Войти
ПрограммированиеФорумГрафика

Что такое DirectX Graphics? (2 стр)

Страницы: 1 2 3 Следующая »
#15
21:18, 3 июня 2019

MrShoor
> Ах, да. Ну и самая абсурдная часть opengl - это то, что компиляция glsl кода -
> задача драйвера.

Это разумно, так ты клянёшь вендора, а не OGL )))


#16
23:14, 3 июня 2019

gamedevfor
> Это разумно, так ты клянёшь вендора, а не OGL )))
Это не разумно, потому что порождает огромное количество реализаций, работающих по разному. И печально всё настолько, что рождаются вот такие велосипеды: http://aras-p.info/blog/2010/09/29/glsl-optimizer/

#17
0:31, 4 июня 2019

MrShoor
Если бы это делал OGL то все кляли бы OGL за то что сделали общую тормозную реализацию, тогда как вендоры могли бы сделать свои реализации более эффективными и быстрыми ведь вендору то лучше знать как работает их железо. Так что OGL поступил мудро.

#18
(Правка: 0:50) 0:49, 4 июня 2019

gamedevfor
> Если бы это делал OGL то все кляли бы OGL за то что сделали общую тормозную
> реализацию
Если бы OGL сделали спецификацию на intermediate low level ассемблер, как например тот же DXBC или IL, то у меня мог бы быть оффлайновый компилятор от кого угодно, хоть даже от тех же самых вендоров, которые лучше знают как работает железо.

> Так что OGL поступил мудро.
Хорошо, что в Vulkan они осознали всю свою мудрость, и сделали spir-v. А то от их мудрости одни страдания только.

#19
1:19, 4 июня 2019
Rikk
> не от кого угодно. а от производителя прибора.или кто тама автор держатель
> патента.
> у тебя —может и нету. а у других которые лицензировали все честно-- мы хотим
> делать, заплатим налог или скока тама платить, мы официально клиент у вас, мы
> официально будем делать по вашей технологии—-может у них и есть...
Как тебе удается генерировать столько белого шума?
#20
1:40, 4 июня 2019

MrShoor
> Это не разумно, потому что порождает огромное количество реализаций, работающих по разному.
А тебя не смущает, что разные видеокарты внутри устроены по разному, имеют разную архитектуру и т.д.?
Оптимизировать API под конкретную карту могут только разработчики железа. Если они это не могут толком сдeлать - это их проблема а не базового API.
Если ты думаешь, что DirectX работает на любых картах 100% идентично, то могу тебя разочаровать. Например в приложении на DX12 после очередного обновления перестал работает родной микрософтовский шейдер генерации мипмапов.
Причем только на одной карте (Titan V), на всех остальных все работало как раньше. Спецификация DirectX не изменилась. Разумеется косяк где-то в связке драйвер-API но как ты это можешь отследить, если у тебя нет под рукой зоопарка всех возможных видеокарт? Приходится доверять вендорам, но и они иногда лажают.

#21
1:44, 4 июня 2019

san
> А тебя не смущает, что разные видеокарты внутри устроены по разному, имеют
> разную архитектуру и т.д.?
А тебя не смущает, что low level ассемблер оптимизировать проще, чем высокоуровневый язык типа GLSL?

> Приходится доверять вендорам, но и они иногда лажают.
Налажать при компиляции high level языка куда проще, чем low level.

#22
1:52, 4 июня 2019

MrShoor
> А тебя не смущает, что low level ассемблер оптимизировать проще, чем
> высокоуровневый язык типа GLSL?
если ассемблер это : одна команда ассемблера=одна команда машинного, то чего там оптимизировать, и куда еще проще?

#23
1:55, 4 июня 2019

MrShoor
> А тебя не смущает, что low level ассемблер оптимизировать проще, чем высокоуровневый язык типа GLSL?
Ты в принципе не можешь оптимизировать ассемблер, поскольку для этого надо знать микрокод и специфику архитектуры каждой карты. Ассемблер, о котором ты говоришь, это далеко не микрокод, потому от ассемблерных шейдеров давно уже отказались. Микрокод и внутренняя архитектура - закрытая информация. Поэтому низкоуровневую оптимизацию могут делать только разработчики железа.
Я в свое время спрашивал ребят в ATI - почему ОНИ оптимизируют драйвера под игры, вместо того, что бы дать это на откуп самим разработкикам игр. Мне ответили, что это практически нереально без открытия всей внутренней кухни GPU, что разумеестя строгое ноухау.

#24
(Правка: 2:21) 2:20, 4 июня 2019

san
> Ты в принципе не можешь оптимизировать ассемблер, поскольку для этого надо
> знать микрокод и специфику архитектуры каждой карты.
Ты это сейчас про машинный код говориш. Я про ассемблерный.

> это далеко не микрокод, потому от ассемблерных шейдеров давно уже отказались.
Та што ты говоришь:
https://docs.microsoft.com/en-us/windows/desktop/direct3dhlsl/shader-model-5-assembly--directx-hlsl-
DXBC - это то, во что компилирует D3DCompile. Это то, что принимает CreateVertexShader (и прочие CreateXXXShader) первым параметром. Так вот, каждая инструкция DXBC соответствует инструкции этого самого sm5_asm. Один к одному.

