7994420702;horizontal

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

Идеология AMD  

Если сравнивать общую линию развития GPU различных вендоров, то всё же можно заметить признаки того, что Evergreen делает фирма-изготовитель процессоров. Они считают, что GPU — это некое дополнение к CPU, они не планируют развивать функциональность GPU за грань специализации, а нацеливают его на большую потоковую производительность. Так что даже мелкие архитектурные детали и отличия от GPU NVIDIA имеют свой смысл.

AMD рассматривает GPU как некий сопроцессор. У них есть планы интегрировать, со временем, GPU и CPU в один кристалл. Они не собираются устраивать конкуренцию между своими GPU и CPU.

Fermi и Evergreen изготавливаются по одному техпроцессу. Но функциональность Fermi гораздо шире, он может делать многое и помимо сложения и умножения. В частности, в Fermi заявлена полная поддержка C++ и виртуальных функций, чего нет в Radeon, хотя они оба одного поколения DirectX 11.

Pentium 4 среди процессоров тоже относительно не любил виртуальные функции. Для всех процессоров рекомендуется в критических участках кода не использовать вызовы функций, а писать линейный код, но для Pentium 4 это было наиболее важно. А для ускорителей вызовы функций пока в диковинку и не случайно NVIDIA первой вводит эту возможность. Для сопроцессора AMD это не очень нужно.

Ниже, мы специально сравним Fermi и Evergreen, но сразу надо сказать, что Evergreen — это прежде всего 3D-ускоритель, а Fermi — это пятьдесят на пятьдесят, если не больше (в сторону универсальных вычислений). AMD, в их жестокой конкуренции за десктопный рынок с Intel, важно иметь классный GPU, дешёвый и мощный, чтобы продвигать свою платформу, то есть отгружать поставщикам сразу связку процессор+видео. Поэтому избыточной для графики функциональности в Evergreen нет.

Например, это выразилось в том, что локальная память минипроцессора имеет размер в 32 Кб, что только в два раза больше предыдущего поколения, изготовленного по более старому техпроцессу. Тогда как Fermi имеет 64 Кб, что упрощает использование GPU для широкого круга задач и приближает GPU к процессору. Но это избыточно для графики и увеличивает площадь кристалла, делает ускоритель более дорогим, что AMD не нужно. Поэтому AMD не увеличила радикально размер локальной памяти минипроцессора, хотя, наверное, могла.

К сожалению для всех, неприоритетность использования GPU в универсальных вычислениях для AMD выразилась в том числе и в том, что программная поддержка существенно отстала от железа.

Проблемы программной поддержки  

Абсолютная теоретическая производительность GPU увеличивается с переходом на более тонкий техпроцесс в большей степени, чем мощность центральных процессоров. Новые транзисторы превращаются в новые вычислительные блоки, что, ввиду полностью параллельной модели вычислений на GPU, напрямую увеличивает скорость расчетов. С переходом на современный 40 нм техпроцесс вычислительная сила GPU Radeon достигла колоссальных значений. Она уже измеряется в терафлопах, даже не гигафлопах. Но приложений, использующих эту мощность Radeon, весьма мало. И в этом виновата сама AMD. Потому, что написать их пока затруднительно. Это не вина вполне стандартной архитектуры GPU, причина в отсутствии надлежащих инструментов программирования.

Произошло вот что: AMD свернула разработку собственного языка программирования Brook+ для своих GPU и переключилась на поддержку OpenCL и DirectCompute. Это здравое решение, потому что разница невелика, AMD участвовала в разработке OpenCL, текущая ревизия OpenCL вполне соответствует возможностям железа AMD. Но получилось так, что Brook+ уже не поддерживается, а компилятор и драйвер OpenCL ещё толком не сделаны. Получилась переходная ситуация. Вот, в текущий момент, когда пишутся эти строки, программировать для Radeon трудно, с технической точки зрения. Компилятор OpenCL для Radeon 5XXX работает медленно и с ошибками. Ошибки бывают трёх видов:

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

Ещё несколько месяцев назад ошибки компилятора были абсолютно критическими, но и сейчас, чтобы программировать на OpenCL для Radeon, надо быть весьма квалифицированным программистом: надо уметь, при случае, отличить собственную ошибку от ошибки компилятора и обходить различные непроработанные места. Но это ещё половина беды, последняя версия OpenCL SDK от AMD не имеет программной поддержки некоторых функций OpenCL, которые во всю используются для программирования GPU, как NVIDIA, так и старых Radeon. Причем, аппаратная поддержка этих функций, естественно, есть. А именно, нет поддержки чтения данных из двумерных массивов с помощью текстурных выборок и с возможным использованием фильтрации. Это во всю используется в CUDA-программах, которые предполагается портировать под OpenCL, чтобы они работали на всех GPU. Это востребовано, потому что чтение из текстур кэшируется с помощью кэшей первого и второго уровней. Что интересно, иерархия кэшей несколько сходна, в данном случае, и у NVIDIA, и у AMD: каждый минипроцессор имеет read-only кэш L1 размером 6–8 Кб и больший L2 кэш, на несколько минипроцессоров. Такая архитектура кэшей оптимальна для чтения текстур в современной 3D графике.

Вот нельзя просто взять CUDA-программу и беспроблемно портировать её на Radeon. CUDA-программа автора статьи так же использует хранение данных в текстурах, то есть, в терминологии OpenCL — доступных только для чтения массивов, поэтому её портировать пока затруднительно. Общее же развитие драйверов и т.п., по степени сырости, соответствует тому, что было у NVIDIA, примерно год назад. Присутствуют проблемы совместимости с различными операционными системами. Например, существенно падает производительность в 32-битном режиме. В некоторых версиях Linux, если OpenCL-программа даёт ошибку исполнения, то надо всю систему перезагружать.

Упущенные возможности AMD  

Вероятно, с новыми релизами драйверов и инструментов от AMD, в OpenCL SDK недоработки будут исправлены, но время уже упущено. Хотя Evergreen появился на рынке некоторое время назад, конкурировать ему (в части вычислений на GPU) придется с Fermi, и карточки Radeon будут смотреться не очень выигрышно. Но Radeon57XX, по своим вычислительным возможностям, гораздо мощнее GT200 и менее сложный в программировании, с точки зрения железа. Но из-за отсутствия должной программной поддержки, Radeon не очень привлекателен для GPGPU-программистов. А AMD имела хороший шанс утвердить свой ускоритель, как стандартный для растущего числа неграфических пользователей GPU. Чтобы, например, оптимизировали программы в первую очередь под него, с учетом его особенностей, того же собственного размера варпа и объёма локальной памяти.

Но похоже, что история с Intel Pentium 4 ничему не научила AMD: кому был бы нужен P4 без оптимизирующего компилятора и оптимизированных для него различных кодеках, плеерах и другого ПО? И как важно, что разработчики уделяют главное внимание оптимизации под наиболее распространенную архитектуру. Но можно повторить, для AMD данное направление неприоритетное, а с учетом малого внимания AMD к программной поддержке собственного железа, на поддержку программной среды для GPU пришлось совсем мало ресурсов.

Так что сейчас терафлопы Evergreen лежат почти мёртвым грузом. Должно пройти ещё какое-то время, пока появится достаточное количество приложений, их использующих, хотя они могли бы быть готовы уже сейчас. Можно было сделать возможность тривиально портировать уже существующие CUDA-приложения, и они бы заработали гораздо быстрее, чем на текущих GeForce, не говоря уже о современных CPU.