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

Передача сообщений между потоками GPU

Страницы: 1 2 Следующая »
#0
0:20, 17 авг. 2015

Привет!

Не совсем о графике, но все равно.

Совсем не работал с темой OpenCL\CUDA и подобные.
Прощу простить некоторое невежество.

На GPU множество процессоров.
Можно ли от одного процессора GPU передавать сообщение другому процессору GPU?
Или это в принципе невозможно? И каждый процессора работает изолированно?
Например, я не вижу причин для ввода этой функции для 3D.

Возможно ли организовать очередь сообщений для каждого процессора GPU?

Спасибо!


#1
6:59, 17 авг. 2015

Вам в каждом микротреде надо очередь, или одну на варп?

#2
7:28, 17 авг. 2015

GhostCoderPPetrov
> Можно ли от одного процессора GPU передавать сообщение другому процессору GPU?
Можно. Запись в память, синхронизация, чтение из памяти.

#3
12:20, 17 авг. 2015

Таже CUDA/OpenCL работают в терминах отдельных нитей. И взаимождействие между разными нитями жестко ограничено.
Попытка передать сообщение из одной нити другой нити между разными потоковыми мультипроцессорами опасна - дело в том, что не все заданные нити запускаются одновременно.
Сама CUDA управляет запуском блоков нитей и при большорм числе нитей у вас какие-то блоки нитей уже завершат работу, а какие-то еще не начнт работу. И взаимодйествие между ними практически невозможно.
Можно перед запуском узанть параметры GPU и запустить ровно то количество блоков/нитей, котроое млжно запустить одновременно. Тогда можно  взимодействовать через шлобальную память.

#4
13:02, 17 авг. 2015
steps3d

г-н Боресков ? я учился по Вашим книгам :)

#5
13:55, 17 авг. 2015
г-н Боресков ? я учился по Вашим книгам :)

У меня была книга "Компьютерная Графика: Первое знакомство" еще в конце 90-х.
Спасибо за книгу!

А насчёт основной темы - прорабатываю варианты создания прототипа игры, описанной здесь - http://www.gamedev.ru/gamedesign/forum/?id=195867

Очень много пользователей,  локация - вся Земля, данные берутся геодезические (снимок с космоса плюс карты высот),
потом добавляются здания (ну не знаю, есть же базы Народной Карты Яндекс, OpenStreetMaps).
Из ломаных линий дорог генерируем полноценные 3D дороги, с бордюрами, полосами и прочее (по шаблонам "деревенская дорога", "шоссе").
Из полигонов зданий генерируем 3D здания, можно для начала просто коробки, как в 2GIS, или так-же по шаблонам.
Шаблоны дорог\зданий\ландшафта (лес\степь\реки) можно выбирать каким-нибудь эвристическим алгоритмом.

Примерно так работает Autodesk InfraWorks, только пользователь там сам выбирает шаблон (без звука, прощу прощения):
https://youtu.be/8TZITl8qEJc
https://youtu.be/kJS8PzwpKb8
https://youtu.be/c7nB69NmXis
https://youtu.be/Cqo2CxQcRxg
https://youtu.be/IV4d7007dDw

То есть генерация 3D мира - дело техники и входных данных.

Проблема в реализации механики игры.
Даже если не делать полноценной физики, а ограничиться расчётом попаданий снарядов и взаимным столкновением юнитов.

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

Самое первое, что приходит в голову, купить N компьютеров, в каждом организовать 4 сетевых платы.
Каждый узел соединить гигабитным ethernet с соседними.

Если каждый узел обрабатывает определенную зону (скажем, 1км х 1км), то будем считать что,
число юнитов на ней ограниченно, и в среднем не превышает какого-то предельного числа Z.

Расчёт взаимных столкновений займет порядка Z*(Z-1)/2 операций, то есть это полный перебор.
Это это перебор в одной зоне, где число юнитов ограничено, я думаю, тут меня поймут.
А всего юнитов на всей карте ограничено только финансовыми возможностями покупки узлов.

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

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

В идеале, размер патча для каждого узла не фиксирован, и изменяется динамически,
в зависимости от числа игроков, и число узлов сети также изменяется динамически,
и есть возможность добавлять новые\убирать узлы из сети.

