URL: https://www.opennet.dev/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 122361
[ Назад ]

Исходное сообщение
"Существенное увеличение производительности Zink, реализации OpenGL поверх API Vulkan "

Отправлено opennews , 07-Ноя-20 10:19 
Компания Collabora сообщила о прогрессе в разработке проекта Zink, развивающего Gallium-драйвер для Mesa с реализацией API OpenGL поверх Vulkan. Zink позволяет получить аппаратно ускоренный OpenGL при наличии в системе драйверов, ограниченных поддержкой только API Vulkan. Отмечается, что производительность Zink теперь близка к производительности родных реализаций OpenGL и отстаёт от них лишь примерно на 5%. Напомним, что на начальном этапе разработки производительность Zink отставала от родных реализаций более чем в три раза...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=54047


Содержание

Сообщения в этом обсуждении
"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 07-Ноя-20 10:19 
>проекта Zink, развивающего Gallium-драйвер для Mesa с реализацией API OpenGL поверх Vulkan

🤦‍♂️


"Существенное увеличение производительности Zink, реализации ..."
Отправлено Иваня , 07-Ноя-20 10:36 
Словами скажи, что не так?

"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 07-Ноя-20 10:56 
Да

"Существенное увеличение производительности Zink, реализации ..."
Отправлено Другой анон , 07-Ноя-20 11:02 
Не так, это зоопарк API, раелизаций и главное прослоек между ними для хоть какой то работы всего этого.

"Существенное увеличение производительности Zink, реализации ..."
Отправлено n00by , 07-Ноя-20 11:53 
Не переживайте, Khronos Group переведёт старые интерфейсы (OpenGL) в разряд не рекомендуемых и останется только один Vulkan. Благодарные пользователи подпрыгнут до потолка от радости и побегут покупать новые железки, на которых их любимый интернет-мессенджер на Electron почему-то вдруг перестал работать. Вот тут эксперты по зоопаркам и вспомнят, что есть "ненужная прослойка".

"Существенное увеличение производительности Zink, реализации ..."
Отправлено RHEL fan , 09-Ноя-20 14:30 
Прям напомнило
https://ru.wikipedia.org/wiki/%D0%A1%D0%...,_%D0%BF%D0%BE%D0%B6%D0%B8%D1%80%D0%B0%D1%8E%D1%89%D0%B8%D0%B9_%D1%81%D0%B2%D0%BE%D0%B5%D0%B3%D0%BE_%D1%81%D1%8B%D0%BD%D0%B0#/media/%D0%A4%D0%B0%D0%B9%D0%BB:Francisco_de_Goya,_Saturno_devorando_a_su_hijo_(1819-1823).jpg

"Существенное увеличение производительности Zink, реализации ..."
Отправлено n00by , 09-Ноя-20 16:16 
Люди думают, что время идёт, а Время видит, как люди проходят. https://youtu.be/QnSZhAvQd_8



"Существенное увеличение производительности Zink, реализации ..."
Отправлено Я , 08-Ноя-20 19:13 
суть в том что на будущих видяхах не будет опенгл, останется только вулкан. для того чтоб в этот момент не стало мучительно больно и разрабатывается цинк.

"Существенное увеличение производительности Zink, реализации ..."
Отправлено Мастер , 09-Ноя-20 16:12 
А у Линуксоидов всегда все через кондом работает ибо безопасность во главе!

"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 07-Ноя-20 11:24 
Gallium - это внутренний фреймворк MESA для написания любых драйверов.
Vulkan и OpenGL - это клиентские API.
Zink - это слой трансляции вызовов OpenGL в Vulkan, т.е. к gallium отношения вроде как не имеет.

"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 07-Ноя-20 11:26 
хотя нет, наврал
вот https://i.ytimg.com/vi/RhV72Xc8I1A/maxresdefault.jpg

"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 07-Ноя-20 12:17 
>>производительность Zink отстаёт от производительности родных реализаций OpenGLлишь примерно на 5%.

Вот и вся новость.


"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 07-Ноя-20 13:15 
Надежда есть:

Напомним, что на начальном этапе разработки производительность Zink отставала от родных реализаций более чем в три раза.


"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 08-Ноя-20 02:26 
Это не надежда, а звоночек, что OGL усиленно закапывают (Эппл, Кронос, Гугл...).

"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 08-Ноя-20 05:06 
Что в этом плохого?

"Существенное увеличение производительности Zink, реализации ..."
Отправлено Урри , 08-Ноя-20 17:20 
То, что OpenGL - очень удобная и клевая библиотека, позволяющая легко и просто строить всяческие интерактивные графики без того, чтобы углубляться в эти ваши графические пайплайны.

"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 08-Ноя-20 22:35 
Ну и кто у вас ее отнимает ?

"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 09-Ноя-20 01:50 
> кто

Эппл, Гугл, Кронос...


"Существенное увеличение производительности Zink, реализации ..."
Отправлено asdasd , 09-Ноя-20 16:57 
Вы точно говорите о OpenGL, а не конкретно о OpenGL 2? Потому-что начиная с OpenGL 3 вы уже долны сами написать минимум два шейдера.

"Существенное увеличение производительности Zink, реализации ..."
Отправлено Урри , 11-Ноя-20 00:25 
Да, о первой и второй, которые до сих пор прекрасно работают везде, где есть OpenGL.

"Существенное увеличение производительности Zink, реализации ..."
Отправлено Spock , 24-Мрт-21 12:49 
Возьмите уже нормальную обёртку над вулканом и закопайте glBegin.

"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 07-Ноя-20 12:21 
Чёт странно, вулкан-пукан вроде новая современная херня которая должна работать куда лучше чем opengl, нужна новость, когда будет опережать органах хотя бы на 5%

"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 07-Ноя-20 12:52 
Хочешь быстрее, лучше, сильнее — пиши на вулкане. Прослойки совместимости существуют, внезапно, для совместимости. С тебя 10 баксов на счёт опеннета за консультацию.

"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 07-Ноя-20 17:56 
Каких таких органах? Товарищ майор

"Существенное увеличение производительности Zink, реализации ..."
Отправлено A.Stahl , 08-Ноя-20 12:04 
"вулкан-пукан", товарищ майор.

"Существенное увеличение производительности Zink, реализации ..."
Отправлено lockywolf , 07-Ноя-20 12:28 
Как же оно отвратительно работало раньше, если его так ускорили?

"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 07-Ноя-20 13:16 
Это стандартная практика - сначала работать над реализацией, а потом начинать потимизации.

"Существенное увеличение производительности Zink, реализации ..."
Отправлено Леннарт Поттеринг , 07-Ноя-20 15:56 
> начинать потимизации.

Главное не забыть окно открыть.


"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 07-Ноя-20 13:25 
Отвратительно работает нативный OpenGL на проприетарных дровах от nVidia (в linux). Уже подумываю сменить на amd 5600xt с их открытым драйвером в ядре, т.к. мой старенький радеон R9-290 сейчас в OGL бегает быстрее, чет 1660ti (есть оба). Уже жалею о покупке глюкавого GTX.

"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 07-Ноя-20 16:20 
А ты уверен, что дело в nvidia? Куда чаще всего причина либо разрабы-криворучки, либо разрабы-вредители. Сравнивать amd с nvidia просто нельзя и нет никакого смысла, потому что у nvidia есть как минимум поддерживающий новое железо драйвер, cuda с nvenc и всякие physx в игрушечках (hairworks в том числе), рейтрейсинг с "нейронным" апскилингом и всё остальное.

"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 07-Ноя-20 16:32 
> А ты уверен, что дело в nvidia?

https://forums.developer.nvidia.com/t/slow-opengl-performanc...
https://forums.gentoo.org/viewtopic-t-1096808-start-0.html
https://askubuntu.com/questions/1232787/recent-upgrade-to-20...

Кривость дров от зеленных известный факт, отрицают это только фанатики.

> cuda

проприетарное ненужно

> nvenc

оно разве работает в linux?

> physx

уже умерло

> hairworks

у amd также полно вендерлок технологий, вот только зачем?

> рейтрейсинг

в RDNA2 подвезли, причем в виде стандарта, а не мертворожденного RTX

> "нейронным" апскилингом

и это тоже есть в RDNA2

Жаль, что начальные RDNA2 еще год ждать.


"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 07-Ноя-20 17:15 
Ты говоришь, как человек, который повёлся на рекламу и пустые обещания. Будь осторожен, ты не первый, кого маркетологи поимели. Нвидия это уже сегодня (и вчера, и до того, а значит, много успешных наработок) и она не стоит на месте. Зато есть возможность выбрать шашечки (ждать ещё лет 5) или ехать (сейчас), это всегда плюс в плане того что без конкуренции всегда хуже -- нет мотивации для развития. Пс https://ngc.nvidia.com/

"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 07-Ноя-20 17:21 
> Ты говоришь, как человек, который повёлся на рекламу и пустые обещания

И это говорит человек, который перечислил маркетинговый треш типа hairworks и physx?
Кстати, даже Линус показал средний палец глюкавым драйверам от nvidia.

> Зато есть возможность выбрать шашечки (ждать ещё лет 5) или ехать (сейчас)

Да-да, линуксоиды ждут нормальные драйвера и OGL от нвидии уже 20 лет (погугли сообщения на форумах), но походу жифорсы так и останутся худшим выбором для Linux.


"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 07-Ноя-20 17:35 
Не маркетинговый треш. Успешно используется в играх, ради которых карточки и покупаются. Кто ж виноват, что нвидия нашла общий язык с разрабами. Амд между прочим точно так же мелко гадит пользователям, мол, у нас тут всё такое замечательно открытое, но вы не купили наши новые карты, а значит, у вас будет тормозить. Нвидия за таким не замечена вроде.

У nvidia нормальные драйвера. И это именно тот производитель, который изначально сделал ставку на opengl. Не знаю где ты это взял, но у меня было множество карт разных производителей, и nvidia стабильно наименее проблемные (хотя проблемы конечно имеются, вот в 440 видимо сломали совместимость с efi framebuffer и управление подсветкой).


"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 07-Ноя-20 18:37 
Вообще, ситуация конечно забавная. 99% игр построены на технологиях NVIDIA (буквально все современные, за исключением отморозков с havok), но исполняются на железе от амд.

Я так понял, у меня теперь не работают ни simplefb, ни vgacon, и только efifb остался (до запуска иксов). Возможно, это из-за того, что ядро загружается в efi режиме. Но с иксами тут точно драйвер нагадил, предыдущая версия нормально работает.


"Существенное увеличение производительности Zink, реализации ..."
Отправлено Михрютка , 08-Ноя-20 01:03 
dude.

20 лет с nvidia на борту. на бсд, на лине, на виндах. до сих пор претензий нет.

а нет, вру, есть. на ленововском лаптопе графика тормозила, пока не выяснилось, что минт не шмогла подтянуть нвидиевский драйвер. поставил его руцями, после этого претензии к лаптопу исчезли.

я что-то делаю не так все эти 20 лет?


"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 08-Ноя-20 03:03 
Да, ты привык к лагам

"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 08-Ноя-20 11:22 
Ты бредишь, Мань. Какие лаги? Просто раньше все упоминания mesa приходилось выжигать калёным железом для надёжности, теперь уже можно этого не делать.

"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 08-Ноя-20 11:19 
Ради интереса прочитал твои ссылки. Это полная лажа, поищи нормальные в следующий раз. Они есть, и я, как пользователь, осведомлён о проблемах.  С тех пор, как перешли на libglvnd, проблемы из-за mesa стали неактуальны --  ты сказал, драйвер кривой, но это mesa кривой и багованный был (пока nvidia не выкатила костылей сама).

"Существенное увеличение производительности Zink, реализации ..."
Отправлено дохтурЛол , 08-Ноя-20 12:56 
Вроде да. https://i.imgur.com/mDx9O69.png

"Существенное увеличение производительности Zink, реализации ..."
Отправлено asdasd , 09-Ноя-20 17:00 
По первой же ссылке там явно криворукие разрабы:
> Looks like your application is very inefficient on the Turing compared to the Pascal, clogging the pipelines while not doing much.

Ситуация такая-же, как была с играми iD и процессорами x86 VIA, что оно тормозило, т.к. были оптимизированы под конвеер Intel.


