The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Улучшение открытых драйверов Radeon: интеграция UVD в Mesa, ..., opennews (?), 15-Апр-13, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


46. "Улучшение открытых драйверов Radeon: интеграция UVD в Mesa, ..."  +1 +/
Сообщение от ананим (?), 15-Апр-13, 13:35 
llvm там не только (и не столько) для opencl, сколько для самих драйверов (и шейдеров), тк дрова то для амд на галиум (кстати интел предложила и потом отказалась от этой архитектуры, если склероз не врёт).

А вообще да, верно (плюс ещё vdpau, плюс управление питанием и тд по-мелочи).
Это вон умнику с ником аризу свою реализацию opengl написать как 2-а пальца, а на практике очень сложная и объёмная задача на уровне всех иксов с глибц в придачу.
А если ещё учесть лавирование между патентами...

Ответить | Правка | Наверх | Cообщить модератору

56. "Улучшение открытых драйверов Radeon: интеграция UVD в Mesa, ..."  +1 +/
Сообщение от Аноним (-), 15-Апр-13, 14:35 
> llvm там не только (и не столько) для opencl, сколько для самих
> драйверов (и шейдеров), тк дрова то для амд на галиум

Там есть и режим без LLVM - в драйвере и свой местечковый генератор кода шейдеров есть. Он кстати пока затыкает этот самый LLVM по оптимальности сгенеренного кода, так что LLVM по дефолту вообще не активирован. LLVM генерит код для VLIW еще хуже чем код для х86 и ARM. Потому что он изначально вообще ни в зуб ногой о том чот такое VLIW и какие там ограничения на поток команд и как это оптимизить под максимально параллельное выполнение. Это кой-как минимально приводится до валидного состояния отдельным костылем в отдельном проходе. По поводу чего выбор LLVM вообще вызывает много вопросов и нареканий. Похоже амдшники его взяли в основном из соображений что на нем OpenCL будет проще реализовать.

Ответить | Правка | Наверх | Cообщить модератору

61. "Улучшение открытых драйверов Radeon: интеграция UVD в Mesa, ..."  +/
Сообщение от ананим (?), 15-Апр-13, 14:56 
Всё это верно, но время на набивание шишек то ушло, тк никто до этого это просто не делал.
(Вот и тема инноваций всплыла)

Зыж
Но согласитесь, в теории это звучало более чем заманчиво.

Ответить | Правка | Наверх | Cообщить модератору

67. "Улучшение открытых драйверов Radeon: интеграция UVD в Mesa, ..."  +/
Сообщение от Аноним (-), 15-Апр-13, 15:06 
> Но согласитесь, в теории это звучало более чем заманчиво.

Ну как бы на практике врядли кто захочет сам писать полновесный OpenCL компилятор самолично. Интел правда грозился показать всем кузькину мать, сделав сие самолично под свою архитектуру. Если осилят - пожалуй зады у конкурентушек малость надерутся, да. Т.к. кодогенератор под конкретную архитектуру имеет все шансы быть куда оптимальнее чем хрень которая про VLIW вообще ничего не знает и после которой поток команд приводится до хотя-бы просто технически валидного состояния которое сможет прожевать такой процессор отдельно стоящим костылем.

Но какая из стратегий возьмет в долговременном плане - это будет интересно посмотреть.

Ответить | Правка | Наверх | Cообщить модератору

70. "Улучшение открытых драйверов Radeon: интеграция UVD в Mesa, ..."  +/
Сообщение от ананим (?), 15-Апр-13, 15:33 
>Т.к. кодогенератор под конкретную архитектуру имеет все шансы быть куда оптимальнее чем хрень которая про VLIW вообще ничего не знает

Ну так надо всего-лишь, чтобы эта «хрень» узнала… Теоретически.

Ответить | Правка | Наверх | Cообщить модератору

71. "Улучшение открытых драйверов Radeon: интеграция UVD в Mesa, ..."  +/
Сообщение от Аноним (-), 15-Апр-13, 16:12 
> Ну так надо всего-лишь, чтобы эта «хрень» узнала… Теоретически.

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