В DirectX ты можешь устанавливать только скомпилированные DXBC (а для DX12 только DXIL) шейдера. Создать шейдер напрямую из HLSL кода нельзя. Скомпилировать HLSL код ты можешь вообще без видеокарты в системе. Это полностью оффлайновый компилятор. Так что OpenGL вполне мог специфицировать промежуточный ассемблерный язык (как Spir-V тот же). А вендоры этот ассемблер уже будут оптимизировать.

> что разумеестя строгое ноухау.
Не такое уж и строгое. Разработчикам под консоли (под NDA) выдают вполне годные тулзы. Тот же orbis от AMD. Так что если игра кроссплатформенная, а не только PC, то будь уверен, что все что нужно под оптимизацию у разработчиков скорее всего было.

#25
(Правка: 2:58) 2:31, 4 июня 2019

MrShoor
> Ты это сейчас про машинный код говориш. Я про ассемблерный.
> Скомпилировать HLSL код ты можешь вообще без видеокарты в системе.

Ты путаешь CSO и ассемблер. CSO это обьектный код к реальному микрокоду отношения не имеющий.


>Так что OpenGL вполне мог специфицировать промежуточный ассемблерный язык (как Spir-V тот же). А вендоры этот ассемблер уже будут оптимизировать.
Этот 'промежуточный язык' ничем не лучше исходного кода на HLSL/GLSL. Это не набор машинных инструкций, а последовательность вызовов функций. Реальное оптимизирование идет на уровне микрокода, а CSO и все подобное, это просто промежуточная прокладка, дабы не парсить каждый раз текст и не заниматься высокоуровневой оптимизацией. Оптимизация же на уровне обьектного кода тебе ничего не даст кроме лишнего геморроя.


>Разработчикам под консоли (под NDA) выдают вполне годные тулзы.
Там такое соглашение, что мама не горюй. Ну и не обольщайся, разработчики игр и Sony это немного разные вещи.  Разработчиков тысячи, Sony одна.

#26
2:49, 4 июня 2019

san
> Ты путаешь CSO и ассемблер. CSO это обьектный код к реальному микрокоду
> отношения не имеющий.
Если под CSO ты понимаешь compiled shader object, то для DX СSO - это и есть тот самый DXBC. Командам DXBC один в один соответствуют sm5_asm инструкции. И да, это не реальный микрокод, который будет исполнятся.

#27
2:51, 4 июня 2019

san
> Этот 'промежуточный язык' ничем не лучше исходного кода на HLSL/GLSL.
Лучше. Намного лучше. Потому что он прямой как палка. Нет никаких вложенных функций, инстуркции простые, и оптимизировать их проще.

#28
(Правка: 5:04) 3:01, 4 июня 2019

>Та што ты говоришь:
>https://docs.microsoft.com/en-us/windows/desktop/direct3dhlsl/shader-model-5-assembly--directx-hlsl-
Ты сам то этот текст читал? Там один-в-один функции из HLSL, немного разбавленные операциями типа mov (суть a=b;) и подобными. Поскольку HLSL/GLSL очень кастрированный язык (нет рекурсии, косвенной адресации и т.п.), то перевод его в этот псевдокод делается элементарно. Задача транслятора в CSO - выбросить все лишнее из исходника (неиспользуемые функции и все такое), раскрыть циклы и вместо вызовов функцй сделать их inline. Потом попробовать слегка соптимизировать то, что осталось. Сам перевод нотации делается практически линейно - там вообще нечего оптимизировать, все сделано до вас, и поверьте вы там ничего нового не изобретете.

Тебя наверно смущает термин - assembler. Но это совсем не тот ассемблер что на CPU. Это просто псевдокод, так правильнее.

P.S.
Кстати тебе никто не мешает писать на HLSL сразу как в OBJ. Выкинь все лишнее, вместо вызовов функций вставляй их код, разверни циклы - т.е. сделай линейную программу. Она будет переведена в то, что ты называеш "ассемблер" один в один.

#29
5:07, 4 июня 2019

san
> Тебя наверно смущает термин - assembler. Но это совсем не тот ассемблер что на
> CPU.
Не уж то ты думаешь, что ассемблер, который на CPU на современных процессорах исполняется как есть? :) Инструкция за инструкцией. Он так же как и в случае с GPU транслируется в свой внутренний код + оптимзируется на лету.

> Задача транслятора в CSO - выбросить все лишнее из исходника (неиспользуемые
> функции и все такое), раскрыть циклы и вместо вызовов функцй сделать их inline.
А так же
1. Cоптимизировать математические операции, чтобы когда например ты делаешь a + b в одном месте, и a + b  в другом - все это сделать одной инструкцией заранее.
2. Или например ты такой умножаешь mul(ViewProjectionMatrix, float4(0, 0, z, 1)), то выкинуть умножения на 0.
3. Или например ты делаешь pow(a, 8), а конпелятор превращает это в
mul r1, r0, r0
mul r2, r1, r1
mul r3, r2, r2
4. Или вытащить выборки из текстуры на самый верх так, чтобы они были сначала, а только потом работа с прочитанными данными (чтобы не ждать семплер)
5. и еще куча штук, которые делает hlsl компилятор

Короче да, за исключением этих 100500 вещей - это практически

Сам перевод нотации делается практически линейно

Дядь, ты вообще ассембреный выхлоп видел от hlsl? Тебе показать?

Страницы: 1 2 3 Следующая »
ПрограммированиеФорумГрафика