hackage.haskell.org
Чет ржу ..
Чет ржу ..
Это я читал EGL specification.
Спек, напомню, должэн позволять получить OpenGL context для любой оконной системы, и дажэ для голого фрэймбуфера.
Вызов инита (eglGetDisplay) предусматривает передачу любого вида display_id в качестве единственного параметра: X display, win32 DC, gbm_device * ...
Но не предусматривает передачу того, какой именно вид display_id был передан.
Невозможные дебилы какие-то разрабатывали.
sdl2 — фреймворк с супер поддержкой на всех платформах — есть возможность достутачтся до gl контекста; используется великанами индустрии типа valve.
sfml — C++ легкий фреймворк для того же самого. Поддержка чуть меньше, тоже есть возможность получить контекст и работать с opengl напрямую.
glfw — сверхлегкий opengl фреймворк, позволяет только получить контекст и самые базовые события окна и инпута.
Хочу заметить что как sdl так и sfml это довольно развесистые фреймворки, которые можно использовать без привязки к opengl, при чем если делаете 2Д игру, то врядли нужно что то даже делать с GL. Что есть хорошо.
Выяснение через 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. И всё заработало.
habrahabr.ru "Шейдер для жука"
Круто у чувака получается жуков лепить Надеюсь и в браузер переползет.
opengl.org // 4.5 короче релизнули // как обычно больше всякого прямого доступа и контроля за пайплайном
Сегодня разобрался детальней.
Во-первых, они -не тормоз, а медленный газ- не стоят на месте, а весьма медленно крутятся. Притом только новые, у которых видимо угол поворота вычисляется в зависимости от скорости в 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?
Если суспенднуть процесс, который рисует то шум продолжается.
На этот раз наткнулся на Unigine 0.2, последнюю опенсорсную версию. (Unigine потом стал закрытым и успешным).
OpenGL там конечно старый (1.4) и с кучей расширений, однако сама демка интересная, в т.ч увидел там:
* soft shadows
* портальный рендеринг с исползьванием bsp-trees
* система частиц
* зеркала
* автоматические тени от всех объектов
* простая rigid-body физика (даже с joint-ами)
* объемный туман
* просто скриптовый язык с консолькой по ~
Допинал исходники чтобы компилялись на современных линупсах.
github.com
Вкратце — снимается оверхед на последовательный биндинг наборов buffer objects
(и улучшается cache locality)
developer.download.nvidia.com
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
Такие дела.
А вот если я хочу отрендерить в буфер, который в памяти CPU - то какие есть модные способы стащить результат, кроме glReadPixels?
youtube.com
картинкосмотрелка
картинкосмотрелка
Читаю на сайте хроносов введение и описание версий: <<OpenGL ES 1.X For fixed function hardware:... OpenGL ES 2.X — for Programmable Hardware>>
Это заголовки мини-описаний соответствующих версий. То есть никто там не рефлексирует ужэ давно, что приличное functions API должно как раз абстрагировать жэлезо и позволять добиваться результата независимо от.
Можете скомпилить это говно и посмотреть насколько будет грузиться CPU?
github.com
У меня есть подозрение что моя старая видяха/драйвер не умеют в нормальный Transform Feedback,
поэтому взвинчивают CPU до 100%, что смешно и нелепо.
Спс.
Все остальные опенгли и директиксы до 3D пока сильно недотягивают. Ну, примерно как и API для рисования рамочек в windows 95. Разве что продвинулись несколько дальшэ.
Вместо описания -> youtube.com
( en.wikipedia.org )
Образец говнокода тут -> github.com
Из планов на будущее: переписать все нах на шейдерах и заюзать нормальные буфера вершин и индексов, вместо deprecated GL_QUAD (хотя тут тоже плюсы — работает на опенсорсных дровах, лол).
Нет никакого нового OpenGL. Крайний OpenGL — OpenGL 1.2, да и то в некоторых аспектах лучшэ ориентироваться на 1.1. Всякие 2 и 3 сделаны исключительно для безсмысленного прожыгания времени, потому ни для чего кроме безсмысленного прожыгания времени они получились не пригодны. В общем, оно или сдохнет совсем или вся муть из 2 и 3 будет переделана кем-то вменяемым. Скорее, к сожалению, сдохнет, хотя я всё ещё надеюсь на что-то.
Третья и четвёртая версии окончательно перестали быть удобным языком трёхмерной графики. И вообще OpenGL перестало быть API трёхмерной графики, взамен оно стало набором команд для битстаффинга некоторого класса современных векторых процэссоров.
Довольно смешно правда, что при этом возможности делать на них что-то кроме графики так и не появилась — но это неважно.
У второй версии ещё бывает вполне простой и адэкватный интэрфейс. В тех местах, где не менялся с 1.1.
В дальнейшэм из API просто выкинули большынство высокоуровневых конструкцый, предложыв переписать всё самостоятельно.
Вообще, способность хроносов и присных гробить код и навыки программистов, наработанные десятилетиями, просто поражает.
То есть вот люди взяли, и понерфили освещение. Было — вполне рабочее. С пачкой довольно весёлых спец.эффектов. Стало — вот вам язык из 60-х годов, пишыте сами.
[продолжэние под катом]
blog.wolfire.com — интересно