API-интерфейс API CUDA и время выполнения CUDA

При написании приложений CUDA вы можете либо работать на уровне драйвера, либо на уровне выполнения, как показано на этом изображении (библиотеки CUFFT и CUBLAS для передовой математики):

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

Я использую CUDA.net для взаимодействия с С#, и он построен как копия API-интерфейса драйвера. Это побуждает писать много довольно сложного кода на С#, в то время как эквивалент С++ будет более простым с использованием API среды выполнения. Есть ли что-то, что можно выиграть, делая это так? Единственное преимущество, которое я вижу, заключается в том, что проще интегрировать интеллектуальную обработку ошибок с остальной частью кода С#.

Ответ 1

Среда выполнения CUDA позволяет компилировать и связывать ваши ядра CUDA с исполняемыми файлами. Это означает, что вам не нужно распространять файлы кубинов с вашим приложением или заниматься загрузкой их через API-интерфейс драйвера. Как вы уже отметили, это, как правило, проще в использовании.

Напротив, API-интерфейс драйвера сложнее программировать, но обеспечивает больший контроль над использованием CUDA. Программист должен непосредственно иметь дело с инициализацией, загрузкой модуля и т.д.

По всей видимости, более подробная информация об устройстве может быть запрошена через API-интерфейс драйвера, чем через API среды выполнения. Например, свободную память, доступную на устройстве, можно запросить только через API-интерфейс драйвера.

В Руководстве программиста CUDA:

Он состоит из двух API:

Низкоуровневый API, называемый API драйверов CUDA,

API более высокого уровня, называемый API-интерфейсом CUDA, который реализован поверх API-интерфейс драйвера CUDA.
Эти API являются взаимоисключающими: приложение должно использовать либо один, либо другие.

Время выполнения CUDA облегчает управление кодом устройства, обеспечивая неявное инициализация, управление контекстом и управление модулем. Код хоста C генерируемый nvcc, основывается на времени выполнения CUDA (см. раздел 4.2.5), поэтому приложения, которые ссылаются на этот код, должны использовать API выполнения CUDA.

В отличие от API-интерфейса драйвера CUDA требуется больше кода, сложнее программировать и debug, но предлагает более высокий уровень контроля и не зависит от языка, поскольку он только имеет дело с кубическими объектами (см. раздел 4.2.5). В частности, сложнее настраивать и запускать ядра с использованием API-интерфейса драйвера CUDA, поскольку выполнение параметры конфигурации и ядра должны быть указаны с явными вызовами функций вместо синтаксиса конфигурации выполнения, описанного в разделе 4.2.3. Кроме того, устройство эмуляция (см. раздел 4.5.2.9) не работает с API-интерфейсом драйвера CUDA.

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

Ответ 2

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

Мои первоначальные попытки с различными обходами в API runtime все приводили к сбою, иногда эффектно - я обнаружил, что могу многократно, сразу перезагружать машину, выполняя только неправильный набор вызовов CUDA из разных потоков.

Поскольку мы перенесли все по API-интерфейсу драйвера, все было хорошо.

Ответ 3

несколько важных замечаний:

сначала различия между API-интерфейсами применяются только к коду стороны. Ядра точно такие же. на стороне хоста сложность драйвера api довольно тривиальна, основные отличия заключаются в следующем:

в драйвере api у вас есть доступ к функциям, которые недоступны в сценариях api, таких как runtime.

эмулятор работает только с кодом, написанным для api времени выполнения.

oh и в настоящее время cudpp, который представляет собой очень удобную библиотеку, работает только с api runtime.

Ответ 4

Есть некоторые реальные проблемы с выравниванием аргументов и API-интерфейсом драйвера. Для получения дополнительной информации посетите бета-версию CUDA 2.2 (или более поздней).