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

SPIR-V (2 стр)

Advanced: Тема повышенной сложности или важная.

Страницы: 1 2 3 48 Следующая »
#15
22:11, 5 янв. 2016

Разбираю код в спеках (spirv.pdf стр 11). Пока что примерно ясно, как должен выглядеть пустой void main().
Пример фрагментного шейдера на glsl и соответствующий код на spir-v

+ glsl
+ spirv

Разбор полетов:
Пока не будем затрагивать ту часть где инициализация и прочие детали.
Имхо, начать стоит с простого определения void main() {}.
Все написанное далее не более чем имхо:

9        OpEntryPoint Fragment %4 "main" %22 %38 %20
+ OpEntryPoint

Тут мы объявляем точку входа, используя OpEntryPoint. "Fragment" в 9 строке говорит, что эту точку входа следует использовать для фрагментного шейдера.
Далее идет идентификатор функции, которая будет использоваться как точка входа и имя точки входа. Соответственно, функция, которую мы объявим под идентификатором %4 и будет вызываться в шейдере. Похоже на то, что имя "main" указанное тут, совсем не обязано совпадать с именем, которое мы потом привяжем к нашему объекту-функции.
Последние три параметра, внешние переменные(атрибуты), к которым будет иметь доступ функция точки входа. Т.е. объекты с идентификаторами %22, %38 и %20, будут in/out атрибутами шейдера.
13        OpName %4 "main"
16        OpName %20 "color"
17        OpName %22 "color1"
23        OpName %38 "color2"
+ OpName

Судя по комментарию, эта часть важна только для дебагера. Конкретно эта строка говорит, что использовав OpName, мы хотим определить для идентификатора %4 имя "main".
Далее, в строках 16, 17 и 23, мы забиваем имена нашим идентификаторам %20, %22 и %38 соответственно.
29        %2 =    OpTypeVoid
30        %3 =    OpTypeFunction %2 ; void ()
+ OpTypeVoid
+ OpTypeFunction

Используя OpTypeVoid в 29 строке, под идентификатором %2 мы объявляем тип, который будет возвращать наша функция(void).
Лирическое отступление: Я пока без понятия, можем ли мы использовать эго для других функций, которые тоже возвращают void, или же для них нужно объявлять свой void, со своим id.
В 30 строке, под id %3, мы объявляем тип, который будем использовать для нашей функции main.
60        %4 =      OpFunction %2 None %3 ; main
+ OpFunction

Тут мы объявляем нашу функцию main. Первый параметр - тип возвращаемого значения, второй - хз, третий - тип(ранее объявленный нами в строке 30) функции.
Лирическое отступление: Вот тут дублируются данные. Почему мы опять указываем возвращаемый тип %2, если уже сделали это при объявлении типа функции?
Далее должны идти инструкции OpFunctionParameter для каждого аргумента, но т.к. аргуметнов нет, то и соответствующих инструкций не последовало.
100        OpReturn
101        OpFunctionEnd
+ OpReturn
+ OpFunctionEnd

Строка 100, очевидно, возвращает значение и прекращает работу функции.
Строка 101 объявляет завершение описания функции, т.е. нашей %4 начатой в 60 строке.

Судя по спекам - не сильно промахнулся.

#16
23:36, 5 янв. 2016

Судя по Vulkan SDK, в спир-в будет компилироваться обычный GLSL. Даже переделывать ничего не понадобится.

#17
0:06, 6 янв. 2016

ArchiDevil
Неужели на уровне spir нельзя будет выжать больше производительности?

#18
0:26, 6 янв. 2016

The Player

почему ты считаешь что оно должно быть быстрее? Это же просто стандартизированное обобщённое представление и его ещё надо компилировать в конечное. Так или иначе все шейдеры сначала компиляться в промежуточный вариант.

#19
0:30, 6 янв. 2016

The Player
> Неужели на уровне spir нельзя будет выжать больше производительности?
С чего бы? Обычный ассемблер, не надо быть умнее компилятора.

#20
0:57, 6 янв. 2016

Затея то хорошая, но мне вот непонятно, неужели нельзя было расширить SPIR 2.0 добавив просто новые инструкции в LLVM.
Ну зачем 100% Khronos defined. Ассемблер он и есть ассмеблер. Что там можно нового придумать.

Ведь теряется весь смысл этой затеи. Для LLVM уже столько компиляторов есть.
А тут будет ещё одна промежуточная стадия трансляции из LLVM в этот SPIR-V.
А это значит дополнительная возможность для ошибок.

#21
4:22, 6 янв. 2016

FROL
> Затея то хорошая, но мне вот непонятно, неужели нельзя было расширить SPIR 2.0
> добавив просто новые инструкции в LLVM.
LLVM создан для процессоров общего назначения. Отсюда целый ряд вещей с нём или нету, или будут инородными. Ты забываешь что у видюхи кроме того что регистры и операции векторные есть ещё и всякие семплеры, текстуры, параметры лерпа регистров и прочая лабуда.

#22
9:43, 6 янв. 2016

clc
ArchiDevil
Ну я не говорю о приросте производительности за просто так.
Просто, возможно будут места, где на уровне spir можно будет провести оптимизацию, которую не сделаешь в glsl.

#23
12:19, 6 янв. 2016

Bishop
> Ты забываешь что у видюхи кроме того что регистры и операции векторные есть ещё
> и всякие семплеры, текстуры, параметры лерпа регистров и прочая лабуда.
А почему это проблема? Почему в LLVM всё это не добавить?

#24
12:42, 6 янв. 2016

slava73
> Почему в LLVM всё это не добавить?
Зачем?

#25
12:43, 6 янв. 2016

Bishop
>>семплеры, текстуры, параметры лерпа регистров и прочая лабуда.

slava73
>>А почему это проблема? Почему в LLVM всё это не добавить?

Ну собственно да, в OpenCL 2.0 это же всё есть и добавили ведь. И операторы синхронизации и прочее.
Зачем было отказываться от LLVM в пользу своего ассемблера. Разве что он у них проще ...

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

#26
12:48, 6 янв. 2016

Кучу кода занимает декларация лишь одного out атрибута...

31    %6 =    OpTypeFloat 32 ; 32-bit float
32    %7 =    OpTypeVector %6 4 ; vec4
40    %19 =  OpTypePointer Output %7 ; out vec4
41    %20 =  OpVariable %19 Output ; color
+ OpTypeFloat
+ OpTypeVector
+ OpTypePointer
+ OpVariable

Тут все просто. Декларируем 32-битный float тип, на эго основе декларируем векторный тип, на основе векторного - декларируем тип указателя и наконец-то, создаем саму переменную.

#27
12:59, 6 янв. 2016

FROL
> Потому что для LLVM уже есть много готовых компиляторов.
Не верно.
Есть куча софта для кода для ЦП, а вот для ГП - ноль, если только ребята из нВидии не пользовали LLVM в своих дровах, что мне кажется малловероятным.

#28
13:12, 6 янв. 2016

Вопрос, который почему-то раньше и не всплывал...
А где сейчас можно потестить SPIR-V код?

#29
15:16, 6 янв. 2016

Delfigamer
> Есть куча софта для кода для ЦП, а вот для ГП - ноль
Ну честно говоря разница не очевидна. Это же нужно для написания своих фронт-эндов.
Промежуточное представление, которое все-равно будет обрабатываться компилятором. И тут совершенно без разницы кто его потом будет обрабатывать CPU или GPU.
Ты же все-равно пишешь код для GPU на си-подобном языке. Чем-то кардинально glsl от си не отличается. Ну подумаешь векторные операции есть, это не существенно.
Примитивы синхронизации и прочие вещи вроде dFdx тоже спокойно выражаются обычными функциями и операторами.
То что там всё подряд инлайнится - так это тоже может зависеть от реализации (например Xeon Phi может делать по другому).

Я так понимаю, что основная цель SPIR-V это именно замена Cи-подобных языков. То есть вместо glsl, hlsl и OpenCL C будет одно более простое представление.
Чтобы драйверу было проще. Именно для этого и был сделан LLVM. Чтобы все производители устройство могли писать только 1 компилятор - более простой компилятор LLVM.

Я готов согласиться с тем утверждением, что возможно для GPU компилятора нужно ещё более простое представление, чем LLVM.
Наверное и компиляторы проще и компиляция быстрее будет ... мне было бы интересно понять преимущество собственного представления SPIR-V над LLVM.
Пока не очевино тем более что в SPIR 2.0 как раз на основе LLVM. Я понимаю еще если бы он сразу был другим.
А так это странновато получается. Сначала взять LLVM, а потом его выкинуть ... почему?


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

Тема в архиве.