The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Существенное увеличение производительности Zink, реализации OpenGL поверх API Vulkan , opennews (??), 07-Ноя-20, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


65. "Существенное увеличение производительности Zink, реализации ..."  –1 +/
Сообщение от Аноним (65), 08-Ноя-20, 22:20 
Я помню из новостей что первый рабочий линуксовый vk дравер для radeon (RADV) потребовал всего 10к строк кода. Наверное он начинался как PoС, ведь все ждали когда amd откроет amdvk. Но выходит написать vulkan намного проще чем написать OGL драйвер, это значит этот Zink упростит разработку дров для будущих GPU, включая веские решения на мобильных SoC.OGL все так же будет использоваться, пока кто-то не напишет фрейвморк который поможет иметь дело со сложностью vulkan. Так что vulkan как "ассемблер" это временное явление, через несколько лет никто не будет писать что-то непосредственно с vulkan.
Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

67. "Существенное увеличение производительности Zink, реализации ..."  +1 +/
Сообщение от Аноним (47), 09-Ноя-20, 00:46 
> всего 10к строк

Дак они спихнули всё, что было в драйвере OGL, на юзверя... Видите ли, тяжело им дрова писать, ниасиливают... А юзер - осилит написание проги на Пулкане, когда только один чёрный квадрат занимает ~1k строк?!

Ответить | Правка | Наверх | Cообщить модератору

69. "Существенное увеличение производительности Zink, реализации ..."  –1 +/
Сообщение от Аноним (69), 09-Ноя-20, 06:14 
>Дак они спихнули всё, что было в драйвере OGL, на юзверя... Видите ли, тяжело им дрова писать, ниасиливают...

RADV (по крайней мере изначально) пилил один чувак, не имеющий отношения к AMD

Ответить | Правка | Наверх | Cообщить модератору

81. "Существенное увеличение производительности Zink, реализации ..."  +/
Сообщение от Spock (?), 24-Мрт-21, 13:01 
Да кого вообще волнует сколько там треугольник строк требует. Один раз написал инициализаую, убрал в модуль и забыл.

В реальном движке сложность как раз идёт от борьбы чёрным ящиком драйвера. А если чёрный ящик минимальный, как в вулкане, то и бороться с ним надо меньше. Один раз заполнил структурку синхронизации и забыл про микрофризы когда драйвер *внезапно* решает прокачать пару гигов через PCI.

Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

70. "Существенное увеличение производительности Zink, реализации ..."  +1 +/
Сообщение от Ordu (ok), 09-Ноя-20, 11:19 
> Но выходит написать vulkan намного проще чем написать OGL драйвер, это значит этот Zink упростит разработку дров для будущих GPU

Задача Zink, как я её вижу, избавить всех от необходимости тянуть реализацию OpenGL. Zink позволит решить проблемы обратной совместимости. А для новых программ, которые хотят OpenGL, я бы порекомендовал посмотреть по сторонам -- не написал ли кто реализацию OpenGL в виде подгружаемой библиотеки, выполняемой поверх vulkan целиком на стороне клиента. Ну реально, это же гораздо удобнее: в системе могут стоять разные версии OpenGL, а со своей программой можно таскать ту версию, которая больше подходит. При желании её даже можно кастомизировать под себя правкой сорцов.

> OGL все так же будет использоваться, пока кто-то не напишет фрейвморк который поможет иметь дело со сложностью vulkan.

Зачем фреймворк? Нужна библиотечка SDL-Vulkan, которая создаст окошко и подготовит всё к выводу. Hello-world на вулкане занимает 1k строк, этот SDL-Vulkan займёт 10k, с учётом всяких возможных вариантов, как можно проинициализировать. А дальше -- сложность vulkan'а перестанет быть сложностью.

То есть, прежде чем писать tl'dr который ниже, я оговорюсь: я с программированием GPU развлекаюсь может раз в пару лет, чисто по фану. Я никогда не работал в геймдеве, и если мне и случается почитывать геймдев форумы, то вот как раз в пару лет, когда у меня в очередной раз не получается работать с GPU так, как мне хочется. Короче я в этом вопросе человек с улицы, которого даже дилетантом язык не поворачивается назвать. Соответственно, я может быть чего-то глубоко не понимаю. Но судя по комментам других участников, у меня складывается впечатление, что они дальше рисования чёрных квадратов никогда не забирались, и на их фоне я чувствую себя гигантом 3d-рендеринга. Поэтому я таки нескромно изложу таки своё скромное мнение.

Сегодня пайплайн OpenGL больше под ногами путается и мешает, с его стеком матриц modelview и бесконечными glEnable/glDisable. Один хрен ты грузишь массивы вершин с сопутствующей информацией в память GPU, после чего в цикле по кадрам объясняешь раз за разом видеокарте, какой массив взять, какими шейдерами рендерить и какие там "global"ы надо передавать этим шейдерам. Нет никаких проблем, прокинуть через эти global'ы матрицу, которая отыграет роль modelview, а заодно вместе с ней координаты источников света, параметры рассеивания света или всё что там ещё нужно твоим шейдерам. С OpenGL ты будешь одни параметры прокидывать через glEnable, другие -- через glPushMatrix/glMultMatrix, третьи -- через global'ы шейдеров. С Vulkan'ом, ты просто хранишь на стороне CPU структурку с этими global'ами, как часть структуры описывающей отрисовываемый объект, и закидываешь global'ы одной структурой в видеокарту, когда возникает необходимость. То есть, с OpenGL тоже так можно, можно сделать glDisable на всё-всё-всё, и работать так же как и с Vulkan'ом, но зачем тогда нужен OpenGL? Для более простой инициализации? Для более простой инициализации можно написать SDL-Vulkan.

Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру