«Хотя набор графических библиотек OpenGL с недавнего времени признан устаревшим» - вот это новость! Кем признан? Когда?

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

Ой, это да. Жопа. Особенно пайплайн бесит, там где ранее у меня была 1 функция в которую я передавал шейдер/буферы данных + буфер вывода рендер таргет и в зависимости от того что рисую ещё и например включение или отключение чего либо типа glEnable() у меня была грубо говоря универсальная хернюша, жрущая любые данные рисующая куда скажут в том виде в котором надо. А теперь для каждого случая надо писать от и до всё статично и отдельно, тоесть если есть отдельный эффект то его надо прописывать от и то отдельно. и потом эти отдельные мегакучи отдавать в порядок исполнения, да ещё млять вручную семафорами синхронизировать ибо отдашь на отрисовку 3 меша в 3 текстуры с потом ещё два результата нужно слить в один то есть 1 2 3 4, а оно исполнит всё в порядке 2 4 3 1 и на экране херота. Блевать хочется. Не, в каких то случаях это прикольно, когда у тебя явно приложение чёткое колличество объектов и способов их рисования, а если хочешь что-то новое добавить, велкам ту кишки и всё по новой. Млять даже что-бы просто отдельно сеткой рисовать или переключить заливку цветом не из текстуры, а из просто vec4 нужно всё продублировать внести 1 изменнеие и всю эту кашу отдельно оформить, конечно макросы и выделение в функции общего дада, но код жиреет в геометрической прогресии. А если хочется графических экспериментов то всё приехали. Либо соси, либо строй высокоуровневую обвязку, которая сожрёт процессор и все плюшки от ручного управления всем летят в трубу.

убили модульность шейдеров

Ну, да, я вот про это. Грубо говоря, для каждого сцекнария отрисовки всё должно быть описано заранее и быть статическим, никакие изменения в процессе работы не могут быть в принципе (за исключением некоторым)

Раньше ты мог для некоторых объектов просто водном и том же коде отключить буфер грубины или ещё что, а теперь сосать, пиши отдельно всё тоже самое для того же самого, но с отключённым буффером, едрить параша. В результате если у тебя в рендере есть отладка, то твой рендер увеличиватся в N раз тоесть был 1000 строк стал 1000* N в зависимости от количества изменений или даже 1000NN если есть варианты множественных изменений, при этом если было 10 шейдеров теперь их может быть под 1000 штук.

Если делать тупо конкретную игру, вот пол, вот небо, вот 3 персонажа, всё круто, если какую хрень динамическую то уууууууууууууууууууууууууу

Пишете бред, т.к. код на Си и питоне не так масштабируется и если чисто код писать то будет 20 и 22 дня, если брать готовые библиотеки и обделить ими Си, то да получится как вы написали и считать будет чуть быстрее, но в целом если взять библиотеки, то сишный код будет написан не сильно более долго, а работать будет в зависимости от навыка учёного-разработчика. В действительности ситуация вымышленная, т.к. чаще команда состоит из учёных-разработчиков на стыке направлений, т.к. часть больше занимается разработкой, а часть больше непосредственно наукой, а инструмент берут в зависимсости от задачи и либо используют сразу матлаб, либо для простых задач питон с библиотеками, либо если нужно поиграться с графикой, то берут готовые сишные библиотеки, типо OSG или vte, на чистом OGL пишут только на Си, т.к. к OGL прибегают именно когда важна производительность.

раньше было всё то же самое, только это всё делалось под капотом в драйвере. в вулкане явно вынесли это всё на публику

Вообще вопрос смешной, т.к. на уровне современного драйвера, разные версии OGL могут работать одинаково, более того старые fixed версии могут внутри гонять буферы и грузить шейдеры

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

Можно не заменять, есть GL_ARB_compute_shader

Это вы скажите свежему OpenCL 3.0 от сентября 2020

не делалось оптимально. mantle(предшественник vulkan) amd создало как раз потому, что не было оптимально

Да, они сейчас чаще так и реализованы. Но фишка то в чём, код как работал так и работает, кишки переехали, на новое, а интерфейс всё тот же, и работает всё быстрее (чуток ибо всё же нашлёпка совместимости). Смешно то что vulkan это и есть фиксированный конвеер как glbegin glend только в профиль. Конечно с крутыми фичами, не без этого…взятыми просто из opengl. Просто конвееры эти не явно в месте торчат, а callback асинхронный, за которым ещё следить надо и один хрен держать в сихронности причём в ручную.

оучше расскажи это самим khronos group https://web.archive.org/web/20171101062642/https://www.pcper.com/reviews/General-Tech/Breaking-OpenCL-Merging-Roadmap-Vulkan

потолок ближе только для узких задач, типо ААА игр в реальном времени, для всего остального OGL3.3-4.3 хватит за глаза

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

Ой, это да. Жопа. Особенно пайплайн бесит, там где ранее у меня была 1 функция в которую я передавал шейдер/буферы данных + буфер вывода рендер таргет и в зависимости от того что рисую ещё и например включение или отключение чего либо типа glEnable() у меня была грубо говоря универсальная хернюша, жрущая любые данные рисующая куда скажут в том виде в котором надо

За универсальность расплачивались производительностью. В Vulkan есть пайплайны, для всего состояния. Пайплайны != шейдерные программы. Пайплайны можно основывать одну на другой, т.о. если состояния различаются совсем чуть-чуть, то это можно использовать, чтобы пайплайна собиралась быстрее и умерить жор (в теории).

Алсо разработчики транслятора d3d -> vulkan продавили динамическое состояние. По итогу, вернули всё в зад. Сначала трансформ фидбек, теперь – это. Ещё один уродливый костыль, все счастливы.

Ну, да, я вот про это. Грубо говоря, для каждого сценария отрисовки всё должно быть описано заранее и быть статическим, никакие изменения в процессе работы не могут быть в принципе

libglslang существует. Так что вполне можно компилировать glsl в SPIR-V на лету, а SPIR-V уже драйвер в машинный код переведёт. Дольше, чем glsl сразу в машинный код, но можно. Кроме того glslang умеет в линковку. Просто очень плохо – один TShader (который представляет из себя «разпаршеный модуль») не может быть использован в более чем 1 TProgram («слинкованная шейдерная программа»).

Соменваюсь что они откажутся от CL, т.к. уж очень кода много, логичнее представить, что они просто в свежих версиях будут внутри держать вулкан, всё также предоставляя OCL как интерфейс

Короче, я понял. Слухи про устаревание OpenGL немного преждевременны.

Не бывает простых и вместе с тем правильных ответов.

Тут куда проще, вулкан не предоставил эволюционного решения чтобы затмить OpenGL, скорее революционное, спорное решение, у которого есть свои плюсы и минусы и что будет предпочтительнее, зависит исключительно от прикладной задачи, проще говоря сейчас у нас 4 современных графических апи: DX, Metal, OGL и Vulkan

Мелкомягкие выпилили поддержку OpenGl в своём чипе SQ1 вообще. Никто не подтянулся.

SQ1 поддерживает Opengl 3.3

https://www.microsoft.com/en-us/p/opencl-and-opengl-compatibility-pack/9nqpsl29bfff?activetab=pivot:overviewtab

https://devblogs.microsoft.com/directx/announcing-the-opencl-and-opengl-compatibility-pack-for-windows-10-on-arm/

плюс

SQ1 поддерживает Opengl 3.3

Значит, потом допилили. Ибо, за что купил, за то и продаю:

Кроме того, Adreno 685 поддерживает только DirectX 12 API, а значит широкий набор игр на OpenGL автоматически выбывает из списка.

Какой дешманский пиар...

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

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

OpenGL-ю давно нужно было вынести мусор. Быстро, решительно. А не жевать жвачку с Compatibility Profile и прочим.

проще говоря сейчас у нас 4 современных графических апи: DX, Metal, OGL и Vulkan

Вот зачем нужны d3d и metal? Затем, что NIH-синдром и попытка vender lock in.

Зачем нужен OpenGL 2-3? С его glVertex4f, glLightf, glPushMatrix и прочим мусором? Затем, что многие не хотят переписывать легаси. А некоторые ретарды и переучиваться не хотят.

Хорош ли на сегодня Modern OpenGL? С его bindless texture, DSA, VAO и прочим? Да, определённо.

Будут ли добавлять в него новые фичи? Очень-очень вряд ли.

Сильно ли отличается Vulkan от Modern OpenGL? Не так уж сильно, на самом деле. В нём есть некоторое количество косяков, связанных с пунктиком про совместимость, заискиванием перед проприетарщиками и директиксерами и просто проблемы роста, но ничего критичного, по большому счёту. Также в нём есть значительное количество плюшек.

Это если совсем-совсем упростить и забить на тонкости и нюансы :P

Зачем нужен OpenGL 2-3?

Многие современные системы поддерживают только OpenGL 2-3.

Например, VirtualBox 6.1.18(последний текущий):

$ glxinfo | grep -i open
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: SVGA3D; build: RELEASE;  LLVM;
OpenGL version string: 2.1 Mesa 20.3.3
OpenGL shading language version string: 1.20
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 2.0 Mesa 20.3.3
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16
OpenGL ES profile extensions:

Упомянутый выше SQ1, поддерживает только Opengl 3.3

Orange Pi 3 поддерживает только Opengl 2.1, лень запускать плату и копировать выхлоп.

говно на палке твой виртуалбокс. программный рендер в mesa поддерживает 4.5

программный рендер в mesa тормозной как говно.

А на VirtualBox можно даже в игры из дистрибутива играть, типа SuperTux и прочие…

для такого есть проброс gpu

Vulkan слишком низкоуровневый чтобы напрямую на нём писать

Норм на нем текстурированый квад пишется. Норм по низкоуровневости.

он скорее для движков

Это ты слышал где-то или сам сделал вывод?

Никаких преимуществ Vulkan не даст, зато с ним много где работать не будет.

Он даёт меньше оверхеда и на CPU, и на GPU, и на их синхронизации. Кури матчасть.