Опа-опа, уже на Channel9!

Не поверите, мой маленький доклад про GPGPU на маленькой уютной майкрософтовской тусовке (спасибо Саша!) решили выложить на Channel9 (спасибо мужикам из MS Russia!).

Я человек приземленный и в основном на пальцах рассуждаю за железо, CUDA и как примерно оно внутри работает. Попеарьте меня, чтоле!

Часть 1 (сам доклад) – http://channel9.msdn.com/posts/mikcher/GPU-Algorithms-Part1/
Часть 2 (вопросы) – http://channel9.msdn.com/posts/mikcher/GPU-Algoritms-Part2/

В будущем выложат еще одну часть, где содокладчик Миша Горбунов будет показывать одну из демок на CUDA.

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

  • kayru

    с нетерпением ждем компьют шейдеры…

  • belaz

    Про скорость памяти. Насчёт 20-25 Гб/сек на CPU – это несколько преувеличено… Реально в синтетике что-то около 8 Гб/сек…

  • http://www.cgportfolio.ru/database/showthread.php?t=26 Vlasov Alexey

    belaz:
    Он говорит “очень, очень синтетика”. Так что ок, вроде…

  • http://www.microsoft.com CEMEH

    Я брал максимальные цифры вот отсюда:
    http://en.wikipedia.org/wiki/Intel_Core_2

    Теоретически, double channel DDR3 может 20+, но в реальности мало кто их видел, да.

  • belaz

    Теоретически может дать память – да. Но в обычной реальности процессор не может засосать внутрь больше, чем позволяет FSB.

    суровая реальность тут: http://www.ixbt.com/mainboard/ddr3-rmma.shtml
    и тут: http://www.ixbt.com/cpu/rmma-conroe.shtml (особенно таблицы 3 и 4)

  • IronPeter

    Где столько русскоязычных микрософтовцев надыбали?

  • http://www.microsoft.com CEMEH

    Да их там человек 700, а то и больше. Куда бы делись.

  • IronPeter

    Там в вопросах и ответах несколько неточностей.

    К примеру их ассемблер считай открыт, вот независимые бинарные утилитки http://www.cs.rug.nl/~wladimir/decuda/, построенные на оффициальной документации
    ( файлик PTX_ISA_x.x.PDF в поставке CUDA TOOLKIT ).

    Вообще есть забавные моменты. Рекомендации считать стойкое крипто совместно с
    неуверенностью, что процессы действительно изолированы по памяти.
    Есть ощущение, что майкрософту и вендорам надо внимательнее отнестись к секьюрности на GPU.

  • http://www.microsoft.com CEMEH

    Нет, ну это же примерно такой же ассемблер, как DX asm, бесконечно далекий от железа?
    А так – у нас в драйвер-модели все секьюрно в теории, весь вопрос – насколько успешно ее имплементировали IHV. Надо чтобы начали плотно ломать, чтобы узнать на этот вопрос :)

  • IronPeter

    Это их реальный ассемблер. Прямо на него устанавливается instruction pointer – и поехало. Код кстати кешируется, это тебе не cell, где надо сделать DMA целиком на весь код. Код кстати единый для CUDA, VS, GS, PS.

    Ваша драйвер-модель это конечно хорошо. Но сейчас CUDA – это такой отросток сбоку. Позволяющий аллоцировать память девайса, что-то там с ней делать. Наружу вытащены какие-то там DMA трансферы в клиентскую память. Как там оно живет – никто не знает. Остается ли мусор на регистрах и в shared памяти после запуска CUDA пакета – тоже никто не знает.

  • http://www.microsoft.com CEMEH

    Хм-хм, интересно, мне казалось, там этот асм нетривиально на железо транслируется.
    Буду знать теперь :)

    Кстати, надо глянуть, как CUDA calls выглядят с точки зрения нашей инфраструктуры.

  • IronPeter

    >там этот асм нетривиально на железо транслируется

    А вот это кстати хрен знает. Т.е. несложно представить что там есть специальный статический оптимизатор. Который зачитывает код чанками. И распределяет во VLIW манере. Ну т.е. add r0, r1 и mul r2, r3 вполне себе можно статически исполнять вместе.

    Можно динамически, когда один batch из тредов будет исполнять add, второй – mul на свободном функциональном устройстве. Так что ты прав, даже фиксирование ассемблера мало дает.

    Это как командный буфер на современном ATI железе. Т.е. вроде формат пушбуфера открыт. Но, с другой стороны, есть прослойка – командный процессор. Который переформулирует команды пушбуфера в записи во внутренние регистры. Командный буфер становится тоньше и более высокоуровневым, детали реализации скрываются.

  • http://andreyogl-d3d.blogspot.com/ Andrey

    CEMEH Спасибо за доклад. Очень впечатляет, очень понятно объясняешь. Жду Compute Shaders, с ними наверняка все будет намного проще. Скажи, что более перспективным более стабильным и более быстрым будет в будущем, OpenCL или Compute Shaders в составе Direct3D 11? или это будет опять подобно OpenGL vs Direct3D. Да и nVidia CUDA уйдет на второй план с приходом Direct3D11, судя по мнению IronPeter ?

  • http://www.microsoft.com CEMEH

    Я не могу комментировать развитие и перспективы OpenCL по очевидным причинам.
    За мнение Пети я опять же не готов говорить :)

    Но понятно, что GPGPU будет развиваться, никуда не денется. Будут интересные времена.

  • look4awhile

    > Хм-хм, интересно, мне казалось, там этот асм нетривиально на железо транслируется.

    так и есть.