Pukan API.
traptd
> Hello World треугольник
> 600 строк.
Наркоманы штоли
traptd
> camel case и pascal case
pukan case
traptd
> Sergio
> Безусловно, там в Q&A сказали что Hello World треугольник на вулкане занимает
> 600 строк.
Пруфы можно?
Laynos
1:34:05
http://youtu.be/EUNMrU8uU5M?t=1h34m3s
Посоны, у кого-нибудь сохранились слайды с GDC?
Ибо щас по ссылке ересь какая-то рекламная на 15 страниц, вместо доклада на 60.
Нашел в кэше гугла:
Собственно, из того, что я понял:
1. Есть очередь.
2. Есть буферы команд, которые мы в разных потоках записываем, а потом отправляем в очередь.
3. Есть пайплайн стейты (шейдеры + сэмплеры + блендинг + растеризатор + буфер глубины и стенсил + вьюпорт)
4. Полагаю, есть функции по передачи данных с CPU на GPU и обратно.
При этом синхронизация и безопасность — нас стороне программиста.
Теперь про ресурсы. Их можно создавать.
Есть видимо линейные (константы, вершинные и индексные буферы) и пространственные (текстуры), то, что называют image.
Цитата:
Vulkan resources are represented by descriptors
• Descriptors are arranged in sets
• Sets are allocated from pools
• Each set has a layout, which is known at pipeline creation time
- Layout is shared between sets and pipelines and must match
- Layout represented by object, passed at pipeline create time
• Can switch pipelines which use sets of the same layout
• Many sets of various layouts are supported in one pipeline in a chain
vkCreateDescriptorPool(...);
vkCreateDescriptorSetLayoutChain(...);
vkCreateDescriptorSetLayout(...);
vkAllocDescriptorSets(...);
Дескрипторы — я так понимаю, описывают, что за ресурс и как его использовать (константы, вершинный буфер, текстуры и т.п.... м.б. указатель и у нас будут overlapped буферы?)
Что за Set'ы, Layout'ы, и Chain'ы?
И про пассы:
Draws are placed inside render passes
• Executed in the context of a command buffer
• Pipelines, dynamic state objects and other resources bound to command buffers
• All draw types supported
- Indexed and non-indexed, direct and (multi-)indirect, compute dispatches, etc.
VK_RENDER_PASS_BEGIN beginInfo = { renderPass, ... };
vkCmdBeginRenderPass(cmdBuffer, &beginInfo);
vkCmdBindPipeline(cmdBuffer, VK_PIPELINE_BIND_POINT_GRAPHICS, pipeline);
vkCmdBindDescriptorSets(cmdBuffer, ...);
vkCmdDraw(cmdBuffer, 0, 100, 1, 0);
vkCmdEndRenderPass(cmdBuffer, renderPass);
Полагаю, пасс определяет то, куда мы пишем результат и включает в себя все рендер-таргеты, буферы глубины, stream-output и UAV'ы?
Ваши мнения и предположения?
Demiurg-HG
По крайней мере выглядит свежо. Архитектура уже слишком сильно поменялась, бОльшая часть OpenGL интерфейса уже давно deprecated. Ну и сабж, судя по всему, представляет не просто новый API, но и новые возможности, если они реально дадут прямой доступ к памяти видюхи.
Suslik
> прямой доступ к памяти видюхи.
Это щас одно из самых ценных. Идёт наравне с многопоточностью и минимальным оверхедом драйвера.
>Это щас одно из самых ценных. Идёт наравне с многопоточностью и минимальным оверхедом драйвера.
а нафига вам прямой доступ к памяти через узкое горло pci-e, на тормозной стороне cpu ? вы тут собрались больше сосчитать на cpu, чем шейдерами там ? )
Suslik
> но и новые возможности, если они реально дадут прямой доступ к памяти видюхи.
Железки то могут быть разные. Это хорошо на конзолях
Suslik
> Demiurg-HG
> По крайней мере выглядит свежо. Архитектура уже слишком сильно поменялась,
> бОльшая часть OpenGL интерфейса уже давно deprecated. Ну и сабж, судя по всему,
> представляет не просто новый API, но и новые возможности, если они реально
> дадут прямой доступ к памяти видюхи.
Прямым доступом к памяти там и не пахнет. Будет что-то в стиле UpdateMemory/UpdateSubresource/CopyMemory/CopySubresource, а такое и раньше было.
codingmonkey
> а нафига вам прямой доступ к памяти через узкое горло pci-e, на тормозной
> стороне cpu ? вы тут собрались больше сосчитать на cpu, чем шейдерами там ? )
Очевидно, что надо внимательнее читать. Во всех презентациях пишут, что сцена между кадрами практически не меняется. Вот играешь ты, например, в Старкрафт, бегут на тебя 1500 зергов в одном кадре, потом опять 1500 тех же самых зергов в другом кадре, тоже самое в третьем кадре, и ничего между кадрами практически не меняется.
Раньше, чтобы все это нарисовать надо для каждого юнита выставить стейты, текстуры, буфер констант, вершинный буфер, поставить шейдеры, вызвать Draw. После вызова Draw драйвер начнет делать кучу проверок, компилировать шейдеры (да, например, если ты поменял blend state, то надо сделать новый хардварный пиксельный шейдер), и уже только после этого, возможно, что-то нарисуется.
С приходом D3D12 и Vulkan, ситуация кардинально меняется. Ты создаешь целиком Pipeline State, который на этапе создания валидируется и для которого формируется внутреннее представление специфичное для конкретного железа. Ты формируешь парочку Command Buffers и Bundles (которые хранится в драйвере или даже на GPU) для всех тысяч юнитов, и просто его вызываешь в нужный момент.
а дорого вообще на GDC мотаться? Мечтаю там побывать.
но вообще я рад, что программировать станет сложнее. Жизнь кипит, нормальные пацаны любят рамзана, владимира, маму, молятся христу. И программируют для Vulkan.
Demiurg-HG
> Вот играешь ты, например, в Старкрафт, бегут на тебя 1500 зергов в одном кадре,
> потом опять 1500 тех же самых зергов в другом кадре, тоже самое в третьем
> кадре, и ничего между кадрами практически не меняется.
> Раньше, чтобы все это нарисовать надо для каждого юнита выставить стейты,
> текстуры, буфер констант, вершинный буфер, поставить шейдеры, вызвать Draw.
Инстансинг ?
>С приходом D3D12 и Vulkan, ситуация кардинально меняется.
Да, мелкие конторы и инди забьют на них болт :)