HLFX.Ru Forum - OpenGL vs Direct3D

Страницы (3): « 1 [2] 3 »
Показать все 31 сообщений этой темы на одной странице

HLFX.Ru Forum (https://hlfx.ru/forum/index.php)
- OpenGL (https://hlfx.ru/forum/forumdisplay.php?forumid=7)
-- OpenGL vs Direct3D (https://hlfx.ru/forum/showthread.php?threadid=4400)

Отправлено Government-Man 18-08-2014 в 21:00:

Цитата:

Ku2zoff писал:
Мне стало интересно. Я хотел бы на своей машине замерить

Хм, пожалуй мне тоже было бы любопытно.

Отправлено XaeroX 15-09-2014 в 18:41:

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 лучший друг бага...
Надеюсь, этот пост кому-то поможет, если он столкнётся с непонятным мерцанием и "через раз биндящимися" текстурами и шейдерами.

__________________

Отправлено XF-Alien 15-09-2014 в 19:18:

Цитата:

XaeroX писал:
если он столкнётся с непонятным мерцанием

Какого рода мерцание? Местами появляющаяся кратковременная чернота на брашах (когда игрок двигается)? Если да, то я наблюдал такое в текущей версии.

Отправлено XaeroX 15-09-2014 в 19:42:

Цитата:

XF-Alien писал:
Местами появляющаяся кратковременная чернота на брашах (когда игрок двигается)?

Да, но не обязательно когда игрок двигается. Это с камерой никак не связано (а то, что ты видишь в текущей версии - проблемы с теневыми объемами).

__________________

Отправлено ~ X ~ 15-09-2014 в 20:48:

Цитата:

XaeroX писал:
Одним словом - OpenGL лучший друг бага...

Почему-то быдлокодеры то же самое про Си/++ говорят... Но торговаться скоростью я не стану.

__________________
Минутка полезного:
Бесплатный UT-подобный Half-Life mod.
Бесплатный редактор для 32-битных текстур. Без дотнета.
Бесплатный IDE для любых компиляторов и ЯП.
Бесплатная Windows-подобная ОС.
Проверка грамматики русского языка.
Чат по hl[fx]: [email protected]

Отправлено XaeroX 07-04-2015 в 21:00:

Ещё немного о том, за что я ненавижу 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-компонентный вторичный цвет технически нет и быть не могло.

__________________

Отправлено XaeroX 15-06-2018 в 03:59:

Однако, здравствуйте.

Сегодня речь пойдёт о Радеонах - да, мы словно снова в 2005 году. Но не о Direct3D (хотя наверняка под ним всё было бы отлично!), а о кривых OpenGL-драйверах (или какой-то ещё НЁХ??) в 2018 году, Карл.

Имеется макбук с ОС High Sierra, Radeon Pro 555.
Запускаю движок и с изумлением замечаю, что отвалились многие эффекты, как-то вода, софт-партикли, некоторые постфильтры. Начинаю смотреть внимательно и быстро прихожу к выводу, что проблема в том, что в шейдеры попадает неправильная текстура глубины экрана.
А конкретно - вызов glCopyTexSubImage2D не отрабатывает и ничего не копирует. При этом не возникает никаких ошибок! Та же ситуация - с glCopyTexImage2D. Безуспешно перепробовал все мыслимые форматы depth-текстуры - включая depth-stencil - обнаружил, что единственное, что работает - это связка glReadPixels + glTexImage2D. А копирование текстуры - ни в какую! Как тебе такое, Стив Джобс?

Понятное дело, что на другом макбуке с GeForce GT 750M всё работает без каких-либо багов, и полностью соответствует картинке десктопа (где у меня тоже GeForce)...

Скрытый текст:

Этот текст скрытый. Вы должны оставить хотя бы одно сообщение в теме, чтобы его увидеть.

__________________

Отправлено ncuxonaT 15-06-2018 в 04:16:

Обычные текстуры тоже не копируются?

Отправлено XaeroX 15-06-2018 в 04:23:

ncuxonaT
Обычные превосходно копируются. Проблема только с копированием глубины и только через glCopyTex(Sub)Image.

Попробую подкостылить для мобильных радеонов копирование через glReadPixels-> PBO ->glTexSubImage, по скорости должно быть сопоставимо, но не удивлюсь, если и оно не работает.
Самое мерзкое тут то, что glGetError не возвращает никаких ошибок.

__________________

Отправлено ComradeAndrew 15-06-2018 в 07:54:

Цитата:

XaeroX писал:
Самое мерзкое тут то, что glGetError не возвращает никаких ошибок.

У меня прям стойкое ощущение дежавю. Где-то у меня так же было. Может даже и не с OpenGL, но запомнил только то, что это вызывало самые противоречивые чувства

Отправлено Дядя Миша 15-06-2018 в 07:59:

Цитата:

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 и там проблем практически нет. Я думаю это и есть правильный ответ. Любите своё дело и всё будет работать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 15-06-2018 в 13:13:

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

Отправлено Дядя Миша 15-06-2018 в 13:44:

ncuxonaT теперь увяжи в эту теорию GL_POLYGON_OFFSET.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 15-06-2018 в 14:27:

Дядя Миша на форумах пишут, что старые радеоны не поддерживают gl_FragCoord хардварно, оно как-то эмулируется через varying. Видимо, с оффсетом сэмулировать не получается, и всё идёт по одному месту.

Отправлено Дядя Миша 15-06-2018 в 15:39:

ncuxonaT это я тоже читал, но связи как-то не уловил. Полигоноффсет это просто оффсет такой.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Временная зона GMT. Текущее время 14:13.

Страницы (3): « 1 [2] 3 »
Показать все 31 сообщений этой темы на одной странице

На основе vBulletin версии 2.3.0
Авторское право © Jelsoft Enterprises Limited 2000 - 2002.
Дизайн и программирование: Crystice Softworks © 2005 - 2024