Каталог
ZV
ездный б-р, 19
+7 (495) 974-3333 +7 (495) 974-3333 Выбрать город: Москва
Подождите...
Получить токен
Соединиться
X
Сюда
Туда
x
Не выбрано товаров для сравнения
x
Корзина пуста
Итого: 
Оформить заказ
Сохранить заказ
Открыть корзину
Калькуляция
Очистить корзину
x
Главная
Магазины
Каталог
Мои заказы
Корзина
Магазины Доставка по РФ
Город
Область
Ваш город - ?
От выбранного города зависят цены, наличие товара и
способы доставки

Четверг, 1 марта 2007 00:00

NVIDIA открывает CUDA

короткая ссылка на новость:

Предыдущие ограничения модели GPGPU



   Учитывая, что Direct3D 10 уже поддерживает значительно более гибкие возможности программирования, можно было бы спросить, зачем ещё нужен специальный интерфейс для программирования GPGPU. Первая причина против использования существующего API - то, что он не должен зависеть от драйверов. Каждая новая версия драйвера может, так или иначе, через ошибки или изменения, затрагивать уже готовые алгоритмы.

   Но даже если исключить такой фактор, проблема остается, потому что основной целью работы ни DirectX, ни OpenGL не является оптимизация режима GPGPU и это ограничивает их производительность при выполнении таких задач. Возможно, однако, что еще более важно то, что произвольное чтение и запись в память в обход системы кэширования (или при сдвиге данных в памяти) все еще не поддерживается Direct3D 10 API.

Не удивительно, что CUDA органически поддерживает как сбор (Gather - произвольное чтение из памяти), так и раздачу (Scatter - произвольная запись в память) данных. И это при том, что ни записываемые, ни читаемые данные не кэшированы

   Напомним, что в прошлом году AMD также внедрила свой собственный интерфейс GPGPU – CTM ("Close To the Metal"), который в настоящее время поддерживается аппаратно архитектурой их R(V)5 продуктов. CTM также поддерживает операции Gather and Scatter. Поэтому может показаться, что, кроме различий в архитектуре между G80 и R580, технология AMD похожа на CUDA, но они отличаются друг от друга очень сильно.

   Идея, которая лежит в основе CTM – дайте программисту больше возможностей напрямую управлять оборудованием и он заставит его работать быстрее. То есть, пусть пишет программы на ассемблере. CUDA, с другой стороны, стремится упростить программирование GPGPU, и предлагает это делать на языке C. В настоящее время базовый ассемблер (также известный как "NVAsc") не доступен разработчикам приложений.

   В настоящее время единственным доступным инструментом программиста CTM является Brook, который абстрагирует базовый интерфейс (Direct3D, OpenGL, CTM и его варианты) и предоставляет потоковоподобную модель программирования, которая довольно хорошо подходит под современное аппаратное обеспечение. Загвоздка, к сожалению, в том, что программисту недоступна произвольная запись в память. Поэтому, если вам это нужно и вы хотите воспользоваться преимуществом CTM, пока придется довольно много писать на ассемблере.

   В любом случае, у CTM хороший потенциал, но его будущее связано с тем, что будет у R600 и как изменится сам код.

   Что касается CUDA, то у неё мы ещё не рассмотрели такие важные характеристики, как производительность и адресуемый рынок. Одной из ключевых целей NVIDIA для CUDA является её пригодность для решения большого круга задач с разными алгоритмами при как можно меньшем взаимодействии с CPU. Как они думают этого добиться? Синхронизация вычислительных потоков и совместное использование данных. Хорошая, быстрая и эффективная синхронизация.

[N3-Новые концепции для CUDA. Часть 1]    Кэш параллельных данных (parallel data cache - PDC), также известный как "совместно используемая память", является одним из основных элементов архитектуры G80, который позволяет работать с более эффективными примитивами синхронизации локальных данных. Похоже, что это основной элемент архитектуры NVIDIA для ускорения работы геометрических шейдеров DirectX 10.

   Перед тем как идти дальше, посмотрите на архитектуру NVIDIA G8x и CUDA. Эта блок-схема очень похожа на одну из диаграмм из патентов NVIDIA, зарегистрированных в 2003 году.

Процессоры, мультипроцессоры и ещё процессоры

   В G80 варианте этой архитектуры на каждый мультипроцессор приходится 8 процессоров (ALU-арифметико-логических устройств) и 16 мультипроцессоров на чип. Кроме того, как видно на блок-схеме, у каждого процессора есть минимум один регистр.

   Опять же, на блок-схеме можно заметить, что на каждый мультипроцессор приходится 1пул общей памяти (shared memory). А общаться между собой разные мультипроцессоры могут только через память устройства (device memory). К тому же, нет никаких естественных примитивов, чтобы упростить эту ситуацию. Вот почему мы называем возможности синхронизации G80 как "локальные" – они не распространяются на весь чип. Однако с другой стороны, это невероятно эффективно для имеющихся возможностей.

   Так что же из себя представляет PDC? Известно, что каждый блок общей памяти состоит из 16 банков однопортовой SRAM. Каждый банк имеет объем 1 KiB (1024 байт) и пропускную способность 32 бита на такт. Так как у G80 всего 16 мультипроцессоров – всего это 256 KiB памяти с пропускной способностью более 675 GiB/s. Для всех задач и целей это можно рассматривать как логическое и очень гибкое расширение регистрового файла.

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

В этом абсолютно произвольном примере, при параллельном кэше для чтения из DRAM требуется всего 4 операции чтения, а в предыдущих вариантах GPGPU – 6 операций. Такой кэш может обеспечить большее быстродействие, по сравнению с обычным кэшем с автоматическим заполнением, но программисту придется проделать большую работу, чтобы заставить эту конфигурацию работать

   Нужно заметить, что кэш параллельных данных поддерживает связь внутри группы из 16 тредов, без какой-либо явной синхронизации. Это можно назвать "суперлокальная неявная синхронизация", и это очень похоже на архитектуру пиксельных шейдеров, которая позволяет выполнять ddx и ddy команды с высокой пропускной способностью и большой скоростью.

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

[N4-Новые концепции для CUDA. Часть 2]    Давайте посмотрим, как NVIDIA описывает среду программирования CUDA. Довольно наглядно это показано на следующем рисунке:

Много ядер, много каналов, много тредов - а это уже не больший параллелизм, чем тот, которым мы ещё можем управлять? " -- David Kirk, NVIDIA

   Термин 'kernel' (ядро ОС) взят от потоковых процессоров. CPU делегирует "ядро" на GPU, и оно там разбивается на сети, блоки и треды. Кроме того, на этом рисунке не показано,

Источник: www.beyond3d.com

подписаться   |   обсудить в ВК   |