Гонка графических титанов продолжается

Flora · 12 мая 2009 18:58:53

Цитироватьуниверсальнее было бы наращивать ядерность процессоров, чем засовывать туда какие-то части отвечающие за графическую визуализацию

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

MoroseTroll · 12 мая 2009 19:59:58

Force: Мне думается, гибридные процессоры (те, что с графикой внутри) в первую очередь будут предназначены для ноутбуков, нетбуков и прочих мобильных устройств, где очень важны минимальные размеры и энергопотребление. Да, скорее всего, настольные ПК (вернее, их владельцы) будут весьма неохотно расставаться с внешними видеокартами.
Насчёт запарок с использованием той или иной части процессора или видеокарты для каких-либо расчётов: надеюсь, nVidia всё-таки не перетянет на себя одеяло со своей CUDA, ибо негоже это, когда интерфейс закрытый и, следовательно, доступный только на фирменных устройствах (помните Glide, MeTaL, RedLine и пр.?). Т.н. вычислительные шейдеры (DirectX 11) и OpenCL (где угодно), надеюсь, победят. Если победит OpenCL, тогда настанет всеобщий мировой кайф для всех устройств (от мобильника до ПК), ибо будет совсем неважно, какая именно часть занята расчётами (процессор, видеокарта и какая-то другая штуковина) - всё будет абсолютно прозрачно. Но это в идеале:embarassed:.
Zontik: Жжёшь:biggrin:!
Flora: Современные видеопроцессоры, поддерживающие SM4 и выше, всё больше и больше походят собой на центральные. Конечно, у первых по-прежнему нет многих важных свойств последних, но грань между ними постепенно размывается. Так что, кто знает, что там в будущем получится...

Flora · 12 мая 2009 21:51:33

MoroseTroll

ЦитироватьСовременные видеопроцессоры, поддерживающие SM4 и выше, всё больше и больше походят собой на центральные.

Ты это с чего взял?

Force · 13 мая 2009 09:42:18

ЦитироватьТы это с чего взял?

Да хотя бы из-за возможностей, которые они предоставляют для расчетов.
MoroseTroll, если честно, я как-то не подумал о возможной смерти CUDA. Конечно, если смотреть с этой стороны, то дело плохо, но мне кажется, другой альтернативы мы просто не дождемся...

Flora · 13 мая 2009 10:18:34

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

И что это за возможности? Расчет шейдеров?

MoroseTroll · 13 мая 2009 11:14:25

Flora: Если сравнивать последовательно, то каждое поколение видеочипов с новой версией SM становится всё гибче и гибче в программировании. Понятное дело, что они ориентированы на графику, но не просто же так nVidia продвигает свою CUDA, согласись.
А что есть шейдер? Подпрограмма, работающая со скалярами, векторами и матрицами. Раньше результаты их работы обязательно надо было записывать в текстуру, сейчас это уже не обязательно, а дальше, сам понимаешь, будет ещё гибче и хитрее. Говоря о похожести, я имел ввиду похожесть на SIMD-блоки центральных процессоров и возможность писать относительно длинные циклы с ветвлениями.
Force: Ну, CUDA просто так не умрёт. Всё зависит от того, насколько быстро и эффективно будут внедряться OpenCL и DirectX 11.

Flora · 13 мая 2009 11:32:42

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

Force · 13 мая 2009 13:50:17

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

Кармак как-то говорил, что в следующем поколении движков он попытается веализовать рейкаст и воксельные пространства, весьма интересно, что из этого у него выйдет

...

MoroseTroll · 13 мая 2009 14:44:32

Flora: А-а, ты про это... Да, последовательные вычисления в основном "не дружат" с параллельными вычислителями. И хрен с ними:biggrin:! Должны же чем-то заниматься собственно центральные процессоры