А сейчас уже немного поздно пить боржоми: проект уже реализован. И оно такое хорошее было совсем не в курсе что такое VLIW и как ему надо команды по нормальному генерить. АМДшники ухайдакали массу ресурсов на прыг по граблям и зверский костылинг чтобы вообще получить просто технически валидный поток команд который VLIW потом вообще в принципе сможет прожевать. Об оптимальности этого потока команд... ну вы поняли.

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

Теоретически, кастомный кодогенератор сильно использующий это мог бы всем надрать попы. Практически, сделать хороший компилер под VLIW - рокетсайнс и брейнфак. И отсутствие хороших компилеров, изначально задизайненых под VLIW и оптимальное использование его особенностей - всегда икалось VLIWам. Итанику вон тоже икалось, например.

Ответить | Правка | Наверх | Cообщить модератору

73. "Улучшение открытых драйверов Radeon: интеграция UVD в Mesa, ..."  +/
Сообщение от Аноним (-), 15-Апр-13, 16:35 
На википедии пишут: "В последнем поколении (Southern Islands) компания AMD/ATI отошла от подхода VLIW". Возможно теперь будет смысл использовать LLVM?
Ответить | Правка | Наверх | Cообщить модератору

79. "Улучшение открытых драйверов Radeon: интеграция UVD в Mesa, ..."  +/
Сообщение от Аноним (-), 15-Апр-13, 18:41 
> На википедии пишут: "В последнем поколении (Southern Islands) компания AMD/ATI отошла от подхода VLIW".

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

все не извиняет того что в претендующем на универсальность решении пробакланили целый класс процессоров. Хотя на момент начала работ над LLVM про VLIW уже все знали. Ну понятно что яблочку оно не надо было, гули. Их только x86 и ARM волнуют. А амдшники в результате по сути др@^W вприсядку с неудобной конструкцией уйму времени без каких-то шедевральных успехов. Так что те кто втирает что там какая-то супер-архитектура - как минимум многовато звиздят.

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

Ответить | Правка | Наверх | Cообщить модератору

75. "Улучшение открытых драйверов Radeon: интеграция UVD в Mesa, ..."  +/
Сообщение от agente (?), 15-Апр-13, 17:33 
как раз таки llvm  включен по умолчанию если собрано  с его поддержкой, и там разницы особо нету, пару процентов плюс\минус. есть некий Vadim Girlin который пилит свой r600-sb  бекенд, но когда я его тестил да а хеавене прирост отличный, остальные игры не реагировали либо падали.
Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

80. "Улучшение открытых драйверов Radeon: интеграция UVD в Mesa, ..."  +1 +/
Сообщение от Аноним (-), 15-Апр-13, 18:45 
> как раз таки llvm  включен по умолчанию если собрано  с его поддержкой,

Вот только обычно с ним то как раз и не собирают. Т.к. он глючный и тормозной. Можете посмотреть в рассылке как Вадим Гирлин разогнал парой патчей местечковый кодогенератор. И как он плевался что то же самое в LLVM - на порядки сложнее.

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

> и там разницы особо нету, пару процентов плюс\минус. есть
> некий Vadim Girlin который пилит свой r600-sb  бекенд, но когда
> я его тестил да а хеавене прирост отличный, остальные игры не
> реагировали либо падали.

Проблема даже не в том. Проблема в том что ту же самую оптимизацию под LLVM запилить - в разы больше геморроя. А вот это - очень плохое свойство, да. И вообще - генерация кода для VLIW там сделана через адовые костыли - на то что нагенерил LLVM напускается отдельная фаза которая исправляет поток команд так что GPU его хотя-бы прожевать сможет. С гуя ли нато так жосска костылить "архитектурно правильный" LLVM - очень интересный вопрос. На момент его разработки VLIW уже не первый год существовали.

Ответить | Правка | Наверх | Cообщить модератору

