OpenGL egl khronos Идиотов не сеют и не жнут.
Это я читал EGL specification.

Спек, напомню, должэн позволять получить OpenGL context для любой оконной системы, и дажэ для голого фрэймбуфера.

Вызов инита (eglGetDisplay) предусматривает передачу любого вида display_id в качестве единственного параметра: X display, win32 DC, gbm_device * ...
Но не предусматривает передачу того, какой именно вид display_id был передан.

Невозможные дебилы какие-то разрабатывали.

Linux OpenGL говно Некоторая часть glx-приложэний прямо сразу после запуска падали с воплями... эээ.. Ну, точно не записал — но в общем — Unsupported GLX Request Opcode major: 155 (GLX), minor: 16 (private vendor request). А, да, от всякого dri я избавился путём установки дефолтной libGL вместо nvidia. Ну, DRI тожэ запретил в конфиге — но как-то оно не всегда запрещается.

Выяснение через tcpdump показало, что это был vendor 65536 — т.е. на самом деле не vendor, а glXSwapIntervalSGI из GLX_SGI_swap_control.

Ъ, у него возможные ошыбки — только BadValue. Ну да, glx у nvidia как обычно никто не тэстирует, и работает оно из рук вон плохо.
Пока что заменил в /usr/lib/nvidia/legacy-304xx/libglx.so.304.123 все строки GLX_SGI_swap_control на GLX_SGI_twap_control. И всё заработало.

Linux OpenGL nVidia Некоторое время назад обнаружыл, что glxgears, запущенные через честный nvidia glx — т.е. на удалённом хосте. Или на локальном, но через tcp/ip, а не unix domain и с export __GL_FORCE_INDIRECT=1 — так вот, запущенные безо всякого dri и shm — стоят на месте и вообще от них практически ничего не добьёшся. Притом пишут один раз какое-то невменяемо большое число fps. А вся система как-то ощутимо тормозит.

Сегодня разобрался детальней.
Во-первых, они -не тормоз, а медленный газ- не стоят на месте, а весьма медленно крутятся. Притом только новые, у которых видимо угол поворота вычисляется в зависимости от скорости в fps, чтобы они не крутились слишком быстро — у старых всё лучшэ с этим.
Во-вторых, вставленная отладочная печать обнаружыла следующую вещь: эта хрень пишэт в какие-то буфера (ну, в буфер приёма/передачи иксов, очевидно) сразу пачку команд на отрисовку фрэйма — пока не заткнётся. Около 15 тысяч фрэймов помещается.
Эти фрэймы рисуются со скоростью, определённой synctovblank. Т.е. около 60 fps. То есть минут 5 по-хорошэму.
При этом почему-то через несколько секунд проскакивает ещё один фрэйм, потому glxgears получает возможность написать свою дикую скорость да ещё и скорректировать скорость вращения.
И потом всё, на несколько минут оно затыкается.

Очевидный вариант решэния — XSync() или хотя бы XFlush() после каждого фрэйма. В общем, XFlush() почему-то работает дажэ лучшэ — в смысле — с ним — скорость 60 fps, а с XSync() — 30. Но это работает.
Ещё вариант — через nvidia-settings поставить nvidia-settings -a SyncToVBlank=0, тогда будет выдавать свои максимальные fps (у меня около 3000 при варианте через ssh на localhost), и особо не затыкаться, поскольку некогда.
Кстати, скорость через tcp/ip причти одинакова независимо от того, замаплено окно или нет — отличается вроде на 10%. Притом оно на 20% медленнее, чем через direct rendering если окно замаплено и в 3 по-моему раз медленнее если окно незамаплено.
Но вообще — надо с этим что-то делать, поскольку opengl-приложэния привыкли, что если SwapBuffers() прошло, то всё, пользователь ужэ видит на экране картинку — а тут такая херня творится.

OpenGL Пытаюсь уяснить себе спеки OpenGL ES.
Читаю на сайте хроносов введение и описание версий: <<OpenGL ES 1.X For fixed function hardware:... OpenGL ES 2.X — for Programmable Hardware>>
Это заголовки мини-описаний соответствующих версий. То есть никто там не рефлексирует ужэ давно, что приличное functions API должно как раз абстрагировать жэлезо и позволять добиваться результата независимо от.

3D OpenGL g-code Пару дней назад до слоупока дошло, что единственное распространённое API для рисования 3d — это g-code.
Все остальные опенгли и директиксы до 3D пока сильно недотягивают. Ну, примерно как и API для рисования рамочек в windows 95. Разве что продвинулись несколько дальшэ.

OpenGL Интересная презенташка по портированию игр под linux/opengl: developer.nvidia.com
via tos4 at ru-linux.livejournal.com

идиоты OpenGL По поводу современного состояния OpenGL:
Нет никакого нового OpenGL. Крайний OpenGL — OpenGL 1.2, да и то в некоторых аспектах лучшэ ориентироваться на 1.1. Всякие 2 и 3 сделаны исключительно для безсмысленного прожыгания времени, потому ни для чего кроме безсмысленного прожыгания времени они получились не пригодны. В общем, оно или сдохнет совсем или вся муть из 2 и 3 будет переделана кем-то вменяемым. Скорее, к сожалению, сдохнет, хотя я всё ещё надеюсь на что-то.

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

У второй версии ещё бывает вполне простой и адэкватный интэрфейс. В тех местах, где не менялся с 1.1.
В дальнейшэм из API просто выкинули большынство высокоуровневых конструкцый, предложыв переписать всё самостоятельно.
Вообще, способность хроносов и присных гробить код и навыки программистов, наработанные десятилетиями, просто поражает.

То есть вот люди взяли, и понерфили освещение. Было — вполне рабочее. С пачкой довольно весёлых спец.эффектов. Стало — вот вам язык из 60-х годов, пишыте сами.
[продолжэние под катом]