Тёмная тема
san
Прочитай книгу дракона про компиляторы, плиз. И не пиши бред. Компиляция очень не линейная.
DirectX это GAPI от Майкросовт.
OpenGL это стандарт GAPI от Кронуса и реализация от кого угодно.
lookid
> Прочитай книгу дракона про компиляторы, плиз. И не пиши бред. Компиляция очень не линейная.
Ты ветку читал, или сразу комментировать полез? Где я писал, что "компиляция линейна"? Я написал, что перевод нотации HLSL в CSO после раскрытия функций и циклов делается по сути линейно. Весь смысл в том, что перевод HLSL в CSO никакой компиляцией не является и ассемблерный код не порождает. Создается обьектный псевдокод (системно-независимый), который в дальнейшем обрабатывается уже драйвером. Где и генерируется собственно команды для GPU. Доступно излагаю?
MrShoor
> Дядь, ты вообще ассембреный выхлоп видел от hlsl? Тебе показать?
Опять полез пиписьками меряться? Аргументы кончились?
san
Он тебе про то, что DX на выхлопе даёт скомпилированный объектник, который вендору будет ощутимо проще преобразовать в свой формат. Свой компилятор конечно может быть эффективней в некоторых моментах, но от него больше минусов - относительная сложность реализации, легаси костыли, разные компиляторы = разные баги.
san
> Весь смысл в том, что перевод HLSL в CSO никакой компиляцией не является и
> ассемблерный код не порождает.
Если что этот самый CSO элементарно превращается в ассемблер. Один к одному транслируется. Так что CSO можно считать "бинарным форматом ассемблера". Просто бинарный формат проще, чем парсить текстовый файл даже такой простой вещи как ассемблер. А вот сам cso - и близко не линейная трансляция от hlsl.
После шейдерного ассемблера уже не должно быть заметных оптимизаций от вендора.
По сути у вендора могут отличаться микрокоды, или какие то операции "эмулироваться" последовательностью команд.
Один хрен весь гемор ложится на разработчика по с учетом особенности работы команд на разных hw
Что такое DirectX Graphics?
Программа обработки видео. видеодрайвер. показать там кружок,треугольник,и все эти крутые 3д.
тему можно закрывать.
Mira
> После шейдерного ассемблера уже не должно быть заметных оптимизаций от вендора.
Т.е. вы считаете, что оптимизация игр вендорами сводится к исправлению обьектного кода шейдеров? И весь этот список https://www.nvidia.com/en-us/geforce/geforce-experience/games/ это просто замена родных шейдеров на исправленные нвидией? Поверьте, это совсем не так.
Я пытаюсь вам обьяснить, что "ассемблерный код" в случае GPU не является тем, что называется классическим ассемблером. Он не превращается в микрокод механически. Это просто линейная последовательность функций (обьектный код), которые могут иметь совершенно различную реализацию для разных вендоров и архитектур. Вы конечно можете (и должны) оптимизировать свой шейдер на уровне логики (ну например вы сначала читаете несколько текстур, а потом используете только часть из них), но это делается на уровне HLSL, ассемблерный код вам мало что даст в плане оптимизации. У вас нет доступа к реальной последовательности операций производимой GPU, а транслятор от Микрософт достаточно хорошо вылизан.
san
можно сказать что это ассемблер. в асме думаешь один опкод = одному байткоду?
там только jmp и call может транслироваться в итоге в несколько разных команд в зависимости от способа вызова или длины перехода.
ассемблер GPU отличает больший разброс опкодов , в том числе зависящий от производителя + замена некоторых опкодов последовательностью единичных операций.
джифорс экспириенс насколько я помню, не изменяет логику внутреннего конпеллятора а подстраивает тонкие настройки адаптера под конкретную игру и конкретное железо ПК, чтоб сбалансировать производительность и качество. не париться врукопашку с этими настройками фильтрации и прочей лабуды под каждую запущенную игру.
Mira
> можно сказать что это ассемблер. в асме думаешь один опкод = одному байткоду?
Разумеется нет, но они связаны жестко. Что до "ассемблера GPU" то это очень интересный ассемблер где нет регистров, доступа к памяти, доступа к процессору, потокам и т.д. Т.е это ассемблер без доступа к железу. Называть это ассемблером... ну очень смело.
> джифорс экспириенс насколько я помню, не изменяет логику внутреннего конпеллятора а подстраивает тонкие настройки адаптера под конкретную игру и конкретное железо ПК, чтоб сбалансировать производительность и качество
О чем и речь. Вендоры не шейдера оптимизируют, а их взаимодействие с железом, к которому у разработчиков игр нет доступа. И там иногда скорость вырастает весьма существенно. А ковыряться в обьектном коде (который ошибочно тут называют ассемблером), это пытаться улучшить микрософтовский компилятор. Ну может на каких-то тонких эффектах это и даст 1-2% производительности, но городить весь огород ради этого...
ладно , это не тот вопрос за который стоит воевать)
PS я всегда считал DirectXGraphics не GAPI а выродком DXSDK , тоесть интерфейсы с собственно директиксом + набор инструментария и вспомогательных векторных библиотек. ну там матрицы считать чтоб SIMD и высокоуровневые интерфейсы, ранее бывшие в D3DXxx
Mira
> в асме думаешь один опкод = одному байткоду?
опкод=?
байт-код=?
Rikk
> опкод=?
> байт-код=?
?????
https://archive.org/stream/SNESDevManual/book2#page/n89/mode/2up
Super Nintendo16bit snes sdk
book2, стр90
секция 2-1-1
пример графического процессора(видеокарта) SuperFX1. на момент 1991г это было высочайшая революционная технология которая была даже выше чем пк.
parallel operation with supernes cpu — параллельность
стр96—блок-схема гпу. блоки : регистры операции умножитель кэш, дешифратор команд
стр100-instruction set—набор инструкций. это похоже на вполне обыденный assembler cpu
Rikk - виртуал морфии?
monobogdan
> Rikk - виртуал морфии?
это риторический вопрос не имеющий смысла и автоматически не требующий ответа
