Лекция 2. Вершинный конвейер. Введение в DirectX 11 

@SweetTea, интересно, где же ещё ты меня видел?)

В той модели конвейера, которую я на доске рисовал - PA. Тут важно помнить, что это именно модель, для представления в голове. В реальности, между вашим С++ кодом и железом лежат: DirectX, драйвер, да и сама видеокарта нифига не проста во внутреннем устройстве. И в ней (реальности) конвейер может не просто отличаться, а его может не быть совсем.

Мотиваций тут несколько. Для начала, если уж ставить себе цель научить людей кросплатформенному API, то надо не OpenGL (которого нет ни на мобильных устройствах, ни на XBox и PS4), а какой-нибудь WebGL или OpenGL ES на худой конец. Есть ещё вулкан, но он не случился на iOS и дюже сложен для новичков. По сути, это даже не графический API, а API управления GPU. Люди из комитета по его разработке (Khronos) не рекомендуют его для обучения начинающих: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-Nx0u-9ZwrmQ.htmlh45m и я с ними полностью согласен. Почему не WebGL? Потому что там а) сильно течёт абстракция - надо на JS писать, как на С++ и б) всё-таки вакансий под него мало, и серьёзную графику, по большей части, пишут на C++ и не для веба (но ситуация с каждым годом меняется!). Возвращаясь к вашему вопросу, следующая мотивация - всё та же востребованность в вакансиях. Я не видел мест, где на позицию графического программиста требовалось знание исключительно OpenGL. Возможно, такие места есть, но чаще всего требуется знание хотя бы одного из двух и не важно чего. Конечно, знание обоих API, всегда плюс. Но на промышленном уровне разницы, на самом деле, мало: в крупных проектах API всегда закрыт какой-то «доморощенной» абстракцией и код непосредственной работы с DX или OGL ничтожно мал. Например рендер StarCraft 2 может работать и через DX (на Windows) и через OGL (на Mac). Потом, из личных ощущений, если освоить DX, то с OGL проблем особых не будет - железо под капотом одно и то же, а абстракция не столь толста. Это как выучить Java - на C# пересесть будет сильно проще, чем с Си. Но это всё скорее о том, что разницы принципиальной нет. Почему же всё-таки крен в сторону DX? Тут две причины. Во первых, инструментарий поддержки разработки из коробки: отладка, мат. библиотека, загрузка текстур - всё это доступно после установки Visual Studio без каких-либо дополнительных библиотек или приседаний. А значит среднестатистический студент потратит больше времени на важное, чем на борьбу с окружением. Во вторых, у меня с DX опыта больше: код на нём я лучше проверю на корректность, быстрее смогу помочь студенту разобраться с каким-то «затыком», покажу больше «граблей» и «подводных камней», рассказ будет ближе к реальной жизни.

Но вообще, я старался делать лекции максимально абстрагировано от конкретного API: они должны быть полезными и для людей, самостоятельно изучающих OpenGL. В одной из последних даже рассматривается код на GLSL ;)

Имхо DirectX 11 гораздо стуктурированей. OpenGL проще не отражает суть современных GPU

Если вы хотите разобраться в устройстве современных GPU, то лучше всего CUDA изучать. Графические API (что DX11, что OpenGL) нынче являются очень толстой абстракцией, сильно отдалившейся от реального железа. В оригинале, кстати, мнение даже не моего авторства, а небезызвестного Wolfgang Engel - глав. реда серии GPU Pro, он работал над графикой GTA 4 как минимум (наверняка ещё над чем-то, но за всем не уследишь).

Можно попытаться изучить драйвер AMD для Vulkan. gpuopen.com/gaming-product/amd-open-source-driver-for-vulkan/. Финский студент наверняка бы изучил

В 2018 году лекции записывались. В DX 12 Mesh Shaders появились в 2020. Без машины времени никак не вышло бы затронуть. К тому же одно дело «затронуть», рассказывая сказки, а другое дело в реальной боевой ситуации поюзать, а потом опыт передавать.

@@DrollerTroller Как вы считаете, имеет ли смысл применять рендеринг на основе bsp дерева в 2022 году? Современное оборудование ведь несравнимо быстрое, поэтому есть ли смысл заморачиваться на сортировку полигонов через bsp?

@@frettchen1585 bsp - это инструмент. Имеет ли его смысл применять или нет, зависит от задач конкретного проекта. Наверняка есть ситуации, когда имеет смысл. Подробную классификацию, к сожалению, не дам.

@@DrollerTroller Спасибо за ответ. Отличные лекции.

Разность результатов в матричном умножении - это факт не про DirectX, а следствие линейной алгебры: если вектор слева, то он - строка, если справа - столбец :) Обычное правило умножения матриц (вектор - это матрица 1хN или Nх1 в зависимости от ваших вкусов). Тут компилятор HLSL более чем корректно всё делает. А вот технически (на уровне ассемблера) эти умножения отличаются из-за укладки матрицы в память. Во втором варианте будет 4 векторные инструкции скалярного умножения dp4 (если матрица и вектор 4-мерные). А в первом будет куча mul'ов и add'ов (под рукой нет кода более точно сказать, можете сами глянуть, что fxc выдаёт в том и том варианте). Правда, есть подозрение, что на современных видеокартах, которые являются уже скалярными, а не векторными, разницы по скорости не будет. А вот устройства с честными векторными ресгитрами вариант с умножением вектора справа сильно быстрее делают.

Спс проверил в GLSE такая же ситуация

msdn.microsoft.com/ru-ru/library/windows/desktop/bb509632(v=vs.85).aspx - про кратность 64 байтам подробнее. Вообще, ковырять DirectX11 я бы советовал всегда сверяясь с оф. документацией.

Благодарю, а то внес дезинформацию