HLFX.Ru Forum - OpenGL vs Direct3D

Показать все 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)

Отправлено XaeroX 16-05-2014 в 19:52:

OpenGL vs Direct3D

Т.к. ни для кого уже не секрет, что я занимаюсь мультирендером в волатиле, решил создать тему, где буду делиться впечатлениями от обоих API (OpenGL, D3D9) при решении одних и тех же задач.
Если у вас есть собственные наблюдения - пожалуйста, давайте делиться ими в этой теме.

Пока могу сказать, что D3D нравится всё больше и больше.
Назову два интересных момента.

1) Сглаживание (multisample)
Для включения MSAA в OpenGL под виндой требуется пересоздавать окно программы! Почему? Оч. просто. Сначала нужно создать контекст и получить кои-какие функции WGL, т.к. в винде имеются только функции GL 1.1, и остальные надо получать через расширения. Без контекста их получить нельзя. А заодно надо проверить, поддерживается ли MSAA драйвером. Но чтобы создать контекст, надо установить пиксельформат. А изменить его для одного и того же окна уже никак нельзя.
В D3D есть функция CheckDeviceMultisampleType, её можно вызвать до создания девайса. Ничего пересоздавать не требуется.
Справедливости ради отметим, что в Linux окно тоже пересоздавать не нужно, GLX реализован грамотнее, чем WGL.

2) Многопоточный рендеринг
Контекст OpenGL может быть current только для одного потока в каждый момент времени. Поэтому, если мы желаем рисовать в отдельном потоке, надо вызывать в нём wglMakeCurrent. Но что если нам надо, вернувшись в основной поток, тоже выполнить какую-нибудь GL-команду, да хотя бы glReadPixels для скриншута? Мы должны вызвать wglMakeCurrent в основном потоке. Но он уже вызван в потоке рисования! Значит, после рендеринга надо освободить контекст в потоке рисования. Т.е. мы вызываем wglMakeCurrent( hdc, hglrc ) два раза за кадр - в потоке рисования и в основном, а также wglMakeCurrent( hdc, NULL ) тоже два раза. Можно, конечно, слегка оптимизировать, вызывая wglMakeCurrent в основном потоке только тогда, когда мы собираемся выполнять команды OpenGL. Но это сильно усложняет логику - ведь команда снятия скриншута может поступить, вообще говоря, на любом кадре, или, скажем, игрок захочет подгрузить доп. текстурку (скин модели игрока). Но в любом случае как минимум один раз пара вызовов wglMakeCurrent будет вызвана. А эта команда, вообще говоря, довольно затратная - это мы знаем ещё по использованию pbuffer (одна из причин его замены на FBO - именно этот wglMakeCurrent).
В D3D, согласно документации, есть "внутренние механизмы синхронизации", поэтому никакие функции вызывать не надо, можно смело дёргать команды отрисовки из любого потока. В итоге выигрыш от многопоточности становится ощутимее.

__________________

Отправлено Ku2zoff 16-05-2014 в 20:33:

Первый пункт... Ну, в общем-то мне плевать на сглаживание. А если учесть разрешения современных дисплеев, то без него вполне можно обойтись при 1920х1080 и даже при более низком кол-ве пикселей. А вот второй... Если D3D менее затратен, это даёт ему хорошее преимущество. Как человек, ничего толком не смыслящий в кодинге графики, в очередной раз напишу: D3D рано или поздно изломается с новой версией винды. А OpenGL будет соместим. Ну или по-любому будет враппер OpenGL-D3D, исправляющий несовместимость. А вот обратно навряд ли. Уж больно они говённые, врапперы из D3D в OpenGL.

Добавлено 17-05-2014 в 03:33:

Цитата:

XaeroX писал:
GLX реализован грамотнее, чем WGL.

Потому что мелкомягкие стараются продвигать свою собственную технологию. Вот ещё бы старые версии в новых операционках без проблем работали, было бы круто.

Отправлено FiEctro 16-05-2014 в 22:01:

У проектов на d3d есть одно маленькое но довольно интересное преимущество (по моим наблюдениям) - они не так капризны к драйверам. Ну т.е. таже халфа спойкойно работает на любом офисном древнющем компутере в д3д, а огл не робит и всё тут - иди ищи дрова .

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!

Отправлено Ku2zoff 17-05-2014 в 10:53:

Цитата:

FiEctro писал:
а огл не робит и всё тут - иди ищи дрова

Дык это проблема чисто операционки, то есть винды. Такие уж дефолтные дрова от мелкософта. В линуксе вон тоже без драйверов от производителя железа ничего в 3Д не работает. А со свободными драйверами, как их там, Nouveau кажется, будут аццкие тормоза, либо половина фич не будет поддерживаться. Так что это вполне нормальная ситуация, когда в винде D3D приложения могут работать искаропки. Опять же зависит от видеокарточки и версии WDM. То же самое и в линуксе: со старыми видеокартами Nouveau показывает хорошие результаты.

Отправлено XaeroX 17-05-2014 в 11:48:

Цитата:

Ku2zoff писал:
Вот ещё бы старые версии в новых операционках без проблем работали, было бы круто.

Не понял. Какие старые версии не работают в новых операционках?
В WinXP работает даже DX6 (тот, что в первом Half-Life используется).
Да и в новых должно работать.

Цитата:

Ku2zoff писал:
в винде D3D приложения могут работать искаропки.