.
Опять же, человеческая мысль на месте не стоит, для каких-нибудь категорий последовательных алгоритмов придумают какие-нибудь параллельные варианты, хотя, конечно, далеко не сразу. Кстати, в последних SSE появились и будут появляться специальные инструкции для пакетного сравнения как раз для того, чтобы эти самые последовательные вычисления чуток ускорить.
В некоторых случаях может помочь смена, так сказать, парадигмы:biggrin:. Если, скажем, взять синус или косинус, то их расчёт с использованием всяких SIMD-инструкций практически одинаков по времени что для одного значения, что для четырёх. Отсель мораль: зная это, умный программист не будет вызывать четыре раза подпрограмму расчёта для каждого отдельного значения, а, если будет возможность, запихает все четыре в один пакет и сделает всего один вызов. Ну и т.д.
Force: Кармак - гений программирования. Если бы не занимался своей космической х#рнёй, был бы впереди планеты всей, а так - просто один из лидеров. Впрочем, у меня нет сомнений, что у него всё задуманное получится.

Flora · 13 мая 2009 20:13:20

Force

Цитироватьпоследовательные" вычисления можно сделать параллельными, например в расчетах физики миллионов мелких частиц, которые "не сталкиваются".

И что это за частицы такие "которые не сталкиваются"? Нейтрино, что ли?

При расчете сферического коня в вакууме?

Если частицы, как ты говоришь "не сталкиваются", то что там рассчитывать? Движение прямолинейное и равномерное...

ЦитироватьКогда частиц миллионы, там уже не важно, сталкиваются они между собой или нет

Ну ты даешь! Все как раз с точностью до наоборот! Чем больше столкновений, тем точнее надо их учитывать. А вот если частиц мало - можно наплевать на столкновения, т.к. они маловероятны...
MoroseTroll

Цитироватьдля каких-нибудь категорий последовательных алгоритмов придумают какие-нибудь параллельные варианты

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

MoroseTroll · 14 мая 2009 10:02:41

Flora: Про синус/косинус. Допустим, есть какой-то цикл, в котором используются оные функции для каких-то там вычислений. Если исходные значения углов, для которых они считаются, известны заранее (а часто так и бывает), то цикл этот можно слегка оптимизировать. Можно либо выделить отдельный цикл для синусов/косинусов, где они будут считаться пачками по четыре (а не по одному), либо сделать это накопление по четыре внутри оригинального цикла.

Force · 14 мая 2009 11:12:20

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

Flora · 14 мая 2009 17:42:50

MoroseTroll, все равно не понял. Откуда взялись пачки по 4 штуки?
Вот простой пример: Если надо допустим сосчитать сумму ряда: cos1*sin1 + cos2*sin2 + ... cos360*sin360 =? Сколько надо ядер, чтобы сделать вычисление за один такт?

Force

ЦитироватьНапример, камнепад

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

MoroseTroll · 15 мая 2009 10:22:29

Пачки по 4 штуки взяты из размера XMM-регистра (128 бит), что используются в SSE-инструкциях всех мастей. Число обычной (или одинарной) точности занимает 32 бита, следовательно, таковых поместится 4 штуки в одном 128-битном XMM регистре.
Насчёт твоего ряда: все аргументы друг от друга независимы, следовательно, синусы и косинусы можно и нужно считать параллельно. В случае со специальной инструкцией FSINCOS, имеющейся в любом современном процессоре, ядер потребуется 360. В случае использования SSE-инструкций, ядер потребуется в два-четыре раза меньше - зависит от реализации алгоритма. Другое дело, что сложить всё результаты за один раз не получится.

Flora · 15 мая 2009 10:58:39

Цитировать32 бита, следовательно, таковых поместится 4 штуки в одном 128-битном XMM регистре

А операцию по размещению 4 штук можно за один такт выполнить?

Цитироватьядер потребуется 360

ЦитироватьДругое дело, что сложить всё результаты за один раз не получится.

Ну а раз за один раз не получится, то значит 360 ядер будут задействованы только в первый такт, потом 359 будут простаивать, пока 1 ядро будет суммировать.

Не очень эффективно, не так ли? Может достаточно 2-х? Одно суммирует, одно вычисляет слагаемые.