"Существенное увеличение производительности Zink, реализации ..."
Отправлено sharddddin , 08-Ноя-20 22:11 
Поддерживаю! То ли я такой неуч, то ли несведущ в настройках - в Арче, на 1060, с такими же как выше параметрами, рабочий стол (Плазма 5) и все телодвижения тормознутые какие-то - становится даже обидно как-то, когда на работе какой-то Коре-ту-дуо с винчестером на оффтоповской 7-ке летает быстрей, чем моя оптимизнутая (видать, не до конца!) на SSD!!... Раз прооптимизировал настройки xorg.conf и KDE - стало заметно быстрее, но с дальнейшими оптимизациями запорол графику...
(Option         "metamodes" "nvidia-auto-select +0+0 {ForceFullCompositionPipeline=On}"
    Option         "AllowIndirectGLXProtocol" "off"
    Option         "TripleBuffer" "on"
    SubSection     "Display"
        Depth       24
)

"Существенное увеличение производительности Zink, реализации ..."
Отправлено НяшМяш , 07-Ноя-20 13:31 
Так и писали вначале без преждевременных оптимизаций.

"Существенное увеличение производительности Zink, реализации ..."
Отправлено commiethebeastie , 07-Ноя-20 13:53 
У меня маааааленький такой вопрос, как его активировать? Почему разработчикам таких вещей лень написать такую мелочь? файл zink_dri.so у меня есть.

Просто нереально бесит, когда вам пишут про его переменные, а самое важное забывают:

https://docs.mesa3d.org/drivers/zink.html

PS

export MESA_LOADER_DRIVER_OVERRIDE="zink"


"Существенное увеличение производительности Zink, реализации ..."
Отправлено test , 07-Ноя-20 19:01 
еще нужно указать путь к опенгл драйверу, т.е. вот
LIBGL_DRIVERS_PATH=/home/bill/Build/mesa/lib64/dri MESA_LOADER_DRIVER_OVERRIDE=zink glxgears -info

"Существенное увеличение производительности Zink, реализации ..."
Отправлено Неа , 07-Ноя-20 13:55 
Любой, кто более-менее серьезно занимался 3D понимает, что все API, которые есть сейчас являются лютым овном. Из них DirectX менее пахучее.

"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 07-Ноя-20 14:45 
> Из них DirectX более пахучее и менее портируемое

поправил


"Существенное увеличение производительности Zink, реализации ..."
Отправлено Рева RarogCmex Денис , 07-Ноя-20 14:49 
Windows-разработчик, не желающий учить алгоритмы, детектирован.

"Существенное увеличение производительности Zink, реализации ..."
Отправлено lockywolf , 07-Ноя-20 15:51 
Не надо тут инсинуаций. Человек активный контрибутор в wined3d.

"Существенное увеличение производительности Zink, реализации ..."
Отправлено commiethebeastie , 07-Ноя-20 16:32 
Тип:    Аноним

Чтоа?


"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 07-Ноя-20 20:07 
ну и чем плох Vulkan?

"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 07-Ноя-20 16:22 
Вроде говорили, что на каких-то операциях он даже быстрее. Хотелось бы запустить его поверх проприетарного драйвера nvidia, возможно удалось бы решить некоторые проблемы таким образом.

"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 08-Ноя-20 05:27 
Хоти. А мы будем наслаждаться уже сейчас. рыкса.

"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 08-Ноя-20 11:34 
Так проблемы то у mesa. Говнище ещё то.

"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 07-Ноя-20 16:32 
Слабенько, надо вулкан запустить поверх дыреньикса, который поверх опенгля. Вот тогда всё завертится быстро. А всего лишь с одной прокладкой - не, это медленно.

"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 08-Ноя-20 02:03 
С обратной трансляцией в дикректикс и все это в виртуалке

"Существенное увеличение производительности Zink, реализации ..."
Отправлено Cyber100 , 07-Ноя-20 17:10 
opengl всего лишь медленнее на 5 персентов...

в 2020 году, етиху же мать, когда уже аналог директа будет...


"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 07-Ноя-20 17:50 
Уж точно не в ближайшие 100 лет

"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 07-Ноя-20 20:30 
> The overall concept and feature set of Vulkan is similar to Mantle later adopted by Microsoft with Direct3D 12 and Apple with Metal.

Ну ты понял.


"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 07-Ноя-20 20:56 
глупые линуксоиды даже не способны написать аналог директикса...
Пишут какой-то убогий opengl на 5% медленнее

"Существенное увеличение производительности Zink, реализации ..."
Отправлено maximnik0 , 07-Ноя-20 22:59 
>написать аналог директикса.

