iCrosss Facebook page

суббота, 6 марта 2010 г.

Driver API или Runtime API что выбрать?

Вы наверняка видели в документации по CUDA следующую картинку. Давайте расшифруем все её элементы. К CUDA Libraries можно отнести библиотеки высокого уровня, которые предоставлены компанией NVIDIA (CUBLASS, CUFFT), а также сюда можно отнести все библиотеки, которые написаны или будут написаны с использованием CUDA. CUDA Runtime API – представляет собой API для работы с GPU адаптером(ами), запуском ядра и операциями с памятью. Все функции CUDA Runtime имеют префикс “cuda”. CUDA Driver API – низкоуровневый интерфейс доступа к GPU, загрузки модулей ядра и операций с памятью. Функции CUDA Driver API имеют префикс “cu”.  

Основные отличия Driver API от CUDA Runtime:

  • инициализация контекста вручную
  • загрузка модулей вручную
  • дополнительные вызовы для передачи параметров в ядро
  • необходимость наличия .cubin файла с конечным продуктом
  • больший контроль выполнения и ошибок
  • возможность получить больше информации об устройстве
  • независимость от языка программирования
  • невозможность использовать режим эмуляции для отладки(так как для запуска ядра необходимо загрузить .cubin файл с GPU кодом)
  • функции Driver API находятся в nvcuda.dll, а Runtime API в cudart.dll

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


пятница, 5 марта 2010 г.

NVIDIA Parallel Nsight ("Nexus")

Компания NVIDIA решила создать продукт, который позволить производить отладку, профайлинг и анализ приложений написанных с использованием технологии CUDA. Для чего это нужно, ведь в CUDA уже предусмотрен режим эмуляции для того чтоб можно было отладить все функции и ядро которые выполняются на GPU? Да, действительно, в CUDA есть режим эмуляции, предусматривающий компиляцию кода, таким образом, что его выполнение будет производиться на центральном процессоре и эмулировать потоки, создавая их средствами операционной системы. Но такой подход имеет множество недостатков, которые существенно затрудняют отладку. Об этом написана отдельная статья «Подводные камни -deviceemu».
Вернемся к теме статьи. Для того чтобы побороть все недостатки режима эмуляции NVIDIA разрабатывает продукт который продвинет технологию в массы и позволит сделать отладку более комфортной. На сегодняшний день доступна «бэта» версия, ознакомится с которой, можно по ссылке. На прошлой неделе NVIDIA проводила веб семинар по использованию Nexus, показывали презентацию, основные фишки отладки и анализа. Отвечали на вопросы. Продукт состоит из 2 частей Host и Monitor и построена на базе клиент-сервер. Системные требования продукта:
  • Windows Vista SP1 или Window 7.
  • .NET framework 3.5
  • Microsoft Visual Studio 2008 (все кроме Express) с SP1.
  • Драйвер с поддержкой CUDA 3.0  (версии 195.62 и выше)
По аппаратному обеспечению тоже выдвигаются определённые требования. Графический процессор должен быть не младше G92 (список поддерживаемых устройств приведён в конце статьи). Исходя из этого, можно сказать, что на сегодняшний день поддерживается очень узкая часть рынка. Для установки, вам, скорее всего, потребуется дополнительно приводить свою систему в соответствии с требованиями продукта. Также, одна из немаловажных особенностей – для отладки вам потребуется два компьютера включённых в одну сеть. Владельцев материнских плат с двумя слотами для видеокарт это не касается (достаточно  иметь две видеокарты NVIDIA с выключенным режимом SLI). В таком случае, отладку можно будет проводить на той карте, которая не подключена к монитору. Эти ограничения можно объяснить очень просто, во время остановки на breakpoint, видеокарта замораживается и если у вас используется одна карточка на всё, то изображение на мониторе перестанет обновляться. Поэтому выполнять отладку лучше на удалённой машине, которая по терминологии NVIDIA называется «target». На нее достаточно установить .NET framework, драйвер и Nexus Monitor, установка среды разработки не обязательна. Именно на этой машине должна быть установлена видеокарта G92+. На «host» машину необходимо установить требуемую версию среды разработки и не забыть про SP1, затем Nexus Host. Видеоадаптер на ней может быть любым.  
Теперь немного о работе с продуктом. Он встраивается в среду разработки: появляется надпись Nexus в главном меню, а также свойства в контекстном меню проекта. Это позволяет настраивать конфигурацию проекта имя или адрес сервера, на котором будет запущен проект. Выполнять отладку и профайлинг необходимо пользуясь пунктами меню Nexus. Для начала работы необходимо запустить монитор на «target» машине. При запуске отладки происходит соединение по TCP/IP порт 8000 (соответственно, все настройки бренмауэра и маршрутизатора должны быть установлены правильно, чтоб не препятствовать процессу). Выполняется синхронизация и все файлы заливаются на «target» машину, где выполняются под чутким контролем монитора. Для адаптации существующего проекта или для создания нового необходимо использовать версию компилятора NVCC и библиотек CUDA, которые входят в состав NVIDIA Nexus. Компилировать .cu файлы необходимо с опцией «–G0», или использовать уже существующие build правила которые идут в комплекте с продуктом.
NVIDIA Nexus (или “Parallel Nsight”), очень мощное средство для работы с CUDA приложениями. Оно способно избавить вас от множества страданий и неудобств, которые приходилось испытывать ранее. Но хочу напомнить, что это пока еще «бэта», и во время работы с продуктом могут возникать определённые сложности. Если вы не в силах сами справиться с ситуацией, загляните в support и поищите там, если не нашли, оставьте «ticket» разработчикам. Возможно, вы нашли какой-то «баг», тогда, это будет вашим вкладом развитие передовых технологий :).  

