The OpenNET Project / Index page

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



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

Оглавление

Представлен RV64X, открытый GPU на базе технологий RISC-V, opennews (ok), 01-Фев-21, (0) [смотреть все]

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


168. "Представлен RV64X, открытый GPU на базе технологий RISC-V"  +1 +/
Сообщение от Ordu (ok), 01-Фев-21, 20:38 
> и получать качество уровня первого дума.

Нет. Doom и Quake хоть и базировались на софтварном рендеринге, но этот рендеринг выполнялся на доисторических x86, в которых даже SSE не было. Плюс тактовые частоты порядка 100MHz. Сегодня кваку софтварно можно гонять на очень больших разрешениях, ограничением будет скорее пропускная способность шины, нежели возможности процессора к исполнению максимального числа инструкций.

> Это вопросы к M$ и Кроносу с их прямохерами и пулканами.

Не, это вопросы к nvidia и ей подобным. Во времена Doom'а и Quake, я общался с видеокартой напрямую, и никакие API-обёртки мне были не нужны. Сейчас... не, ты попробуй сейчас отрисовать что-нибудь amd'шным gpu, без огромного драйвера. Если его в vesa режим вогнать то можно, конечно, но vesa -- это ведь труп того же VGA, который финально умыли, причесали, нарядили в парадный костюм перед тем как закопать.

Давно уже напрашивается иметь в качестве видеокарты отдельный специализированный компьютер, с GPU оформленным как процессор общего назначения с кучей специализированных ядер. Чтоб я туда грузил бы код, занятый отрисовкой, и а потом каждый кадр скидывал бы ему обновления сцены. Или, скажем, я б туда загрузил декодер av1, и гнал бы туда пожатый в av1 поток видео, а оно бы декодировало и рендерило бы. Или я б там Xorg сервер запустил бы, а на стороне CPU крутился бы маленький драйвер, чьей задачей было бы эмулировать сокет X'ов, и какие-нибудь экстеншны типа mit-shm.

Впрочем X'ы упустили эту возможность. Им бы с самого начала ещё в 80-х принять бы в мейнстрим возможность для клиента выполнять код в контексте X-сервера, тогда сейчас естественным развитием был бы вынос X-сервера в фирмварь для GPU. Но сейчас уже поздно пить боржоми, я подозреваю, X'ы не дожили до своего звёздного часа.

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

175. "Представлен RV64X, открытый GPU на базе технологий RISC-V"  –1 +/
Сообщение от Онаним (?), 01-Фев-21, 21:16 
> Давно уже напрашивается иметь в качестве видеокарты отдельный специализированный компьютер

У меня для тебя плохие новости - GPU - это и есть отдельный специализированный компьютер.
Процессора общего назначения в нём нет, но он там и не нужен, потому что чтобы на эту числодробилку выдать нужный объём работы - нужен нехилый CPU, и требования к CPU также растут постоянно. Ставить CPU в GPU бессмысленно - ты этим самым просто ограничишь пользователя его возможностями. А ставить всегда такой CPU, чтобы однозначно не ограничить - будет дорого. Плюс ему надо будет свою память ставить отдельную, разводить I/O, и т.п., а место на видеоадаптере не безгранично.

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

204. "Представлен RV64X, открытый GPU на базе технологий RISC-V"  +/
Сообщение от Ordu (ok), 02-Фев-21, 00:16 
>> Давно уже напрашивается иметь в качестве видеокарты отдельный специализированный компьютер
> У меня для тебя плохие новости - GPU - это и есть
> отдельный специализированный компьютер.

Да. Так почему бы не довести это до логического завершения?

> Процессора общего назначения в нём нет, но он там и не нужен,
> потому что чтобы на эту числодробилку выдать нужный объём работы -
> нужен нехилый CPU, и требования к CPU также растут постоянно.

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

> Ставить
> CPU в GPU бессмысленно - ты этим самым просто ограничишь пользователя
> его возможностями.

Бла-бла-бла. Каким образом?

> А ставить всегда такой CPU, чтобы однозначно не ограничить
> - будет дорого. Плюс ему надо будет свою память ставить отдельную,
> разводить I/O, и т.п., а место на видеоадаптере не безгранично.

Зачем ему ставить отдельную память? О каком I/O речь идёт? Всё что ему нужно -- доступ к PCI и к видеопамяти.

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

223. "Представлен RV64X, открытый GPU на базе технологий RISC-V"  +/
Сообщение от Аноним (186), 02-Фев-21, 01:11 
Disclaimer: я не тот придурок с левыми теориями...