Вам какую версию то подать ?
Если бы вы следили за новостями то знали что с 2005 года уже были проекты по портированию дерекх,(М$ выложила  под свободной лицензией виндовс СЕ ) до этого были лицензионные ограничения.
Проблемы есть с 9 версией,там некоторые библиотеки жестко прибиты к win32 .А так 10 версия дерекх если вы не знали официально на 80% входит в состав Open Gl 4.3,единственное что нужно сделать это перекомпелировать приложение,т.к по системным вызовам библиотеки  не совподают.


"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 07-Ноя-20 17:49 
DirectX поверх OpenGL поверх Vulcan = coooombooooo! Больше прослоек красивых и разных

"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 07-Ноя-20 17:52 
> при наличии в системе драйверов, ограниченных поддержкой только API Vulkan.

Я таких систем пока не знаю.


"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 08-Ноя-20 02:21 
На OGL уже поставили крест, как Эппл, так и Кронос. В ведре тоже будет пулкан.

"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 07-Ноя-20 17:54 
Нескучная прослойка

"Существенное увеличение производительности Zink, реализации ..."
Отправлено Позитивный аноним , 07-Ноя-20 22:56 
Автор забыл написать: разработчик Zink вышел на основную работу и теперь времени на доработку проекта у него тупо нет. Доделает последние 450 патчей, а дальше что будет с Zink - неизвестно.

"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 08-Ноя-20 02:19 
Про OGL можно забыть, Эппл ещё 2 года назад сказала, что всё. Кронос пилит Пулкан. Последние новшества OGL были в 2012, когда compute_shader добавили.

"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 08-Ноя-20 03:22 
Vulkan мертвый апи, даже память между приложениями делить не может

"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 08-Ноя-20 04:02 
> Vulkan мертвый апи

Увы, этот труп тащат и эппл, и гугл в свои системы. А кронос им активно помогает.


"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 10-Ноя-20 16:40 
> труп тащат... эппл

Там началось всё из-за эппла... на маках и айфонах решили дропнуть OpenGL. Собственно Zink - попытка спасти разработчиков прикладного софта от необходимости переписывать всё на Metal (который нигде акроме яблочной продукции не используется).

Потом подтянулся гугл, поскольку есть возможность получить полноценный OpenGL (а не обрезок в виде OpenGL ES) на железе смартфонов (это всякий шлак типа Adreno, PowerVR и прочих Mali). На Raspberry Pi еще есть какой-то смысл.

Для AMD, nVidia и intel - это бессмысленная прослойка, но может и эти ребята уверуют в Zink через несколько лет (но это уже будет другое железо, другая реальность и т.д.).


"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 08-Ноя-20 05:30 
Распишите минусы вулкана, без приколов, в чем он плох?

"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 08-Ноя-20 12:10 
Вероятно сильная низкоуровневость, чтобы нарисовать что-то типа "helloworld" надо написать ~200 строк кода. Неосиляторы жалуются и ищут готовые фреймворки)

"Существенное увеличение производительности Zink, реализации ..."
Отправлено n00by , 08-Ноя-20 12:30 
> Вероятно сильная низкоуровневость, чтобы нарисовать что-то типа "helloworld" надо написать
> ~200 строк кода.

Это на чём так мало? На Си для "Чёрного Квадрата" Малевича требуется 350, а классический Треугольник - уже 700 (чисто для Вулкана, не считая создания "окна" средствами платформы). Официальный vulkan-tutorial - 900 строк на С++ https://vulkan-tutorial.com/code/15_hello_triangle.cpp


"Существенное увеличение производительности Zink, реализации ..."
Отправлено Аноним , 08-Ноя-20 15:13 
Представь, раньше ты писал на Си++, а теперь тебя пересадили за ассемблер... Вот такая же разница между OGL и Пулкан.

"Существенное увеличение производительности Zink, реализации ..."
Отправлено n00by , 10-Ноя-20 14:39 
> Представь, раньше ты писал на Си++, а теперь тебя пересадили за ассемблер...

Вообще, есть в этом свои плюсы. Всякие гуру разработки операционных систем на диалекте баш, утверждающие, что в Си типизация строгая, а #define объявляет переменную, займут заслуженное место.


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

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

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


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

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


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

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


"Существенное увеличение производительности Zink, реализации ..."
Отправлено Ordu , 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.