Список графических адаптеров поддерживаемых Nexus:
   GeForce 210 GeForce 310 GeForce 8400 GeForce 8400 GS GeForce 8800 GS GeForce 8800 GT GeForce 8800 GTS 512 GeForce 9300 GE GeForce 9300 GS GeForce 9300 SE GeForce 9400 GT GeForce 9500 GS GeForce 9500 GT GeForce 9600 GS GeForce 9600 GSO GeForce 9600 GSO 512 GeForce 9600 GT GeForce 9800 GT GeForce 9800 GTX GeForce 9800 GTX+ GeForce 9800 GX2 GeForce G100 GeForce G210 GeForce G210 GeForce GT 120 GeForce GT 220 GeForce GTS 240 GeForce GTS 250 GeForce GTX 260 GeForce GTX 275 GeForce GTX 280 GeForce GTX 285 GeForce GTX 295 GeForce NVS 2100 GeForce NVS 3100  
    Quadro CX Quadro FX 1800 Quadro FX 370 Quadro FX 3700 Quadro FX 380 Quadro FX 380 LP Quadro FX 3800 Quadro FX 4800  Quadro FX 580 Quadro FX 5800
     Tesla C1060 Tesla S1070

четверг, 4 марта 2010 г.

Подводные камни “–deviceemu”

При разработке приложений с использованием технологии CUDA остро стоит вопрос об отладке функций, которые выполняются на графическом процессоре. Код написанный с директивами __global__, __device__, а также все переменные и массивы которые инициализированы для хранения в памяти графического адаптера не могут быть доступны к просмотру и отладке при помощи стандартных средств разработки (например, Visual Studio). Также все указатели на на выделенную видео память не являются валидными в контексте CPU и RAM.
Для решения этой проблемы был разработан подход, который позволил производить отладку приложений подобного рода. Его суть состоит в том, чтоб эмулировать весь код, который предназначен для выполнения на GPU, при помощи процессора. В таком случае все потоки, которые должны выполнятся на GPU, создаются как потоки операционной системы. Вся память, которая выделяется на адаптере, теперь принадлежит процессу.
Все это можно активировать, добавив опцию компилятора NVCC «-deviceemu» в список опций компиляции .cu файла. После этого весь код проекта будет доступен для отладки, так как фактически он выполняется центральным процессором.
Но не всё так чудесно. С возможностью отлаживать ваши программы, вы приобрели вероятность наступить на грабли, которые разбросало данное решение.
Ниже я приведу основные проблемы, которые могут возникнуть при использовании режима эмуляции:
  • При использовании режима эмуляции существует возможность вызова функций внешних библиотек из ядра или локальных функций не являющихся __device__ функциями
  • В режиме эмуляции можно получить доступ к данным находящимся в ОЗУ системы из функций графического адаптера и наоборот. Это является одной из основных проблем так как при выполнении на GPU функции не смогут получть доступ к памяти по темже указателям, что приведёт к ошибкам и разнице в результатах расчётов.
  • В режиме эмуляции отсутствуют ограничения на размер разделяемой памяти (__shared__)
  • Некоторые 32 разрядные операционные системы Windows (речь не идёт о серверных ОС), такие как Windows XP имеют ограничение на максимальное выделение памяти в размере 2 Гб в рамках одного процесса. А на графских адаптерах NVIDIA Tesla установлено 4 Гб
  • Результаты вычислений могут не совпадать в режиме эмуляции и в режиме выполнения на устройстве. Это можно объяснить очень просто. При работе сопроцессора используются 80 битные регистры при операциях с плавающей точкой, а результат округляется до соответствующего типа (32 бита float или 64 – double). Графические адаптеры не имеют такой возможности и оперируют только предоставленным количеством разрядов. Соответственно при большом количестве вычислений может накопиться некоторая небольшая погрешность, что и даст разницу результатов. Исправив слово состояние сопроцессора при помощи команд ассемблера можно добиться одинаковых результатов, за счёт уменьшения точности расчетов на CPU. Более детальную информацию можно посмотреть здесь, тамже можно найти исходные коды для изменения слова состояния сопорцессора
  • Время работы приложения в режиме эмуляции в десятки раз может превышать время работы того же алгоритма на центральном процессоре без разпаралеливания. Это существенный недостаток, иногда необходимо добраться до определённого потока и приходиться ждать минуты, что очень затрудняет отладку
  • Также немаловажным недостатком является невозможность использования режима эмуляци при программировани CUDA на уровне Driver API. Это можно объяснить тем, что режим эмуляции поддерживается только на уровне CUDA Runtime. При компиляции в режиме эмуляции, NVCC не генерирует файлы необходимые для загрузки модуля, которые могут содержать только GPU код (.cubin).
Также нельзя использовать режим эмуляции частично, т.е. компилировать некоторые файлы проекта в родном режиме, а некоторые в режиме эмуляции это грозит ошибкой cudaErrorMixedDeviceExecution.
Всё это может привести к ошибкам исправлять которые достаточно сложная задача, что делает режим эмуляции не достаточно гибким при отладке. Работая в этом режиме необходимо быть внимательным ко всем деталям. Но, несмотря на это, некоторые из приведенных ограничений, могут стать даже полезными, и в умелых руках сослужить хорошую службу разработчику.
Сейчас компания NVIDIA ведет работу над разработкой продукта под названием Nexus, который позволит разработчику отлаживаться непосредственно на графическом процессоре. Но об этом в другой статье :)