85. "Улучшение открытых драйверов Radeon: интеграция UVD в Mesa, ..."  +/
Сообщение от agente (?), 15-Апр-13, 19:19 
если нужен opencl\uvd\radeonsi то без llvm не собрать.
Я читал рассылку и тестил все собственноручно, кроме хевена нигде супер выйгрыша  видно не было.
На ванильной месе, для производительности, нет никакой  хоть сколько-нибудь заслуживающей внимания разницы с llvm или без.
Ответить | Правка | Наверх | Cообщить модератору

88. "Улучшение открытых драйверов Radeon: интеграция UVD в Mesa, ..."  +/
Сообщение от Аноним (-), 15-Апр-13, 19:36 
> если нужен opencl\uvd\radeonsi то без llvm не собрать.

Не совсем понял как UVD стыкуется с llvm.

> Я читал рассылку и тестил все собственноручно, кроме хевена нигде супер выйгрыша видно не было.

Я сомневаюсь что вы смогли протестировать вообще все возможные в мире варианты шейдеров, простите великодушно :).

Основная проблема в том что на их кастомного кодогенераторе перец "пришел, увидел, победил". Для LLVM потребовалось бы намного больше усилий для того же результата. При том что LLVM вообще ничего такого особого сам по себе не предлагает. Называя вещи своими именами, он генерит код для GPU на уровне плавания топора по реке. После нескольких лет въе... над этим крапом достижения сводятся к "способен наконец сгенерить код который можно скормить GPU" и "не очень сильно сливает кастомному кодогенератору". Не больно какое привлекательное соотношение затрат усилий к результату.

> На ванильной месе, для производительности, нет никакой  хоть сколько-нибудь
> заслуживающей внимания разницы с llvm или без.

Вот я и думаю - если б они несколько лет повъе вместо этого дурацкого LLVM с той же интенсивностью над кастомным кодогенератором - результат бы поражал воображение. В общем это имхо было довольно дурным решением.

Ответить | Правка | Наверх | Cообщить модератору

91. "Улучшение открытых драйверов Radeon: интеграция UVD в Mesa, ..."  +/
Сообщение от agente (?), 15-Апр-13, 19:54 

> Не совсем понял как UVD стыкуется с llvm.

Коммит поддержки UVD перед вами, сорцы есть, без llvm UVD не будет.

> Я сомневаюсь что вы смогли протестировать вообще все возможные в мире варианты шейдеров, простите великодушно :).

И не было в целях, запуская всякие нативные игры с R600_DEBUG=nollvm и без, разницы ~0

Ответить | Правка | Наверх | Cообщить модератору

136. "Улучшение открытых драйверов Radeon: интеграция UVD в Mesa, ..."  +1 +/
Сообщение от Аноним (-), 16-Апр-13, 18:36 
> И не было в целях, запуская всякие нативные игры с R600_DEBUG=nollvm и без, разницы ~0

Все бы ничего, НО называя вещи своими именами, на допиливание этого крапа парнями из АМД было убито несколько лет. С нулевым user-visible result'ом. По поводу чего к нему и претензии. Это довольно нерациональное использование ресурсов, мягко говоря. При том если оптимизации LLVM сложнее чем местечкового кодогенератора - опять же плохо. Гиря на ногах тем кто будет пытаться оптимизнуть производительность. Зачем?

Ответить | Правка | Наверх | Cообщить модератору

95. "Улучшение открытых драйверов Radeon: интеграция UVD в..."  +1 +/
Сообщение от arisu (ok), 16-Апр-13, 00:29 
> С гуя ли нато так жосска
> костылить «архитектурно правильный» LLVM — очень интересный вопрос. На момент его
> разработки VLIW уже не первый год существовали.

яблоку «вливы» неинтересны.

Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

135. "Улучшение открытых драйверов Radeon: интеграция UVD в..."  +1 +/
Сообщение от Аноним (-), 16-Апр-13, 18:32 
> яблоку «вливы» неинтересны.

Да... Кэпа перекапитанил другой, более суровый Кэп.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру