Pentium4 производства AMD, часть 5

Использование OpenCL

Производители GPU договорились унифицировать язык программирования, чтобы обеспечить совместимость программ с GPU различных вендоров. Это совсем не сложно, как уже было отмечено выше, микроархитектуры всех графических процессоров достаточно схожи. Но все-таки интересен вопрос, на сколько быстро будет выполняться OpenCL-программа, разработанная на одном GPU, на системе с карточкой другого производителя?

В первую очередь, это должно быть интересно AMD, так как NVIDIA предоставляет более отлаженную платформу и разрабатывать будут в первую очередь на ней. Надо сказать, если программа не очень глубоко оптимизирована под конкретный GPU, просто параллельная OpenCL-программа, то её архитектурные предпочтения равновероятны независимо от того, на какой архитектуре она разрабатывалась. Но если программа жёстко ориентируется на специфику GPU NVIDIA, в первую очередь на размер варпа, она сама разбивает нити на пучки по 32 и внутри варпа не предполагается дивергентных ветвлений, только различные варпы могут разбегаться по программе, то на AMD, с её вдвое большим размером warp, такая программа легко может работать в два раза медленней.

Также, GPU могут отличаться в оптимальной организации доступа к памяти. Если программа очень жёстко настроена на специфику банков памяти NVIDIA, то она не получит такого же прироста от этой оптимизации на Radeon. Надо сказать, что на данный момент тонкие вопросы оптимизации доступа к памяти очень слабо документированы для Radeon, и в целом документация не совсем полна и непонятно организована. Документация на CUDA выглядела несколько смутной, по сравнению с руководствами по программированию и оптимизации для CPU, а документация AMD выглядит смутной по сравнению с описаниями CUDA.

Для того, чтобы близко приблизиться к теоретическому максимуму производительности, надо учитывать особенности того или иного конкретного GPU. Оптимизация для одной из архитектур может быть немного деоптимизацией для другой, и AMD будет несколько страдать от недостатка внимания. То есть, производительность будет в целом несколько меньше, чем могла бы, если бы разработчики, в первую очередь, ориентировались на специфику AMD.

Например, у Fermi, GT200 и Radeon различный размер локальной памяти. 48 Кб (без учета 16 Кб L1), 16 Кб и 32 Кб соответственно. Для NVIDIA часто лучше ориентироваться на размер памяти 16 Кб, в этом случае программа пойдет на всех GPU — и старых, и новых. А Fermi сможет просто 3 блока нитей исполнять вместо одного на GT200, так как он, со своими 48 Кб памяти, будет выглядеть как три минипроцессора старого образца. А для AMD лучше сделать вариант с использованием 32 Кб локальной памяти, он будет быстрее работать, вероятно. Если бы Evergreen был неким стандартом, самым массовым продуктом, на который в первую очередь ориентируются разработчики, то могли бы пострадать уже изделия NVIDIA. Следующим образом, программа ориентируется на размер локальной памяти 32 Кб, для 16 Кб GT200 запускается какой-то совместимый вариант, который работает не очень оптимально, а на Fermi не используется дополнительный размер кэша, а только 32 Кб, хотя он на самом деле больше.

Также, для Radeon желательна векторизация и использование векторных типов данных, в том числе чтобы загрузить векторные регистры. И более агрессивное избавление от ветвлений. Некоторые фирмы смогут выделить ресурсы для эквивалентной оптимизации, некоторые вообще не озаботятся низкоуровневой оптимизацией. Можно сказать, что ситуация, отчасти, напоминает ситуацию с десктопными процессорами, где Intel гораздо лучше поддерживает разработчиков, только тут в роли Intel выступает NVIDIA.

Вот если бы поменять местами программную поддержку NVIDIA и AMD, то есть: AMD работала бы над продвижением GPU, как NVIDIA сейчас, CUDA бы работала уже давно на Radeon, а на GeForce был бы Brook+ и недоделанный компилятор OpenCL, то с учётом доступности в настоящее время, относительной дешевизны и высокой пиковой производительности Evergreen, он бы стал фактическим стандартом, как Pentium 4 в своё время. Однако можно снова сказать, что у AMD несколько другие планы, и универсальные вычисления на GPU для неё вторичны.

Но с точки зрения прироста относительно тех же процессоров, который в удобных для GPU случаях составляет разы и порядки, отличия в скорости между NVIDIA и AMD в десятки процентов из-за различного уровня оптимизации, смотрятся не так значительно и принципиально.

НазваниеКоличество чиповЧастотаКоличество SIMD EngineКоличество VLIW модулейПроизводительность в floatПроизводительность в double
Radeon HD5970 2 725 MHz 40 640 4,64 TFLOPS 928 GFLOPS
Radeon HD5870 1 850 MHz 20 320 2,72 TFLOPS 544 GFLOPS
Radeon HD5850 1 725 MHz 18 288 2,09 TFLOPS 418 GFLOPS
Radeon HD5770 1 850 MHz 10 160 1,36 TFLOPS
Radeon HD5750 1 700 MHz 9 144 1,008 TFLOPS
Radeon HD5670 1 775 MHz 5 80 0,620 TFLOPS

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

Ссылки