> Зачем ему ставить отдельную память? О каком I/O речь идёт? Всё что
> ему нужно -- доступ к PCI и к видеопамяти.

Вообще, local storage, обычно прямо на кристалле рядом с соотв. блоком - делают. Для немедленного хранения добра вотпрямща.

Видеопамять - она где-то там. GDDR и проч может показать впечатляющий бандвиз на линейных операциях, но не особо быстро разворачивается на конкретно вот этот доступ, а потом совсем другой. Так неэффективно. Обычный DDR  ... заметно хуже на больших линейных доступах характерных для графики.

А pci - он вообще где-то там. Конечно подперто dma со всех сторон и проч но латенси всего этого...

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

219. "Представлен RV64X, открытый GPU на базе технологий RISC-V"  +/
Сообщение от Аноним (-), 02-Фев-21, 01:03 
> Процессора общего назначения в нём нет, но он там и не нужен,

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

> потому что чтобы на эту числодробилку выдать нужный объём работы -
> нужен нехилый CPU, и требования к CPU также растут постоянно.

Локальный CPU имеет некий плюс: шиной не подперт. И для каких-нибудь вычислений и проч может очень удачно менеджить вгрузку задания и забор результатов, с оффлоадом остального от этого - и отсутствием нужды выполнять дикую камасутру с (полу)(недо)(квази)хардварными блоками которые в общем то сделают то же самое, но - с кучей дурных трабл по пути.

> Ставить CPU в GPU бессмысленно - ты этим самым просто ограничишь пользователя
> его возможностями. А ставить всегда такой CPU, чтобы однозначно не ограничить
> - будет дорого. Плюс ему надо будет свою память ставить отдельную,
> разводить I/O, и т.п., а место на видеоадаптере не безгранично.

Не вижу чему такому противоречит комплекс массивов, каждый с своим CPU для локального менеджмента заданий и массивом числокрушилок. Собственно GCN что-то отдаленно напоминающее это и есть, пачки числодробилок выделены в копипастабельный логически завершенный блок. С чего вдруг 1-2 ядра для выделенного адекватного менеджмента такого блока дичь - а кто б его знает?

> Плюс ему надо будет свою память ставить отдельную

Зачем? Некий турбо-быстрый local storage на кристалле + доступ в общую шину и какие там еще контроллеры, если надо реально дофига. АМД как-то так и делает в GCN опять же.

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

258. "Представлен RV64X, открытый GPU на базе технологий RISC-V"  +/
Сообщение от Онаним (?), 02-Фев-21, 09:51 
>  АМД в GCN вместо хтонического VLIW который никто толком прогать не может нормально сделал нечто заметно более похожее на обычный процессор

Так и я о том. Убрали VLIW с фронта и сделали нормальный GPU вместо вывешенного голым задом ядра исполнения :D

> С чего вдруг 1-2 ядра для выделенного адекватного менеджмента такого блока дичь

Да оно не дичь, но оно должно успевать кормить эти блоки данными. То есть в идеале туда придётся ставить те же полноценные высокочастотные модули от зенов например, а они далеко не холодные. Ну и опять же память отдельную, I/O и т.п.

С доступом в общую шину будет проблемка - если заставить исполнять из видеопамяти - передерутся с самими модулями GPU, их паттерны обращения хорошо предсказуемы, а у CPU общего назначения - нет. Можно заставлять локальный CPU ждать, как центральный CPU при обмене через PCIe, но тогда вообще смысл локального CPU теряется. Если дать доступ к системной памяти через PCIe - передерутся с системным CPU и общая производительность в итоге всё равно будет так себе. + latency.

Ну и да, если ставить по CPU на группу модулей - чокнешься всё это щщастье синхронизировать. Особенно при том, что тем же игроделам придётся поддерживать 100500 разных вариантов построения таких GPU.

Короче, не нужно оно, нет смысла переусложнять. Системного достаточно.

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

267. "Представлен RV64X, открытый GPU на базе технологий RISC-V"  +/
Сообщение от Сишник (?), 02-Фев-21, 11:19 
Ну по факту каждый CU в GCN и есть CPU, со своим декодером, векторным АЛУ и регистрами. https://3dnews.ru/assets/external/illustrations/2019/07/07/9... И если это встроенные в проц ядра, то сидят они на той же шине памяти, и всё вполне себе работает. Вот только использовать эти ядра напрямую не дают.
Ответить | Правка | Наверх | Cообщить модератору

