LINUX.ORG.RU

OpenGL. Сколько ему ещё осталось?

 ,


0

4

Только-только научился писать простенькие 3D игрушки на OGL 3.3, а тут такое. А раз Vulkan - замена OpenGL, то последнему недолго осталось перед тем, как его поддержку дропнут в драйверах. Сколько времени можно ещё отсиживаться на OpenGL?

★★★★★

Последнее исправление: tailgunner (всего исправлений: 1)

OpenGL перестанет быть API для написания hi-end игр, и всё. В остальном - будет реализация поверх Vulkan, и будет OpenGL жить долго и счастливо.

tailgunner ★★★★★
()

А раз Vulkan - замена OpenGL

присоединюсь: нет.

morse ★★★★★
()
Ответ на: комментарий от gavlig

Что же он тогда такое, если не замена OpenGL? Теперь, когда Vulkan вышел, кому, кроме нас - неосиляторов, нужен OGL?

robus ★★★★★
() автор топика
Ответ на: комментарий от robus

Теперь, когда Vulkan вышел

В окно он вышел, лол.

cnupm
()

Лет 25-30.

куда это его...

тут вон игори 2005 года спокойно бегают на современном железе.

Deleted
()
Ответ на: комментарий от tailgunner

OpenGL перестанет быть API для написания hi-end игр, и всё

а так же для эмбедщины, например. реализация zero copy off-screen rendering на GLES - ад и израиль. втягивание механизма синхронизации буферов из GL в систему - ад и израиль. зоопарк GPU-специфичных буферов из-за выделения их в DDK - ад и израиль

jtootf ★★★★★
()
Ответ на: комментарий от jtootf

OpenGL uses the high-level language GLSL for writing shaders which forces each OpenGL driver to implement its own compiler for GLSL that executes at application runtime to translate the program's shaders into executable code for the target platform. Vulkan will instead provide an intermediate binary format called SPIR-V (Standard Portable Intermediate Representation), analogous to the binary format that HLSL shaders are compiled into in DirectX. This reduces the onus on driver vendors, allows shader pre-compilation, and permits application developers to write shaders in languages other than GLSL.

From this.

robus ★★★★★
() автор топика
Ответ на: комментарий от robus

intermediate binary format

intermediate

какая тебе разница, во что твой шейдер будет скомпилирован? прекомпилированный GLSL-шейдер тоже, знаешь ли, бинарный

jtootf ★★★★★
()

Я думаю, лет 10±5

В любом случае, это гадание на кофейной гуще. Время покажет.

upd. А, раз речь о дропе поддержки в драйверах (а не о том, что приложения не будут на нём разрабатываться кроме маргинальщины, как я изначально подумал), то явно намного больше. Лет 20 минимум ещё проживёт.

Psych218 ★★★★★
()
Последнее исправление: Psych218 (всего исправлений: 2)
Ответ на: комментарий от jtootf

Зачем? Зачем всё писать на вулкане, когда можно больше, чем половину переложить на драйвер? Таки у всех прям боттлнеки?

gavlig ★★★
()
Ответ на: комментарий от robus

В каком-нибудь из следующих OpenGL просто добавят обязательные ARB_spir_program и ARB_vulkan_interop.

i-rinat ★★★★★
()
Ответ на: комментарий от tailgunner

Если всем этим будет заниматься Vulkan, проблемы уйдут сами собой.

прелесть Vulkan именно в том, что он этим не занимается. вообще. да, если у тебя будет унифицированная работа с памятью, уйдёт огромное количество проблем

jtootf ★★★★★
()
Ответ на: комментарий от gavlig

Зачем всё писать на вулкане, когда можно больше, чем половину переложить на драйвер?

что именно переложить на драйвер?

jtootf ★★★★★
()

Ага ага. Вышел новый ассемблер - когда закопают C++?

anonymous
()
Ответ на: комментарий от gavlig

управление памятью и очередью команд как минимум.

ну вот сейчас в GLES управление памятью отдано драйверу. в результате у нас есть платформозависимый KHR_image_base, OES_EGL_image, OES_EGL_image_external и несколько почти нигде не реализованных расширений для того, чтобы оное управление вернуть обратно. спецификация эти расширения практически не описывает - типы opaque, семантика операций по большому счёту implementation dependent, реализации всегда OS-dependent (EGLImage для Android нельзя использовать в Linux, etc)

кроме этого у нас есть собственный механизм синхронизации буферов (fence), иногда несколько (gralloc_lock в Android), требующий поддержки в ядре и юзерспейсе, и целого слоя взаимодействия с механизмами синхронизации остальной системы. ваши иксы и ваш Wayland часто работают плохо не потому, что их писали криворукие идиоты, а просто потому, что OpenGL - отвратительное, негибкое, малостандартизованное говно мамонта

jtootf ★★★★★
()
Ответ на: комментарий от jtootf

ну давай закопаем OpenGL потому что GLES. А десктоп вообще не существует и для него ничего не пишут и там всё не работает.

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

gavlig ★★★
()
Ответ на: комментарий от tailgunner

В остальном - будет реализация поверх Vulkan, и будет OpenGL жить долго и счастливо.

Я видел, что это обсуждали в рассылке Месы и говорили, что пока это нерационально, так как абстракции OpenGL плохо ложатся на Vulkan. https://lists.freedesktop.org/archives/mesa-dev/2016-February/107937.html

trycatch ★★★
()
Ответ на: комментарий от gavlig

ну давай закопаем OpenGL потому что GLES

как будто в большом OpenGL что-то из указанного выше решается лучше

которые не принесут профита

ага, конечно. никакого вообще профита

jtootf ★★★★★
()
Ответ на: комментарий от jtootf

Ещё вот захотелось добавить, что при всей говёности опенгл альтернативы ему пока нет. Я сам не в восторге от него, но вулкан, как заметил анон выше, как ассемблер и плюсы. Будет вылизанный апи без тонны легаси и ещё одной тонны экстеншенов от вендоров, я первым возьмусь за лопату и начну присыпать опенгл сверху, а пока — увы и ах, при том что он

отвратительное, негибкое, малостандартизованное говно мамонта

gavlig ★★★
()
Ответ на: комментарий от gavlig

вулкан, как заметил анон выше, как ассемблер и плюсы

с тем же успехом можно говорить что OpenGL с шейдерами и OpenGL с фиксированным конвейером как ассемблер и плюсы. опять же - почему бы не переложить это на драйвер?

вылизанный апи без тонны легаси и ещё одной тонны экстеншенов от вендоров

ну вот дали вам такой API - унифицированный, чистый, без экстеншенов на каждый чих. вендорам существенно меньше делать, опять же, драйвера проще. что не так?

jtootf ★★★★★
()

шутка про еще один стандарт

unt1tled ★★★★
()
Ответ на: комментарий от jtootf

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

gavlig ★★★
()
Ответ на: комментарий от jtootf

какая тебе разница, во что твой шейдер будет скомпилирован?

Они, как я понял, хотят кодеров заставить шейдеры компилить в этот промежуточный формат. А это - просто сразу взять и умереть, как сложно. Как бы.. не каждый сумеет компилятор написать.

Таким образом мне есть разница, кем скомпилирован - если дадут какую-нибудь функцию, типа glsl_to_spirv, то всё ок. Если заставят компилятор писать, то всё очень печально.

robus ★★★★★
() автор топика
Ответ на: комментарий от YLoS

Уже кубик даже на интеле крутится.

robus ★★★★★
() автор топика
Ответ на: комментарий от robus

не каждый сумеет компилятор написать

примите вещества и покиньте тред. много компиляторов GLSL ты написал?

как я понял

ты неправильно понял

jtootf ★★★★★
()
Ответ на: комментарий от gavlig

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

вот это, кстати, в кои-то веки стало реальностью. промежуточный слой для Vulkan можно сделать переносимым

ну, посмотрим. но я всеми конечностями за

jtootf ★★★★★
()

ТС: ты уверен что САПРы будут переписывать на Vulkan??? Чтобы деталь трактора переливалась блёстками на мониторе проектировщика михалыча?

I-Love-Microsoft ★★★★★
()

Боюсь вскоре просто реализуют вулкан, как общий базис, а сам opengl будут писать как обертку вокруг вулкана.

Deleted
()
Ответ на: комментарий от I-Love-Microsoft

этим вообще не пахнет особо, лет через 10 минимум кто то заюзает.

umren ★★★★★
()
Ответ на: комментарий от YLoS

Вот веселуха будет гогда опенгл дропнут, а вулкан не заработает.

Есть мнение, что почти 100% будет OpenGL 4.6 и 4.7. А ежели повезет, то еще и 5.0 будет. Не торопитесь...

anonymous
()

ещё отсиживаться

Зачем? Хелловорлды можно писать хоть под Kukan или Pukan, у тебя же их стабильной работы никто не требует.

anonymous
()
Ответ на: комментарий от anonymous

Это серьёзный бизнес, всё уже нанут писать под новые апи, дабы спровоцировать апгрейд ос/железа.

anonymous
()
Ответ на: комментарий от I-Love-Microsoft

Как раз для CAD-ов Vulkan очень даже неплох, особенно для ситуаций, когда надо рендерить что-то, содержащее большое количество одинаковых деталей (e.g., сегменты труб, лестницы, поддерживающие структуры, и т.д.).

anonymous
()
Ответ на: комментарий от reprimand

Xorg - сколько ему еще осталось?

Ровно до того года, когда проприетарные дрова отвяжут от X11 и добавят EGL...

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от robus

Это радует. А то бинарные шейдеры - это же ужас какой-то.

Пахнет вендофоном версии младше 8.

andreyu ★★★★★
()
Ответ на: комментарий от buddhist

Я и сам за что-нибудь простое. Потому как даже без шейдеров (т.е. на нормальном GLUT'е) OpenGL уж слишком монструозный. Дофигища кода все равно писать надо. А уж про шейдеры я вообще молчу — продукт чьего-то больного мозга.

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

figure *circ = DrawCircleAt(x, y, z);
colr *c = RGB(r, g, b);
circ->material = MAT(c, refl, ...);
а не толпу непонятного кода.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.