Прим. переводчика: в данной статье обсуждается общий подход к выбору вопросов для собеседований на позицию программиста компьютерной графики на примерах конкретных вопросов.
Недавно я видел в твиттере довольно много дискуссий о хороших и плохих вопросах на интервью. Некоторые из этих вопросов выглядят полезными.
В основном, наиболее интересные из них выглядят открытыми. Они могут привести к весьма большим и разветвленным обсуждениям или даже не имеют «верного» ответа. В конце концов, вам, скорее, нужно не узнать ответ (он всё равно будет 42), а увидеть процесс решения проблемы и/или оценить общие знания и понять собеседуемого.
Ниже я приведу примеры, которые я использовал несколько раз, и они ориентированы на программистов графики с некоторым количеством опыта.
Когда GPU семплирует текстуру, как он выбирает MIP-уровень, из которого нужно читать?
Хорошо, этот вопрос имеет верный ответ, но он всё ещё может привести к обширным обсуждениям. Правильный ответ на сегодняшний день примерно такой:
GPU растеризует всё блоками 2x2, считает разницу по вертикали и по горизонтали между фрагментами блока и использует величину этой разности, чтобы выбрать MIP-уровень, который наиболее близок к соотношению 1:1 между фрагментами и текселями.
Если соискатель не знает ответа, вы можете попытаться вывести его. «Итак, если бы вы создавали GPU или писали программный растеризатор, что бы вы делали?».
Многие люди начинают с идей «базирующихся на расстоянии до камеры» или «основанных на том, насколько большой треугольник на экране» и так далее. Это отличный первый шаг (примерно так растеризаторы и работали в действительности в прежние времена). Вы можете принять вызов, вбросив следующий вопрос: “а что если UV координаты не вычисляются в вершинах?”. Это, конечно, сделает неприменимыми предложенные методы и нужно будет придумать что-то ещё.
Когда же вы придёте к решению с фрагментными блоками 2x2, вы можете продолжить дискуссию на эту тему (или сразу перейдите сюда, если соискатель знает ответ). Какие последствия влечет за собой такое решение для разработки программ, эффективности и т.д.? Возможные темы для обсуждения:
Для квада 2x2 инструкции шейдера должны выполняться вместе и одновременно, только в этом случае разница между UV-координатами может быть вычислена. Это приводит к некоторым последствиям для ветвлений, обычное семлпирование может быть запрещено (HLSL) или его результат будет не определён (GLSL), когда оно используется в ветке кода с динамическим ветвлением.
Одновременное выполнение может привести к разговору о том, как вообще работает GPU. Что такое wavefront, warp, SIMD (или как это называется в API/GPU, который вы предпочитаете). Как работает ветвление, как хранятся временные переменные, как оптимизировать загрузку, как работает скрытие задержки и т.д. Можно потратить много времени, чтобы это обсудить.
Растеризация квадами 2x2 является неэффективной для маленьких треугольников (треугольники, которые занимают один фрагмент, всё равно требуют 4 выполнения шейдера). Какие это имеет последствия для высокой плотности геометрии, тесселяции, созданию LOD (уровней детализации) для геометрии.
Вы разрабатываете систему освещения для игры/движка. Какой она будет?
Здесь нет «верного» ответа. Система освещения может быть какой угодно. Есть как минимум несколько десятков обобщённых методов сделать её и, возможно, миллионы специализированных подходов! Освещение охватывает множество вещей: точечные, площадные источники света, освещение от окружения, эмиссивные поверхности; предпосчитанные и вычисляемые в реальном времени компоненты освещения; направленное и глобальное освещение; тени, отражения, рассеивающие среды; соотношение между производительностью в реальном времени и производительностью при настройке, требования платформ и многое другое. Разговор может выйти долгим.
Тут вы заинтересованы в следующем:
Общий процесс мышления и подход к открытым проблемам. Стараются ли соискатели прояснить требования и пробуют ли сузить круг вопросов? Говорят ли, что они знают, чего не знают, и что требует дальнейшего исследования? Предлагают ли они единственную любимую технику и не могут предоставить никаких её недостатков?
Осведомлённость в существующих решениях. Знают ли соискатели принципы работы, достоинства и недостатки популярных техник? Пробовали ли какие-то из них? Насколько актуальны их знания?
Знание проблемной области и принятие решений. Это система освещения для одной очень специфической игры или она должна быть «применима для всего»? Как это повлияет на возможные выборы, и каковы последствия этих выборов? В частности, как делать выбор в зависимости поддерживаемых платформ, минимальных требований, ожидаемой сложности контента и других факторов?
Отношение к компромиссам. Почти все инженерные решения их включают. Выбирая тот или иной путь разработки чего-либо, вы приходите к компромиссам. Это может быть производительность, удобство использования, расширяемость, доступность на разных платформах, сложность реализации, влияние на рабочий процесс, количество того, что нужно изучить, и так далее. Понимают ли соискатели эти компромиссы? Знают ли они достоинства и недостатки различных техник и понимают ли их?
Вы разрабатываете графический API для движка. Как бы он выглядел?
Так же как и с вопросом о системах освещения выше, тут нет одного верного ответа.
Этот вопрос проверяет осведомленность в проблемной области (консольные графические API, «современные» API такие, как DX12, Vulkan, Metal, более старые API: DX11, OpenGL, DX9). Что нравится и не нравится в существующих графических API (тревожный знак, если всё устраивает: идеального API не существует). Что бы поменяли если бы была возможность?
И вновь компромиссы. Что предпочтительнее, производительность или удобство использования? Можно ли иметь и то, и другое (если «да», то почему и как? если «нет» — почему?). Можно ли сузить требования в зависимости от того, кем будет пользователь? Будет ли предложенная абстракция работать эффективно на нижележащих API?
Вам нужно хранить и рисовать большой город. Как бы вы это сделали?
Этот вопрос я не использовал, но видел его упоминание в твиттере. Звучит как отличный вопрос, потому что он не имеет верного ответа и затрагивает много вещей.
Создание, процедурная генерация, запекание, изменения в реальном времени, хранение, стриминг, пространственные структуры данных, уровни детализации, перекрытие видимости, рисование, освещение и так далее. Много-много возможных обсуждений.
Ну, вот и всё.
Стоит сказать, что прошло много времени с тех пор, как я сам собеседовался… Так что я не знаю, так ли полезны эти вопросы для соискателей, как мне кажется.
Комментарии (35)
MrSung
05.08.2021 22:15-10Сейчас есть unreal engine 4. Поясните смысл существования программиста графики и написания движка в 2021.
lesandr Автор
05.08.2021 22:19+5Свой движок даёт намного больше возможностей для низкоуровневых оптимизацией и адаптации всего движка для своих игр.
Смысл существования программистов графики в разработке и улучшении методов компьютерной графики. Пока ещё не все задачи в этой области решены и работа для нас есть.
SmallSnowball
05.08.2021 23:46+9UE 4 кто-то пишет, и среди этих людей есть программисты графики
UE 4 великолепный движок, но далеко не ультимативное решение со множеством своих проблем и закидонов.
При использовании UE4 иногда все равно есть потребность в программировании графики, написать там кастомные шейдера для игры, подправить чего-то, корректно настроить существующий рендер, пофиксить багло в рендере и т.д.
Кастомные готовые движки других студий никто не отменял, заменять их на ue4 просто так без весомых причин никто не будет.
Куча существующих игр на разных движках требуют поддержки и багофикса
Некоторые игры требуют очень кастомных рендерных решений (см. Claybook, Dreams и т.д., где даже полигонов то нету).
samrrr
06.08.2021 00:24+1А скока там фпс выдаст этот замечательный движок при 5000 активных акторов с включённым Tick?
Aquahawk
06.08.2021 08:31+2Если вы используете unreal engine 4, но вдруг что-то начинает умирать, вам нужен программист графики. Когда вы хотите какой-то эффект которого нет из коробки, вам нужен программист графики. Когда вы хотите отобразить 100 тысяч анимированных объектов, как я показывал в демке https://www.youtube.com/watch?v=adixpp9CK_A вам потребуется программист графики. Если вы просто собираете игры как из конструктора, только из готовых деталей, вам не нужен программист графики, просто ваши задачи не доросли до возможности такого специалиста окупать. Современная видеокарта это невероятно гибкий и мощный инструмент, владение которым требует многих лет тренировки и оттачивания навыков. Ровно как react во фронтенде, очень много кто его использует, но есть множество случаев когда он неуместен.
nameless323
06.08.2021 16:22+1к остальным комментам. если студия большая и делает большие дорогие игры, то использование стороннего движка это зависимость от лицензии и вообще от желаний юридического отдела разработчика движка. это риски, для многих компаний (см EA, Ubisoft etc) проще разработать свой двиг и не рисковать что разработчики сменят лицензию движка, закроют его, перестанут поддерживать и т.д
etoropov
06.08.2021 02:49+1Наверное узнал про мир графики по этим вопросам больше, чем знал до этого вообще.
Было бы очень круто, если бы кто-нибудь написал статью с ответами на все эти вопросы.
Malizia
06.08.2021 06:00+1В книге Real-Time Rendering есть ответы на большинство, если не все, вопросы.
UberSchlag
09.08.2021 07:11А в книге Game Engine Architecture есть отличная глава по архитектуре железа: как cpu, так и gpu. При этом она достаточно краткая, чтобы не перегрузить деталями, но и достаточно подробная, чтобы разобраться.
0o00oo00o0
06.08.2021 08:05+1Посоветуйте, пожалуйста, проверенные временем настольные книги, учебники по разработке графики и игровых движков. Знаю о red book, но этого мало.
lesandr Автор
06.08.2021 08:08+1По графике могу посоветовать упомянутую выше Real-Time Rendering.
Про игровые движки, к сожалению, не берусь что-то советовать.
sakhapovi
06.08.2021 08:57+1По игровым движкам знаю про Game Engine Architecture (уже есть third edition).
UrsusDominatus
06.08.2021 12:46+1Графика: серии Shader X, GPU Pro, GPU Zen, GPU Gems, Ray Tracing Gems. Отдельные книги: Shaders for Game Programmers and Artists, Real-Time Rendering.
Игровые движки, и всякие околодвижковые темы: серии Game Programming Gems, Game Engine Gems.
Malizia
06.08.2021 13:59-4не уверен, что есть какой-то смысл читать книги по геймдеву изданные 5+ лет назад. Информация сильно устарела, железо обновилось, вышли новые API.
UrsusDominatus
06.08.2021 14:04+6Принципы компьютерной графики не меняются уже много лет. Возможности видеокарт выросли, пайплайн усложнился немного. Появился compute, ray tracing. Но база та же. Из этих книг можно много чего почерпнуть даже сейчас.
BattleAngelAlita
06.08.2021 15:49+1Как раз самое то. Железо достаточно развилось чтобы применять на практике хай-енд алгоритмы тех времён.
Malizia
06.08.2021 15:57так в современных изданиях/переизданиях будут все актуальные на текущий момент алгоритмы с новыми хай-энд идеями. Зачем заниматься фильтрацией, если её уже сделали авторы новых изданий?
JKot
06.08.2021 16:40+2Обычно в книгах очень много интересных техник которые на практике не применимы при текущем развитии. Практические техники лучше смотреть у тех кто занимается практикой. Все ведущие игровые студии выпускают пайперы на Siggraph, GDC или на своих сайтах, там гораздо приспособленные к практике решения. В книгах тоже много интересных и полезных идей, но всё же там часто теоретизируют.
BattleAngelAlita
06.08.2021 09:47-3>Вопросы на собеседовании графонщика в юнити
Эта статья
>Вопросы на собеседовании графонщика в гайдзин
«Есть лес, есть танк, найди коллизию танка с деревом»
Тру стори.
JKot
06.08.2021 10:18+3Ещё хорошими вопросами будут про MSAA там много тонкостей того, как вычисляются атрибуты для каждого сэмпла. Какие будут ddx ddy в каждом сэмпле и при каких обстоятельствах. Как правильно резолвить msaa в HDR пайплайне.
Про TXAA можно долго говорить о методах подавления гостинга и замыленности.
А так-же стоит поговорить про оптимизацию шейдеров. VGPR, bandwidth, occupancy, wavefront и что происходит при бранче и т.д
UrsusDominatus
06.08.2021 13:51+2Ой, не нравятся мне эти вопросы по MSAA и TXAA. Очень смахивает на "сам только что узнал, буду теперь валить кандидатов". Чего греха таить, сам я не знаю сходу (хотя графический программист, вроде) ответы на эти вопросы. Но это очень специфические, относящиеся к определенной технике/методу/эффекту темы. Кто с этим плотно не работал (я не работал), всех нюансов сходу знать не может. Таких вопросов можно придумать миллион. ИМХО, надо спрашивать про базовые вещи, без понимания которых очевидно что дальше в "MSAA" лезть не следует. Вопросы описанные в статье - база и основа. Хорошие вопросы (Ваш про оптимизации тоже).
Чтобы я еще спрашивал:
Буфер глубины. Как хранятся значения в нем? Как влияет на точность значения near и far plane? Что можно сделать для повышения точности
Матрицы трансформации. Пространства координат и переходы между ними. У нас есть большущий бесшовный мир, будут ли проблемы с точностью вычислений и если будут, то какие есть методы борьбы с ними?
Render Pipeline. Как из вершины модели получается пиксель на экране? Какие оптимизации применяют производители видеокарт для ускорения пайплайна? Что быстрее отрисовать: меш из миллиона вершин занимающих один пиксель, или треугольник занимающий миллион пикселей? (Не смотрите на меня так, очевидно же что вопрос с подвохом).
Владение тулзами. У вас на сцене то исчезает, то появляется модель (должна быть всегда, это баг). Что вы будете делать чтобы локализировать и починить эту проблему? На некоторых видеокартах эффект отличается визуально от референсной реализации. Ваши шаги по выявлению "неисправности"?
nameless323
06.08.2021 16:29+1на самом деле из всех этих вопросов даже про рендер пайплайн можно говорить часами, начиная с UMD, KMD и их роли в dx/opengl/vulkan и заканчивая тем, как работают кэши у output merger когда стоит блэнд. хотя наверное чтоб спросить в общем и пойдет, но имхо если собеседовать на мидла/сеньора то обсуждения опыта в резюме (а как эту технику сделали, какие были сложности, что бы сделали по другому). из своего последнего собеседования, только положительные ощущения от собеседования с человеком, с которым я час обсуждал как раз анти-алиасинг (который у меня в резюме и был) и очень не понравился вопрос на "пересеките на бумажке луч с плоскостью", что гуглится за 5 минут и особо в памяти потом не задерживается. вывести самому можно (что я и сделал в итоге) но зачем? хотя для джунов нужны как раз общие вопросы
JKot
06.08.2021 16:31+1TXAA сейчас используется прям везде, есть сотни техник которые используют его идеи, странно будет если кандидат ничего не слышал про это.
Сложные вопросы нужны чтобы отделить джуна от сеньора. К примеру даже про MSAA сеньор может не знать, но если знает это уже большой плюс.
Ваши вопросы хорошие. Про Parallel reduction ещё неплохо бы спросить.
Malizia
06.08.2021 14:09немного оффтопа - через пару дней начнется SIGGRAPH 2021, судя по программе, там много чего интересного будет. Кто-нибудь следит?
Chaos_Optima
06.08.2021 15:26SIGGRAPH уже почти прошёл, осталось несколько дней
Malizia
06.08.2021 15:37https://s2021.siggraph.org/ Здесь даты с 9 по 13 августа. Возможно, это только онлайн часть.
Chaos_Optima
06.08.2021 19:06Да сори перепутал, он с пн, запутался из-за того что они видосики уже выложили для ознакомления
FadeToBlack
Да это жесть какая-то, а не вопросы. Современных соискателей боишься спросить вообще что такое mip маппинг, рискуя получить встречный вопрос: а зачем его трогать, оно же само работает как-то? Мб, конечно, это следствие того, что слишком многое сейчас "просто работает само", поэтому глубокие знания не требуются.
lesandr Автор
Не отчаивайтесь. Ещё есть достойные соискатели, способные ответить про мип-маппинг и не только.
Tufed
Познакомился с мип-маппингом еще в начале нулевых, когда интернет был почасовой по карточкам, а наибольший интерес вызывала игра «проклятые земли» от Nival Interactive. Вызов консоли и разбор файлов при помощи блокнота привел к поиску всяких возможностей кастомизации. Хоть я и не разработчик игр, а просто любитель, но подобные собеседования люблю. Всегда интересно поговорить с профессионалом, даже если не возьмут на работу, то результатом собеседования будут новые знания от отсутствия которых я завалился.
YouLeb
Да, есть такие, правда такие требуют зарплату $100500/год))
Aquahawk
Отличные вопросы. В своё время вопрос о том как же выбирается мип уровня привёл к появлению такой шуки https://busyrev.github.io/mipExploration/ Забавно что от производителя карты рисунок зависит, а от модели - нет, также мобилы прям дичь творят иногда. А люди прекрасно ищутся, если задачи интересные, оплата достойная и ищет не просто HR а глава отдела(тобиш я). Если что мы как раз двигло написали очень производительное. Демка https://www.youtube.com/watch?v=adixpp9CK_A риал ворлд из игры https://www.youtube.com/watch?v=QZsPXvuyD8U Сам себя не похвалишь, никто не похвалит :)
MomoDev
это какой-то странный программист графики. На вулкане к примеру мипмапы надо руками генерить, само собой ничего не работает
В целом вопрос о том как работает мипмаппинг очень быстро встает когда нужно самому рассчитать мип уровень, к примеру в случае трассировки лучей
nameless323
наверное это программист графики для игр на каком-нибудь коммерческом движке (не будем показывать пальцем на движок). на самом деле можно даже генерировать мипы, но не понимать как они выбираются в итоге + когда все есть из коробки многие не задумываются про всякие ваши ddx, ddy, откуда они берутся, как текстуры и вообще данные на гпу приходят и про вообще ваши все эти математики - кинул объект на сцену, какая-то магия, в шейдере уже есть матрицы, есть текстуры, засамплил не думая и уже программист графики (слава богу не все такие, но по ощущениям таких кандидатов все больше, хотя прям собеседовать кого-то я отказался лет 5 назад).
хотя вопросы откровенно простые, но учитывая современный рынок и легкость в первых шагах в геймдеве с использованием движков, даже такие вопросы многих ставят в тупик