Vulkan API (вышел!) (624 стр)

/A\
> но когда ты ставишь барьер между разными этапами, то распараллеливание
> заканчивается.
так с этим никто и не спорит

Как я понимаю, у Вулкана отключаемые слои валидации. Которые в OpenGL отключить невозможно и которые своими проверками снижают производительность. На Вулкане во время разработки их включают, в продакшене выключают и получают прирост в скорости.
Почему не могут ввести аналогичное расширение для OpenGL, чтобы тоже можно было отключать все проверки?

g-cont
По моим наблюдениям, дебажные слои в вулкане замедляют приложение больше, чем какой-нибудь WGL_CONTEXT_DEBUG_BIT_ARB в GL-е. Но там тоже такое есть, если тебе нужно помедленнее :)

g-cont
> Почему не могут ввести аналогичное расширение для OpenGL, чтобы тоже можно было отключать все проверки?
https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_create… _no_error.txt

g-cont
Там вся концепция иная. В ГЛ давно есть zero driver overhead который должен быть не сильно хуже вулкана.
Вулкан без слоев валидации вообще ничего не проверяет, ты можешь создать image с неподдерживаемыми параметрами без всяких ошибок, но потом будет крэш. А слой валидации работает более параноидально и вроверяет абсолютно все, из-за чего работает сильно медленее ГЛ.

Dinosaur
Супер! Буду иметь в виду.

HolyDel
> дебажные слои в вулкане замедляют приложение больше, чем какой-нибудь
> WGL_CONTEXT_DEBUG_BIT_ARB в GL-е.
Вот что я заметил. Поначалу WGL_CONTEXT_DEBUG_BIT_ARB (13-й\14-й годы) действительно сильно ронял перф. Но потом в драйверах што-то подкрутили и разница стала минимальной. Ну если конечно сделать скидку на время, нужное для вывода самих сообщений.

>>В ГЛ давно есть zero driver overhead который должен быть не сильно хуже вулкана.
Тогда какой смысл в вулкане? Он как был сырой так и остался сырым, ИМХО.

/A\
> В ГЛ давно есть zero driver overhead который должен быть не сильно хуже
> вулкана.

далеко не на всех вендорах

innuendo
> далеко не на всех вендорах
у амуде до сих пор на некоторых видяхах траблы с биндлесами.

g-cont
> > > ГЛ давно есть zero driver overhead который должен быть не сильно хуже
> > > вулкана.
> Тогда какой смысл в вулкане? Он как был сырой так и остался сырым, ИМХО.

игры - выжимать все соки из GPU

Только вот айпи,дрова и сама винда этому не очень то и способствуют.

Считаю айпи не вывозят.
Лучше каждый вендор пусть делает прямое общение с gpu.
Мы просто получаем список возможностей данного GPU.
И получаем список команд в виде номера команды и её число параметров.
Все что надо от Микрософта это несколько функций для получения инфы от GPU и передачи данных на
GPU.
Все равно уже Vulkan и dx12 повесили синхронизацию на программиста, то смысла от айпи уже нет никакого.
А обнаглевший Вулкан даже заставил нас менеджер памяти писать самостоятельно.
Да и глючат что Vulkan и dx12 на разных видеокартах.

Тогда каждый вендор сможет быстро внедрять свои фичи, какие захочет.
Потому что даже сейчас есть видеокарты с RTX и старые без RTX и айпи это никак не разрулит.

ronniko
> каждый вендор пусть делает прямое общение с gpu
Ностальгия по DOS-овским временам, когда любая более-менее технически навороченная игра таскала с собой пачку драйверов для поддерживаемого железа? :)

Ты в курсе как программировали под Дос-ом SoundBlaster ?
Ни какой пачки дров не надо было, обходились несколькими асм командами out\in !
Я лично писал свой midi плеер под Dos.
Все было прозрачно и нормально. И ты сам многое контролировал. А не Винда или айпи за тебя.

Давай таскать пачку разных айпи :)
И под каждый писать движок.

ronniko
> как программировали под Дос-ом SoundBlaster ?
> Ни какой пачки дров не надо было, обходились несколькими асм командами !
"Несколько асм команд" для Sound Blaster разных моделей, несколько для AdLib, несколько для Gravis UltraSound и ещё по несколько для других звуковых карт, названия которых я не помню либо вообще не знаю :). Каждый из этих наборов "нескольких асм команд" вполне можно считать драйвером (куда более простым, чем для GPU, но всё же).

> Давай таскать пачку разных айпи :)
Таскай только Vulkan. С учётом "заставил нас менеджер памяти писать самостоятельно" и расширений получается практически то, что ты предлагаешь, но с унифицированным API основной функциональности.

А вот эту часть для винды пишут производители. Как это сейчас и делают дрова Амд и Нвидиа.
Только это будет в самой видеокарте.

Например получили список команд ГПУ.
Скажем команда номер 56 значит init 2d режим.
команда номер 57 значит draw 2d image to screen.
команда номер 1 значит отправить 2d image на гпу.

//psevdo code
SendToGPU(56,800,600);
imgMarioBross = SendToGPU(1,100,100,bmpMarioBross);

Float2 scaleXY = 1.0;
SendToGPU(57,100,100,imgMarioBross,scaleXY);

SendToGPU это win api функция винды.

Как все красиво и просто.
А теперь такое же попробуй написать на opengl или dx11.

>>навороченная игра таскала с собой пачку драйверов
Почему-то для программирования CPU нам не нужны никакие драйвера. Может быть потому что все слои абстракции нативно в железе реализованы?
Так что мешает вендорам договориться и выработать единую систему команд для GPU? Вместо всех этих вулканов и DX12.
Кто не хочет низкий уровень - пусть использует OpenGL.
Кто хочет - пусть программирует напрямую, отправляя железке команды.
Думаю это был бы самый оптимальный вариант.