Сам я настроен несколько скептично с предложенной идеей, но думаю, не всё так безнадежно.
По-крайней мере, в процессе получу новые знания, познакомлюсь с OpenCL, современным программированием графики OpenGL\DirectX, программированием высокопроизводительных систем :)

Вот сейчас занимаюсь исследованием, что может подойти, а что нет.

#6
14:22, 17 авг. 2015

У NVIDIA есть статья про реализацию расчета столконовений на CUDA. Есть куча простых двигающихся объектов и задача расчета их столкновений. Насколько я помню там делается равномерное разбиение пространства и взяимодействие между нитями реализавано на разбитии на отдельные запуские ядер. И тогда все что записала одна нить будет гарантированно видно при запуске следедующего ядра всем нитям.
ЗЫ. Рад что помните мои книги

#7
14:30, 17 авг. 2015

GhostCoderPPetrov

Тут просто нужно понимать, что ядра видеокарты, это, как правило, совсем не то, что ядра CPU. Непосредственно исполнительных ядер (которые собственно и являются "настоящими" процессорами, выполняющими программу) в современных видеокартах немного, а то что указывается в маркетинговых целях - это количество нитей, то есть одновременно обрабатываемых векторными инструкциями данных (как аналогию, можно посчитать например количество параллельно обрабатываемых байтов в инструкциях AVX (32) и умножить на количество ядер, после чего смело продавать 256-ядерные Core i7). Разница, правда, с приведенным примером в том, что конвейер в GPU устроен немного хитрее и выполняет эти инструкции асинхронно и чередуя их с инструкциями других программ (что-то вроде хитрожопого Hyper-Threading), добиваясь ликвидации простоя вычислительных ядер.

Далее - GPGPU по своей природе заточены под алгоритмы класса map-reduce (причем reduce ложится хуже, в силу природной независимости нитей друг ото друга и следующей из этого необходимостью примитивов синхронизации, кроме того общая память (т.н. local store) весьма ограничена по объему(десятки килобайт на каждое "настоящее" ядро) ) над линейными структурами данных - берем большой кусок данных, поэлементно распределяем его по имеющимся нитям и выполняем на нем арифметические действия с последующим результатом над каждым элементом в память. Соответственно, алгоритмы работающие на нелинейных структурах или подразумевающие произвольный доступ к памяти на GPU не кладутся практически никак. То же самое относится и к алгоритмам, обильно использующим ветвление, поскольку оное в GPGPU реализовано, как правило, отключением выполнения нитей, не попадающих под условие (а не условным переходом по адресу, как в CPU) и последующим простоем этих самых вычислительных узлов (дело немного облагораживает вышеупомянутый встроенный планировщик и асинхронное выполнение команд).

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

#8
15:48, 17 авг. 2015

steps3d
> ЗЫ. Рад что помните мои книги

я еще помню using namespace std; в заголовках :)
#9
15:52, 17 авг. 2015

PANDA
> steps3d
> > ЗЫ. Рад что помните мои книги
> я еще помню using namespace std; в заголовках :)

Ну, тогда С++ только только перерождался из С с классами, пространства имен были в диковинку, а на темплейты и вовсе смотрели как на непонятное заморское чудо, а не как на инструмент, составляющий 90% плюсового кода, как сейчас.
#10
16:08, 17 авг. 2015

Сейчас подумываю с сторону CPU - например - http://www.dns-shop.ru/catalog/i1002955/materinskaya-plata-asus-j… c#description

Что думаете?

#11
16:19, 17 авг. 2015

GhostCoderPPetrov

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

(Хинт, большая часть подобных концептов о сверхмассивности онлайновых игр обрубалась по критериям "целесообразность" и "играбельность" )

#12
18:31, 17 авг. 2015

Согласен. Рановато еще на реальном железе. Да еще и ничего нет.
На виртуалке (нескольких) - самое то.

Как считаете держать сетевые соединения?

#13
7:45, 18 авг. 2015

GhostCoderPPetrov
> Как считаете держать сетевые соединения?
А на одной ноде уже все работает, кусочек мира уже симулируется? Потому что иначе толку тужиться и выбирать между двух протоколов, если вы даже не знаете, какие данные вы будете передавать между нодами.

#14
10:36, 18 авг. 2015

GhostCoderPPetrov
Не, люди любят кучковаться. Поэтому постоянно будут нагружены только определённые сервера, а остальные простаивать. Притом возможно нагруженные будут перегруженными.

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

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