К сожалению, это не так. Без установки драйверов не будут работать ни D3D, ни OGL приложения. Проверить легко - удалите драйвера, установите дефолтовые и запустите DxDiag. Вы увидите, что поддерживается только DirectDraw, но не Direct3D.

__________________

Отправлено Cybermax 17-05-2014 в 12:51:

Тема интересная, жаль что её опять свели к драйверам и осям.

__________________
ㅤ

Отправлено ~ X ~ 17-05-2014 в 13:43:

XaeroX про мантл расскажи что-нибудь. Мне интересно, за ним ли будущее?

Вообще преимущества Д3Д очень сомнительные. Т.е. скорее для программера, чем для юзера (т.к. последнему важнее что его игра запускается везде где надо).

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

Отправлено Дядя Миша 17-05-2014 в 13:46:

Цитата:

XaeroX писал:
Для включения MSAA в OpenGL под виндой требуется пересоздавать окно программы!

Сглаживание можно включить в дровах видеокарты, большинство так и делает. Ведь далеко не во всех играх есть такая опция. Да я больше скажу - сам алгоритм сглаживания - невыносимо идиотский. Ну что это такое - отрендерить здоровую картинку, а потом слерпить в маленькую. Нам единственное чего надо - это провода сглаживать, а больше ничего.
Провада и решетки.

Цитата:

XaeroX писал:
Многопоточный рендеринг

Когда всё на GPU пункт полностью теряет смысл - быстрее уже точно не будет, любая видеокарта уделывает CPU как бог черепаху.
Это возможно имело бы смысл только для таких древних рендереров как в ку3. Сейчас во втором потоке логичнее пустить физику и симулятор AI.
Честно говоря для меня эти преимущества таковыми не являются.
Ждём новых.

__________________
My Projects: download page

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

Цитата:

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

Отправлено XaeroX 17-05-2014 в 14:34:

Цитата:

Дядя Миша писал:
Да я больше скажу - сам алгоритм сглаживания - невыносимо идиотский. Ну что это такое - отрендерить здоровую картинку, а потом слерпить в маленькую.

Я вообще-то про MSAA пишу, а не про SSAA.

Цитата:

Дядя Миша писал:
Честно говоря для меня эти преимущества таковыми не являются.

А у меня не было цели назвать преимущества конкретно для тебя.
Я называю преимущества как таковые. Если ты не понимаешь, как организовать многопоточный рендеринг, эффективный даже тогда, когда "всё на GPU" - это ведь не мои проблемы, правда? И не проблемы D3D?

Цитата:

~ X ~ писал:
про мантл расскажи что-нибудь. Мне интересно, за ним ли будущее?

Я с ним не работал, увы.

Цитата:

~ X ~ писал:
Т.е. скорее для программера, чем для юзера

Да, эта тема исключительно для программеров.

__________________

Отправлено XaeroX 17-05-2014 в 14:57:

Дядя Миша
Ещё раз повторю. Если ты не понимаешь, как что-то можно сделать, это не означает, что это сделать нельзя. И незачем пытаться сводить всё к абсурду, все давно в курсе про твоё искромъотное чувство юмора.

__________________

Отправлено Дядя Миша 17-05-2014 в 15:09:

Я не про то, что нельзя. Я про то, что смысла не имеет.
Даже с мультипоточным рендерером маленькая комнатка с мягкими партиклами выдаёт 30 фпс на 9800GT. Я полагаю в однопоточном рендере будет даже быстрее, из-за отсутствия потерь времени на синхронизацию потоков.

__________________
My Projects: download page

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

Цитата:

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

Отправлено XaeroX 17-08-2014 в 19:13:

Забавно

Тестирую волатилу, карта с кучей полигонов (арканос), оптимизации нет, все сурфасы рисуются скопом, даже без сортировки. Вертексный буфер, но в системной памяти.
OpenGL: 400 fps
Direct3D9: 800 fps
SMP, 4xFSAA, 16xAA.
Крутил и так, и эдак - D3D9 упорно выдаёт более высокий фпс.
Такие дела...

__________________

Отправлено PLut 17-08-2014 в 19:23:

XaeroX Это GTX275? Если что-то слабее взять, то как с FPS дела?

__________________
Base Defense on Steam, ModDB

Отправлено XaeroX 17-08-2014 в 21:02:

На других пока не тестировал. Это, так сказать, первичные замеры.
Буду делиться наблюдениями и дальше.

__________________

Отправлено Ku2zoff 18-08-2014 в 05:45:

Цитата:

XaeroX писал:
OpenGL: 400 fps
Direct3D9: 800 fps

Цитата:

XaeroX писал:
На других пока не тестировал. Это, так сказать, первичные замеры.

А если с другими драйверами или на другой видеокарте будет одинаковая производительность? Мне стало интересно. Я хотел бы на своей машине замерить

Отправлено 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 лучший друг бага...

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

Отправлено 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'

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

Цитата:

Дядя Миша писал:
А какой текстурный юнит при этом активен? Не может ли быть такой ситуации, когда subImage работает только на нулевом.

Как раз токе нулевой. В волатиле дептч-текстура может быть привязана только к нулевому юниту. Это связано с особенностями старых видеокарт в режиме D3D9, и я на всех рендерерах придерживаюсь этого правила, чтобы не плодить разные рендерпатчи.

__________________

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

Показать все 31 сообщений этой темы на одной странице

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