285. "Представлен RV64X, открытый GPU на базе технологий RISC-V"  +/
Сообщение от Аноним (285), 02-Фев-21, 15:45 
> Ну по факту каждый CU в GCN и есть CPU, со своим декодером, векторным АЛУ и регистрами.

Типа того. По поводу чего и не выглядит бредом поставить в подобном качестве пачку simd alu и может даже более-менее полное ядро им в помощь. Чем это так принципиально от CU в GCN будет отличаться я не догоняю.

> И если это встроенные в проц ядра, то сидят они на
> той же шине памяти, и всё вполне себе работает. Вот только
> использовать эти ядра напрямую не дают.

И это бывает довольно тупо. Лишняя латенси и оверхед - изниоткуда?

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

286. "Представлен RV64X, открытый GPU на базе технологий RISC-V"  +/
Сообщение от Сишник (?), 02-Фев-21, 15:51 
> И это бывает довольно тупо. Лишняя латенси и оверхед - изниоткуда?

А копировать данные из одной памяти в другую по pсi шине шириной 8-16 линий это не оверхед ли? Можно ж увеличить ширину шины к основной памяти и будет всем счастье.

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

303. "Представлен RV64X, открытый GPU на базе технологий RISC-V"  +/
Сообщение от Аноним (-), 02-Фев-21, 20:25 
Вот именно поэтому там быстрый накристальный local storage. Не гигантский, но позволяет не насиловать шины с большой латенси на каждый пшик.

Алсо сабж и на чем-то типа AHB может наверное быть. Это другие шины с другими соотношениями, у накристальных латенси обычно сильно ниже внешних.

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

282. "Представлен RV64X, открытый GPU на базе технологий RISC-V"  +/
Сообщение от Аноним (282), 02-Фев-21, 14:48 
> Так и я о том. Убрали VLIW с фронта и сделали нормальный
> GPU вместо вывешенного голым задом ядра исполнения :D

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

Фирмачи, собственно, это тоже поняли и активно практикуют. Их, правда, местами дико ненавидят, потому что подпертые блобанутыми фирмварями сервисные операции - очень портит карму когда хочется открытые дрова. Но кмк открытому блоку и открытые дрова/фирмвари сделают...

> Да оно не дичь, но оно должно успевать кормить эти блоки данными.

Это ниоткуда не следует. Оно должно успевать вменяемую координацию, а heavy lifting можно подпереть железом.

> То есть в идеале туда придётся ставить те же полноценные высокочастотные
> модули от зенов например, а они далеко не холодные. Ну и
> опять же память отдельную, I/O и т.п.

Да, если вас взять архитектом в стартап - ему точно будет полный факап.

> С доступом в общую шину будет проблемка - если заставить исполнять из
> видеопамяти - передерутся с самими модулями GPU, их паттерны обращения хорошо
> предсказуемы, а у CPU общего назначения - нет.

Никто в здравом уме не насилует общую шину постоянно, для этого local storage есть. АМДшники практикуют довольно забавный фокус. У них там типа овердохрена регистров. Но если их не хватило, эмулируют это "своплением" видимо в local storage. Они называют это xGPR spill. А остальные что, совсем раки и local storage не будут делать?

> Можно заставлять локальный CPU ждать, как центральный CPU при обмене через PCIe, но тогда
> вообще смысл локального CPU теряется.

Это какая-то очень уж питекантропская модель взаимодействия железок, есть более 9000 более вменяемых вариантов.

> Если дать доступ к системной памяти через PCIe -

Для начала - там и не pcie может быть. А накристальное что-нибудь, типа AHB.

> передерутся с системным CPU и общая производительность в
> итоге всё равно будет так себе. + latency.

Ну вот там амд тоже пару фокусов придумал, допустим zerocopy между системным процом и gpu. Пока вы там по pcie толкаете, оно просто отпускает регион и отдает его gpu - не ворочая данные. Ага, "указатель передать" можно и сильно подальше чем в 1 программме. Передача указателя эффективнее копирования блока, попробуйте оспорить.

> Ну и да, если ставить по CPU на группу модулей - чокнешься
> всё это щщастье синхронизировать. Особенно при том, что тем же игроделам
> придётся поддерживать 100500 разных вариантов построения таких GPU.

Да с чего бы? GPU по жизни как-то так и делают. Особенно штуки типа майнеров.

> Короче, не нужно оно, нет смысла переусложнять. Системного достаточно.

Системного чего? А так если посмотреть на допустим GCN - он тоже не больно какой простой унутрях.

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

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

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




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

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