to post messages and comments.

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

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

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

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

Кто-нить представляет текущее состояние? Что устарело, можно ли юзать gluPerspective? А то пишут, что матрицу проекций вообще теперь лучше не трогать, типа deprecated. Я в прострации.

в продолжение — если же хотите запилить сишечное кросплатформенное приложение лучше всего ипользовать
sdl2 — фреймворк с супер поддержкой на всех платформах — есть возможность достутачтся до gl контекста; используется великанами индустрии типа valve.
sfml — C++ легкий фреймворк для того же самого. Поддержка чуть меньше, тоже есть возможность получить контекст и работать с opengl напрямую.
glfw — сверхлегкий opengl фреймворк, позволяет только получить контекст и самые базовые события окна и инпута.
Хочу заметить что как sdl так и sfml это довольно развесистые фреймворки, которые можно использовать без привязки к opengl, при чем если делаете 2Д игру, то врядли нужно что то даже делать с GL. Что есть хорошо.

кто-то в жуке говорил что у него хелло ворлд на opengl на С++ жрет больше памяти чем на питоне в геймпае. Так вот, не используйте glut. GLUT — это не фреймворк, это штука для быстрого хакинга и написания графических демок. Делать софт или игры с ним не рекомендуется.

Некоторая часть 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. И всё заработало.

Жуйк, хочу поделиться вот такой вот программкой. По сути — симулятор гравитации. Использует OpenCL для расчёта, OpenGL для визуализации и Qt4 для GUI. Умеет генерировать спиральные галактики и сталкивать кучу оных друг с другом. :)
Гуглокод: code.google.com
Бинарники для венды: dl.dropbox.com

Кому лень читать — Open GL NG это новый модный апи с байткод шейдерами, апи которое не выносит от многозадачности, прозрачное управление состояниями конвеера, а главное, единый апи для десктопа и мобильных. А то смотришь на всякие директ х, мантлы, металы и понимаешь что говнецо это наше OpenGL...
Надеюсь и в браузер переползет.

Некоторое время назад обнаружыл, что 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() прошло, то всё, пользователь ужэ видит на экране картинку — а тут такая херня творится.

Короче когда щас запустил свой велосипедодвижок, то при приближении к модельке (=> росту числа вертексный и пиксельных операий) усиляется высокочастотный шум.
Я слышу как работает GPU?
Если суспенднуть процесс, который рисует то шум продолжается.

Чё там Вентиль у себя наоптимизировал? При запуске стим жалуется, что юзает программный рендеринг, сам весь тормозит, GoldSrc тоже тормозит, Source и вовсе не запускаются. При этом всякий опенсорс типа OpenArena или Xonotic летает как ни в чём не бывало, поэтому на полетевшие драйвера не похоже.

Иногда когда мне совсем нехер делать я хожу по разным старым проектам и пытаюсь их запустить.
На этот раз наткнулся на Unigine 0.2, последнюю опенсорсную версию. (Unigine потом стал закрытым и успешным).
OpenGL там конечно старый (1.4) и с кучей расширений, однако сама демка интересная, в т.ч увидел там:

* soft shadows
* портальный рендеринг с исползьванием bsp-trees
* система частиц
* зеркала
* автоматические тени от всех объектов
* простая rigid-body физика (даже с joint-ами)
* объемный туман
* просто скриптовый язык с консолькой по ~

Допинал исходники чтобы компилялись на современных линупсах.
github.com

OpenGL ES Working Group plans to release a new version of OpenGL ES in 2014

The main features of the new API are:
— Backward compatibility with OpenGL ES 2.0 and 3.0
— Compute shaders, with atomics and image load/store capability
— Separate shader objects
— Indirect draw commands
— Enhanced texturing functionality including texture gather, multisample textures and stencil textures
— Enhanced shading language functionality

For clarification purposes the new API will not include:
— Tessellation and geometry shaders

Такие дела.

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

Чят, реквистирую людей с свежей видях nvidia и линуск.

Можете скомпилить это говно и посмотреть насколько будет грузиться CPU?
github.com

У меня есть подозрение что моя старая видяха/драйвер не умеют в нормальный Transform Feedback,
поэтому взвинчивают CPU до 100%, что смешно и нелепо.

Спс.

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

Можно наивный вопрос? Раньше всегда считал, что для производительности GPU-приложений самое главное это количество треугольников и сложность шейдеров. Сейчас вот, связавшись с этой темой по-настоящему, выясняю, что есть еще такая тема, как дроукол, и что если эти дроуколов дофига, то приложение будет тормозить, даже если каждый из этих дроуколов будет рисовать по два треугольника с примитивным шейдером. Так ли это?

Наговнокодил простой vector slime.
Вместо описания -> youtube.com
( en.wikipedia.org )

Образец говнокода тут -> github.com

Из планов на будущее: переписать все нах на шейдерах и заюзать нормальные буфера вершин и индексов, вместо deprecated GL_QUAD (хотя тут тоже плюсы — работает на опенсорсных дровах, лол).

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

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

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

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

*AGAL *FlasCC Есть надежда, что удастся скомпилировать шейдеры на OpenGL в AGAL при помощи FlasCC компилятора и/или GLS3D (https://github.com/adobe/GLS3D) или glsl2agal (https://github.com/adobe/glsl2agal). Кстати в последнем репо есть офигенная тема: agaloptimiser <github.com>.