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

SPIR-V (3 стр)

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

Страницы: 1 2 3 4 58 Следующая »
#30
15:41, 6 янв. 2016

FROL
> Я так понимаю, что основная цель SPIR-V это именно замена Cи-подобных языков.
> То есть вместо glsl, hlsl и OpenCL C будет одно более простое представление.
> Чтобы драйверу было проще. Именно для этого и был сделан LLVM. Чтобы все
> производители устройство могли писать только 1 компилятор - более простой
> компилятор LLVM.
Вот это наркомания.
Нет, SPIR-V придуман был для того, чтобы являться промежуточным языком (как IL в DirectX, который со времен девятого директа существует).
CPU задачи на GPU выполнять сложно, поскольку заточены они под разные задачи и имеют немного совсем разную архитектуру.
SPIR-V придуман для (а скорее всего и с подачки) Valve и подобных им, которые кукарекают о том, что всё плохо, им надо помочь. Вот пусть там сидят и пишут компилятор с HLSL на SPIR-V, сложно им, видите-ли портировать.
4/5 команд, которые будут юзать вулкан, не будут ничего с этим SPIR-V делать и будут спокойно работать с GLSL компилятором.
На надо тут выдумок про LLVM, это нецелесообразно. Никто ничего заменять не собирается.

#31
16:07, 6 янв. 2016

FROL
> И тут совершенно без разницы кто его потом будет обрабатывать CPU или GPU.
А вот тут ты очень ошибаешься. ГП и ЦП есть совершенно разные чипы, предназначенные для решения совершенно разных задач и, соответственно, обладают очень разным набором инструкций.

FROL
> А так это странновато получается. Сначала взять LLVM, а потом его выкинуть ...
> почему?
Наверно, сначала они думали, как ты. Но потом на практике обнаружилось, что ГП и ЦП всё-таки слишком разные, чтобы использовать одно промежуточное представление.

#32
17:23, 6 янв. 2016

ArchiDevil
>Нет, SPIR-V придуман был для того, чтобы являться промежуточным языком (как IL в DirectX, который со времен девятого директа существует).
А LLVM тогда зачем был придуман? По-моему то же самое.

> На надо тут выдумок про LLVM, это нецелесообразно. Никто ничего заменять не
> собирается.
Ну как же не собирается? Как раз именно это они и собираются .

Delfigamer
> > И тут совершенно без разницы кто его потом будет обрабатывать CPU или GPU.
> А вот тут ты очень ошибаешься. ГП и ЦП есть совершенно разные чипы,
> предназначенные для решения совершенно разных задач и, соответственно, обладают
> очень разным набором инструкций.

Так а при чём здесь набор инструкций. Никто же не мешает добавлять новые инструкции как и в LLVM так и в SPIR-V.
Пожалуйста, используйте урезанный набор или наоборот, с добавлением новых инструкций.

Специфические инструкции (вроде mem fence или vote instructions) могут быть вообще говоря как у GPU так и у CPU c его out of order-ами, многоуровневыми кэшамии еще бог знает чем.
А векторные инструкции (в том числе dp4), это наоборот скорее тренд современных CPU нежели GPU (еще со времён 8800 процессоры у NV стали скалярные, хотя по-моему сейчас опять ожирели).

Опять же если бы были команды, работающие на уровне векторов размером в warp я бы с тобой согласился.
А еще лучше если бы весь код из них состоял.
А то что я вижу при поверхностном просмотре - это то же самое, такой же LLVM только с другим синтаксисом.
Обычное описание функции в 1 потоке и всё.

Давай поконкретнее тогда разберёмся - в чём именно существенное отличие. Это было бы интересно.

 

#33
17:40, 6 янв. 2016

FROL
> Обычное описание функции в 1 потоке и всё.
В GPU ничего не делается в одном потоке. Вообще ничего. (на самом деле в некоторых случаях работают)

> А векторные инструкции (в том числе dp4), это наоборот скорее тренд современных
> CPU нежели GPU
GPU не умеют работать не с векторными данными. (на самом деле это не совсем верно)

