OpenGL помогает сажать баги, Direct3D - находить их
Нет, речь пойдёт не о замечательной штуке под названием Direct3D Debug Runtime, и даже не о инструменте PIX. Речь пойдёт о многопоточности и банальных race conditions.
Столкнулся я вчера с удивительной, неописуемой проблемой. Периодически перестаёт применяться вертексный шейдер к отдельным полигонам, и они начинают мерцать. В OpenGL - всё идеально, а в D3D - мерцание. И только при включенной многопоточности. Выключаю статическое кэширование - мерцания нет. Выключаю шейдеры - мерцания нет. Отключаю вызов SetVertexShader( NULL ) (т.е. отключение однажды забинденного шейдера) - мерцания нет. Включаю Debug Runtime - мерцания нет. А так - есть. Гугл, разумеется, был перерыт, и я быстро убедился, что такая проблема возникает только у меня. Я и на драйвер грешил (обновил), и на версию дхсдк (обновил). Ничего не помогало. Мерцает, зараза, и всё тут, словно вертекс-шейдер с перепою и раз в пару сотен кадров просто не хочет биндиться.
Раз дело связано с многопоточностью - остаётся только вариант с race condition, но вот где? Первая мысль, традиционно - не у меня, а у "говнокодеров", написавших директх/драйверы/венду (говнокодерам эта мысль всегда приходит первой ), но я её быстро отогнал. И вот методом многочасового ковыряния в отладчике проблема таки была найдена. Выглядела она в общем случае так:
C++ Source Code:
effect->shader = NULL;
if ( true ) effect->shader = pshader;
Разумеется, вместо true там реальное условие, которое после инициализации становится либо всегда истинным, либо всегда ложным (если шейдер не удалось загрузить).
OpenGL по каким-то причинам совершенно игнорировал эту очевидную ошибку, и мерцания в нём не было никакого. Одним словом - OpenGL лучший друг бага...
Надеюсь, этот пост кому-то поможет, если он столкнётся с непонятным мерцанием и "через раз биндящимися" текстурами и шейдерами.
Ещё немного о том, за что я ненавижу OpenGL.
В нём трёхкомпонентный secondary color!
Тут надо пояснить. Когда шейдеров не было, вторичный цвет задавал цвет спекуляра, а его альфа-компонент не использовался и считался равным 0. В D3D он игнорировался на этапе обработки данных пользователя (там цвета засылаются как DWORD), а мерзкий OpenGL в функции glSecondaryColorPointer дал чёткую установку: кол-во компонентов, переданное пользователем, всегда 3, иначе ошибка! Типа, смотрите на меня, я OpenGL, я самый умный, а вы тупые юзеры.
Появились шейдеры. Появился резон использовать альфа-компоненту вторичного цвета. Что изменилось в D3D? Он перестал игнорировать альфа-байт, переданный пользователем, и передаёт его в шейдер. Что изменилось в OpenGL? НИЧЕГО! Задать 4-компонентный вторичный цвет нельзя. Ну то есть как? Некоторые драйверы (например, NVIDIA) принимают size = 4 у glSecondaryColorPointer. Но формально это нарушение спеки, а значит, на каком-нибудь интеле может быть ошибка и цвет не будет передан вообще. А самое, блин, интересное - нет никакой возможности проверить, поддерживает ли драйвер size = 4 (ну кроме как вызвать функцию и посмотреть glGetError).
Конечно, некоторые скажут - зачем тебе glSecondaryColorPointer, если есть glVertexAttribArray? Ответ: для ARB_vertex_program те же самые ограничения, а использование GLSL у меня опционально, т.к. он ухитряется глючить на некоторых видеокартах (особенно интелах).
И ещё. Железо, разумеется, использовало все 4 байта вторичного цвета. Альфа-компонент часто хранил Fog coordinate. Однако от пользователя это скрывалось. Следовательно, никаких препятствий задавать 4-компонентный вторичный цвет технически нет и быть не могло.
Сегодня речь пойдёт о Радеонах - да, мы словно снова в 2005 году. Но не о Direct3D (хотя наверняка под ним всё было бы отлично!), а о кривых OpenGL-драйверах (или какой-то ещё НЁХ??) в 2018 году, Карл.
Имеется макбук с ОС High Sierra, Radeon Pro 555.
Запускаю движок и с изумлением замечаю, что отвалились многие эффекты, как-то вода, софт-партикли, некоторые постфильтры. Начинаю смотреть внимательно и быстро прихожу к выводу, что проблема в том, что в шейдеры попадает неправильная текстура глубины экрана.
А конкретно - вызов glCopyTexSubImage2D не отрабатывает и ничего не копирует. При этом не возникает никаких ошибок! Та же ситуация - с glCopyTexImage2D. Безуспешно перепробовал все мыслимые форматы depth-текстуры - включая depth-stencil - обнаружил, что единственное, что работает - это связка glReadPixels + glTexImage2D. А копирование текстуры - ни в какую! Как тебе такое, Стив Джобс?
Понятное дело, что на другом макбуке с GeForce GT 750M всё работает без каких-либо багов, и полностью соответствует картинке десктопа (где у меня тоже GeForce)...
Скрытый текст:
Этот текст скрытый. Вы должны оставить хотя бы одно сообщение в теме, чтобы его увидеть.
ncuxonaT
Обычные превосходно копируются. Проблема только с копированием глубины и только через glCopyTex(Sub)Image.
Попробую подкостылить для мобильных радеонов копирование через glReadPixels-> PBO ->glTexSubImage, по скорости должно быть сопоставимо, но не удивлюсь, если и оно не работает.
Самое мерзкое тут то, что glGetError не возвращает никаких ошибок.
XaeroX писал: Самое мерзкое тут то, что glGetError не возвращает никаких ошибок.
У меня прям стойкое ощущение дежавю. Где-то у меня так же было. Может даже и не с OpenGL, но запомнил только то, что это вызывало самые противоречивые чувства
XaeroX писал: Проблема только с копированием глубины и только через glCopyTex(Sub)Image.
А какой текстурный юнит при этом активен? Не может ли быть такой ситуации, когда subImage работает только на нулевом.
Я тут запоследнее время столкнулся с массой увлекательных vendor-specific багов, но не знаю в какую категорию их отнести - то ли долбаный радион, то ли грёбанный OpenGL.
Под радионом имеется в виду X1600, далее радион
1. Радион не любит массивы из юниформов. Причём как-то очень выборочно не любит. Если речь идёт о передаче костей, то все драйвера как-то понимают чего от них хотят и не выёживаются. Но если массив меньше - начинаются чудеса. Табличку гаммы (256 флоатов), пришлось упаковать в vec4 64, ошибок не возникало, но глючило знатно.
2. Согласно спецификации они очень чувствительны к кастованию float->int, доходит просто до маразма. Пишешь 0 вместо 0.0 и шейдер уже не компилится.
3. Множество маленьких VBO. У меня там кустики травы. Радиону они жутко не понравились и скорость отрисовки (в сравнении с drawArrays) упала вдвое. Мало этого! При накоплении в видеопамяти достаточно большого кол-ва кустов, радион просто завис нахрен!
4. Совершенно замечательный баг - при включённом GL_POLYGON_OFFSET любое обращение к gl_FragCoord приводит к сваливанию в софтвар и диким тормозам. Пока оффсет выключён это вообще не влияет на скорость.
5. Это уже на Intel. Вчера столкнулся. В расширениях Intel обнаруживается GL_EXT_texture_array, сами многомерные текстуры загружаются в видеопамять. А вот при попытке компиляции шейдера с
#extension GL_EXT_texture_array : require
Выдаётся ошибка "extension 'GL_EXT_texture_array' is not supported". Спрашивается, а как работать с текстурными арраями без шейдера?
Но поскольку драйвера закрытые, понять что это такое - намеренный саботаж, ограничение железа, преимущества того или иного API крайне затруднительно. NVidia любит OpenGL и там проблем практически нет. Я думаю это и есть правильный ответ. Любите своё дело и всё будет работать.
Дядя Миша на форумах пишут, что старые радеоны не поддерживают gl_FragCoord хардварно, оно как-то эмулируется через varying. Видимо, с оффсетом сэмулировать не получается, и всё идёт по одному месту.