NVidia: CUDA и OpenCL

После появления первой доступной реализации OpenCL (доступна для зарегестрированных NVidia-девелоперов с девелоперского сайта) все кинулись смотреть (и я тоже).

Накопали всякого интересного:

  • Бинарное представление OpenCL-кода - это практически CUDA PTX (ссылки: PDF-текст про это, ветка форума к которой этот текст относится).
  • Возможно подсовывание PTX-кода от CUDA в OpenCL (ссылки те же), смысл может быть в использовании тех CUDA extenstions, которых нет в OpenCL. Правда, при этом можно использовать просто CUDA т.е. смысла не очень много.

Кроме того, многих фишек CUDA просто нет в текущей реализации OpenCL, что огорчительно:

  • Нет работы с mapped pinned memory (что появилось в CUDA 2.2). Т.е. требуются пересылки в память видеокарты даже там, где эта память - на самом деле системная память (ноутбучные видеокарты), да и вообще без пересылок удобнее.
  • В CUDA есть взаимодействие с OpenGL, в OpenCL - нету (в спецификации есть, но пока не поддержано). В результате, пример nbody в OpenCL-реализации работает вчетверо медленнее на GTX280 (80GFLOP/s вместо 320), ибо весь пар уходит в пересылку результата на хост, а с хоста - на отрисовку.

Вообще, со всеми этими extensions все выглядит пока весьма огорчительно. Даже если они появятся в условном OpenCL 1.1+, придется писать по варианту программы под каждую видео-архитектуру. И на текущем разнообразии железа не видно выхода, слишком оно разное, чтобы из одной программы компиляцией получались эффективные решения под ATI и NVidia одновременно.

Простые юнит-тесты еще не делал, руки не дошли, пока только смотрел код из SDK.

Update Похоже, про nbody товарищи не правы. Т.п. в oclNBody какая-то работа с OpenGL objects есть. Либо недоделано, либо просто NBody нужно под OpenCL делать как-то иначе.

Update2 Предыдущий апдейт неверен, ибо (согласно Release Notes): 2. OpenCL - OpenGL Interop is not supported.

Comments

Писал месяц для CELL BE и CUDA.
1. С CUDA проще.
2. Это спец. процессоры для спец. задач.
Делать задачу специально под них - можно,
но переносить код с процессора общего назначения - увольте.
Проще переписать.

Естественно переписать, все другое.

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

странно, что в OpenCL нет взаимодействия с OpenGL. вроде как OpenCL спроектирован, чтобы использовать общие ресурсы с OpenGL и минимизировать переключение контентов. возможно просто не дореализовали стандарт.

Я вот писал со слов (из форума) и похоже был неправ (см. Update) - и интеграция есть и используется она в примере. Однако 80 против 320 GFLOP/s (прямо как оно пишет на экране) - медицинский факт, да и крутится ocl-ный пример сильно медленнее.

как вы сами написали, похоже, что сейчас OpenCL реализован (и пока не оптимизирован) поверх CUDA, отсюда и получаем оверхэд.
будем надеяться, что в будущем OpenCL будет реализован напрямую (или оптимизирован) и производительность будет не хуже, чем у CUDA.

>>придется писать по варианту программы под каждую видео-архитектуру
ну даже на CPU так всегда было и есть, чтобы получить 100% нужна специализация. для видео было бы здорово, если generic код давал 60-70% от оптимизированного. пока главная проблема это хоть как-то облегчить программирование и способствовать широкому внедрению. мощи у видео хватает, даже 60% будет очень хорошо.

Я собираюсь поделать микротесты на следующей неделе, сдается мне, что там не должно быть так уж плохо, а nBody - несчастный случай.

Вместе с тем, достаточно почитать того же Харриса про reduction (или про nBody) и уверенности в 60-70% от возможного пика - нет совсем.

Имеющий глаза да прочтет релизнотесы (это я себе):

2. OpenCL - OpenGL Interop is not supported.

<i>Даже если они появятся в условном OpenCL 1.1+, придется писать по варианту программы под каждую видео-архитектуру.</i>

Ну дак OpenGL всю жизнь такой. Альтернатива - это жизнь в стиле Мелкософт, сделать один стандарт и заставить всех паять железо под него. Зато в OpenGL новые фичи сильно раньше DirectX появляются.

Альтернатива от MS, да, есть (пока в виде эмулятора, впрочем)

Но я посмотрел на количество кода, которое нужно, чтобы сложить 1+1 и огорчился.

"И все у них так"&trade;

У меня тоже первая версия цветокорректора была на DX написана. Боже, как мне стало хорошо, когда наконец эти тормоза из ARB дотянули HLSL до стандарта!

Я имел в виду GLSL :-) Вот что такое половая травма.

Такое чувство что люди написавшие половину коментов не в состояние почитать спеки и код, идем сюда http://www.khronos.org/opencl/sdk/1.0/docs/man/xhtml/ там "OpenCL/OpenGL Sharing APIs" вот вам все функции необходимые для взаимодействия с OpenGL причем из коробки и в стандарте.

Если вы обратили внимание, речь о ситуации на май прошлого года. В той бете NVidia OpenCL (которая тут обсуждается) - не было взаимодействия OpenCL/OpenGL. С тех пор - появилось.

Но и на сегодня не все так уж здорово, скажем у ATI такое взаимодействие есть, но часть кода (например, из примеров SDK NVidia) - не работает. Часть - работает.

Вопрос такой... есть к примеру Nvidia GTX580 с 512PS (aka CUDA cores) и AMD 5780 c 1600PS (а ещё есть 5970 с 3200PS). Так вот... в некоторых тестах люди пишут, что арифметика сильнее у AMD. Это так? Просто я думаю, что лучше для брутфорса хешей.

Очень зависит от программы, как вы понимаете.

AMD - векторный (4-компонентные векторы), NVidia - cкалярный. Если получится векторность задействовать (без ветвлений и простоев), то AMD будет заметно быстрее. Кроме того, для настоящей эффективности для AMD все еще надо использовать тамошний ассемблер (CAL/IL), а OpenCL наивысшей эффективности не дает.

Много-чиповость (5970 и так далее) для брутфорса не помеха, как я понимаю, ну поделите задачу на две.

Add new comment