> А то что я вижу при поверхностном просмотре - это то же самое, такой же LLVM
> только с другим синтаксисом.
Да, принцип именно такой (да даже С++ сейчас так компилируется).
Только вот проблема в том, что GPU это железка очень узкого назначения, которая чуть шаг в сторону, так всё разваливается или работает медленно.
Они только недавно научились нормально с double-floating point работать.
Еще раз - на GPU нельзя работать так же, как и на GPU. И никогда не будет можно, потому что GPU это тупая числомолотилка (векторная многопоточная очень быстрая молотилка, жрущая сразу огромные буферы данных), а CPU значительно умнее, хоть и на порядки медленнее.

#34
18:31, 6 янв. 2016

ну FROL вообще-то прав, в том что набор gpu инструкций может быть составлен из набора SIMD современных процессоров (есть же OpenCL)
может добавление инструкций gpu в LLVM поможет компиляторам векторизовать код

#35
21:09, 6 янв. 2016

Delfigamer
> FROL
> > А так это странновато получается. Сначала взять LLVM, а потом его выкинуть ...
> > почему?
> Наверно, сначала они думали, как ты. Но потом на практике обнаружилось, что ГП
> и ЦП всё-таки слишком разные, чтобы использовать одно промежуточное
> представление.
Ну или Кронос сами не знают, чего хотят, и меняют форматы чисто от балды, ага.
Ещё вариант - по какой-нибудь причине SPIR-V драйверу распарсить проще, чем LLVM. А можно спросить у них самих.
Помнится, у Кроноса на сайте было что-то про независимость написано.

#36
21:23, 6 янв. 2016

ArchiDevil
> SPIR-V придуман для (а скорее всего и с подачки) Valve и подобных им, которые
> кукарекают о том, что всё плохо, им надо помочь. Вот пусть там сидят и пишут
> компилятор с HLSL на SPIR-V, сложно им, видите-ли портировать.
> 4/5 команд, которые будут юзать вулкан, не будут ничего с этим SPIR-V делать и
> будут спокойно работать с GLSL компилятором.
Ой да ладно. Я лично буду рад, если смогу свой GLSL код транслировать в SPIR-V в момент билда продукта. Зоопарк когда каждый вендор пилит свой GLSL компилятор - бред и оттестировать продукт на этапе разработки становится нереально.

#37
23:26, 6 янв. 2016

MrShoor
> Зоопарк когда каждый вендор пилит свой GLSL компилятор - бред и оттестировать
> продукт на этапе разработки становится нереально.
Поэтому никому этот ваш OpenGL и не нужен.

#38
10:18, 12 янв. 2016

clc
В GPU не SIMD, там в целом MIMD с планировщиком скрещенный на уровне ISA отдельных ядер либо с чистым  VLIW, либо с гибридом VLIW/SIMD и разными дополнительными охренительными историями вроде предикатного выполнения. И это только на уровне непосредственно самого вычислительного ядра.
C CPUшным SIMD там даже близко не.

#39
10:46, 12 янв. 2016

MrShoor
> Зоопарк когда каждый вендор пилит свой GLSL компилятор - бред и оттестировать
> продукт на этапе разработки становится нереально.
простите, а кто должен писать компиляторы для разных по архитектуре карт, и кто за это будет платить?

#40
11:23, 12 янв. 2016

ArchiDevil
> Поэтому никому этот ваш OpenGL и не нужен.

Прикольно, 90% товаров от чайников и до машин спроектированы на CAD, которые на GL :)

#41
12:01, 12 янв. 2016

На автокаде всего 10% что ли?

#42
12:03, 12 янв. 2016

kipar
> На автокаде всего 10% что ли?
ЧСХ, автокад тоже OpenGL.

#43
12:57, 12 янв. 2016

Mahagam
Под виндой - DX. Ну и понятно что это только уровень непосредственного рисования, основная то часть во всех CAD все равно на CPU.

#44
13:01, 12 янв. 2016

kipar
> Под виндой - DX.

Это только последние несколько лет

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

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