Страница 2: Архитектура Polaris

Сначала хотелось бы вернуться в прошлое, чтобы сравнить предыдущие этапы развития GPU с нынешним шагом. Например, в года 2001 и 2002, когда техпроцесс составлял 180 или 150 нм. Переход с RV100 на R300 стали серьезным шагом по увеличению производительности, площадь чипа почти удвоилась, несмотря на меньший техпроцесс. Мы получили значимые улучшения по архитектуре, вместо 30 млн. транзисторов теперь использовалось 110 млн., вместо 1 блока пиксельных шейдеров – уже 8 блоков. Все это привело к существенному увеличению производительности.

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

Архитектура Polaris - Graphics Core Next 4.0
Архитектура Polaris - Graphics Core Next 4.0

С первым поколением архитектуры GCN (Graphic Core Next) AMD получила не только высокую производительность, но и значительное энергопотребление, особенно это касалось Radeon R9 290X и Radeon R9 290, самых быстрых видеокарт нового поколения. С годами AMD добавляла различные оптимизации, и чипы Tonga и Fiji уже хорошо раскрывают потенциал архитектуры, демонстрируя ее возможности.

Архитектура Polaris вновь является серьезным шагом вперед. Здесь можно назвать такие термины, как Primitive Discard Accelerator, Hardware Scheduler или Instruction Pre-Fetch, но без глубокого погружения в архитектуру их суть объяснить сложно. Проще для понимания улучшенная эффективность работы шейдеров, а также функция, увеличившая эффективность всего GPU Polaris: сжатие памяти. NVIDIA применяет цветовую дельта-компрессию еще с первого поколения Maxwell, что позволило эффективно использовать не самые широкие интерфейсы памяти. AMD с новой High Bandwidth Memory у GPU Fiji обошла ограничения пропускной способности памяти с другой стороны, но от сжатия выигрыш тоже будет заметен. Особенно это касается видеокарт без HBM, которая и в 2016 году останется прерогативой high-end GPU.

Архитектура Polaris - Graphics Core Next 4.0
Архитектура Polaris - Graphics Core Next 4.0

Старт Polaris AMD наметила с двумя версиями чипа: Polaris 10 и Polaris 11. Polaris 10 будет использоваться в видеокартах Radeon RX 480 и Radeon RX 470. В случае Radeon RX 480 доступна полная конфигурация GPU. Командный процессор (Graphics Command Processor) работает с двумя аппаратными диспетчерами (Hardware Scheduler, HWS) и четырьмя движками Asynchronous Compute Engines (ACE), которые обеспечивают распределение вычислительных задач. 36 вычислительных блоков CU (Compute Units) содержат 2.304 потоковых процессоров, то есть в каждом CU присутствуют 64 потоковых процессоров (36 x 64). Добавьте сюда 4 геометрических процессора и пиксельную пропускную способность 32 пикселя на такт. Не обошлось без 114 текстурных блоков, 2 Мбайт кэша L2, 576 32-битных блоков load/store и 256-битной шины памяти.

Radeon RX 470 использует тот же GPU Polaris 10, но в урезанном виде. Доступны только 32 блока CU, то есть видеокарта опирается на 2.048 потоковых процессоров. Интерфейс памяти остался 256-битным, но AMD предусмотрела конфигурацию памяти только 4 Гбайт. Частота памяти составляет 1.750 МГц. Типичное энергопотребление – 110 Вт, из которых 85 Вт приходится на GPU.

Архитектура Polaris - Graphics Core Next 4.0
Архитектура Polaris - Graphics Core Next 4.0

Для видеокарты Radeon RX 460 AMD будет использовать GPU Polaris 11. Он опирается на 14 CU, что дает 896 потоковых процессоров. Отметим 64 текстурных блока и 128-битный интерфейс памяти. Кэш L2 урезан до 1 Мбайт по сравнению с GPU Polaris 10. Число 32-битных блоков load/store уменьшено до 256. 2 или 4 Гбайт памяти GDDR5 будут работать на частоте 1.750 МГц. Пропускная способность памяти составляет 112 Гбайт/с. Энергопотребление видеокарты будет на уровне 75 Вт, из которых 48 Вт приходится на чип.

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

Primitive Discard Accelerator

Архитектура Polaris - Graphics Core Next 4.0
Архитектура Polaris - Graphics Core Next 4.0

Primitive Discard Accelerator предназначен для предотвращения избыточной тесселяции. Среди всего прочего, AMD ориентируется на некоторые методы GameWorks, которые используют тесселяцию, но при этом выигрывают от особенностей архитектуры GPU NVIDIA, чего нельзя было сказать о видеокартах AMD. Например, при некоторых уровнях тесселяции эффект уже не будет заметен, будет лишь тратиться производительность.

Primitive Discard Accelerator представляет собой фильтр рендеринга, который распознает подобные чрезмерные вычисления и убирает их. Освобожденная вычислительная производительность уходит на то же сглаживание MSAA. Для повышения эффективности работы шейдеров AMD использует новый индекс-кэш для геометрических объектов, который позволяет сохранять данные дольше. В результате данные не придется часто перебрасывать между кэшем и памятью, увеличивается пропускная способность примитивов.

Архитектура Polaris - Graphics Core Next 4.0
Архитектура Polaris - Graphics Core Next 4.0

Еще один способ повышения эффективности архитектуры – улучшенная предварительная выборка инструкций (prefetch). Она позволяет более эффективно заполнять конвейер рендеринга, чтобы в нем было меньше "пузырьков" бездействия. AMD увеличила или оптимизировала кэши и буферы. В частности, здесь важен кэш L2, который повышает эффективность работы с видеопамятью.

У архитектуры GCN 4-го поколения имеется "родная" поддержка FP16 и Int16, в том числе "родные" 16-битные регистры и 16-битный mapping. Данная мера уменьшить энергопотребление и снизить занимаемое пространство/пропускную способность видеопамяти и регистров, поскольку для расчетов FP16 не потребуется занимать ресурсы FP32. Вычисления FP16 важны для графики, приложений фото и видео, а также для глубокого обучения (Deep Learning).

Архитектура Polaris - Graphics Core Next 4.0
Архитектура Polaris - Graphics Core Next 4.0

Новый контроллер памяти GPU Polaris поддерживает GDDR5 с тактовыми частотами до 2.000 МГц. Пропускная способность составляет 256 Гбайт/с. Если сравнивать с предшественником Radeon R9 380, AMD увеличила пропускную способность примерно на 50 процентов.

Но более важна технология сжатия памяти. Как и NVIDIA, AMD добавила новые сценарии сжатия памяти. Технология сжатия особенно важна при использовании узких интерфейсов. 256-битный интерфейс Radeon RX 480 кажется очень узким по сравнению с 512-битным у GPU Hawaii или 4.096-битным у видеокарт с памятью HBM или HBM2 от AMD и NVIDIA. Поэтому AMD желает компенсировать сравнительно узкий интерфейс памяти с помощью технологии цветовой дельта-компрессии (Delta Color Compression, DCC), по крайней мере, в некоторой степени. Технология цветовой дельта-компрессии используется в GPU AMD и NVIDIA на протяжении нескольких поколений. Например, NVIDIA перешла на четвертое поколение технологии сжатия. AMD использовала сжатие с GPU Tonga на видеокартах Radeon R9 295. В последнее время AMD вновь акцентировала реализацию цветовой дельта-компрессии в архитектуре GCN. Важно напомнить, что сжатие осуществляется без потерь. Никакие данные не теряются, разработчики могут использовать данный метод без какой-либо специальной адаптации программного обеспечения.

Технология DCC подразумевает хранение полной информации о базовом пикселе, а окружающие пиксели в матрице 8x8 сохраняются в виде отличий (дельты). Поскольку близко расположенные пиксели обычно мало отличаются по цвету, хранение для них разницы оказывается по объёму информации выгоднее, чем полного значения цвета. Поэтому в случае дельта-компрессии информация о пикселях занимает меньше места в памяти, также достигается экономия пропускной способности памяти. В качестве примера работы технологии можно привести полностью черный и белый блоки, которые будут храниться в памяти как {1.0, 0.0, 0.0, 0.0} или {0.0, 1.0, 1.0, 1.0}. Здесь можно сэкономить ресурсы, сохраняя только 0.0 или 1.0 в качестве значения.

К уже известным сценариям сжатия 2:1 и 1:4 добавляется еще один, а именно 8:1, который обеспечивает еще более сильное сжатие. AMD говорит об увеличении производительности с новым методом на 38%. Конечно, данное значение носит теоретический характер. Оценить на практике влияние цветовой дельта-компрессии сложно, поскольку она выполняется на аппаратном уровне, выключить сжатие может только сама AMD в драйвере. Поэтому приходится довольствоваться тестами, сделанными AMD.

Архитектура Polaris - Graphics Core Next 4.0
Архитектура Polaris - Graphics Core Next 4.0

Конечно, пропускная способность памяти 384 или 320 Гбайт/с у новой видеокарты урезана до 256 Гбайт/с, но благодаря Delta Color Compression и удвоению кэша AMD планирует обеспечить существенный прирост производительности памяти и эффективности. Причем AMD не только увеличила размер кэша, но и оптимизировала его работу. Теперь чтение и запись в кэш осуществляются быстрее, также были ускорены процессы выделения разных областей данных. Все эти меры улучшают эффективность энергопотребления подсистемы памяти и усиливают преимущества DCC.

Asynchronous Compute

Архитектура Polaris - Graphics Core Next 4.0
Архитектура Polaris - Graphics Core Next 4.0

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

Поэтому и были придуманы асинхронные шейдеры (Asynchronous Shader), которые призваны облегчить взаимодействие движка, драйверов и аппаратной части, а также улучшить распределение задач. С появлением первых видеокарт на GPU "Hawaii" AMD начала говорить об улучшениях вычислений на GPU благодаря движкам Asynchronous Compute Engines. Впрочем, данные аппаратные блоки присутствовали во всех GPU на архитектуре GCN. Они предназначены для вычислений на GPU, но игры DirectX 12 их тоже могут задействовать.

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

Архитектура Polaris - Graphics Core Next 4.0
Архитектура Polaris - Graphics Core Next 4.0

С появлением DirectX 12 разработчики получили существенно большие возможности контроля над вычислительными блоками, в том числе и возможность лучшего распределения задач. Но здесь API налагает определенные требования. Современные игры должны разбивать задачи на очереди, которые можно выполнять независимо друг от друга. На примере задачи распределяются по очередям графики, вычислений и копирования. API, в данном случае DirectX 12, затем распределяет очереди по доступным ресурсам GPU.

Подход кажется простым, но на практике он более сложен, поскольку данные отдельные очереди необходимо распределять по свободным ресурсам GPU. AMD описывает данный процесс рендеринга на примере автомобильного трафика, используя перекресток и светофор. Как раз светофор – это диспетчер, который должен распределить процессы по движку рендеринга. Здесь все участники движения имеют равный приоритет. Им приходится ждать, пока освободится ресурс, такая диспетчеризация не самая оптимальная.

Архитектура Polaris - Graphics Core Next 4.0
Архитектура Polaris - Graphics Core Next 4.0

Один из способов улучшить процесс заключается в приоритезации. В таком случае можно задать приоритет некоторым задачам. Например, в случае автомобильного трафика можно остановить синюю очередь, чтобы обработать фиолетовую очередь с более высоким приоритетом – она будет отправлена на рендеринг. Но и здесь приходится переключаться между разными очередями, эффективность не всегда заметно повышается.

И здесь AMD представляет асинхронные вычислительные движки (ACE, Asynchronous Compute Engines). Они позволяют одновременно обрабатывать несколько очередей команд, которые получается более эффективно встраивать в конвейер рендеринга. На примере с автомобильным трафиком использование ACE можно представить как управление каждым транспортным средством в определенном порядке и с нужным интервалом. Если все очереди команд будут поступать хаотично, то мы получим столкновения. Их и предотвращают ACE, помещая команды в очередь. Такой способ позволяет избавиться от пустых мест в очереди на конвейер, более оптимально используя потенциал производительности. Также можно выставлять приоритеты определенным процессам.

Quick Response Queue

Quick Response Queue, которая является частью Asynchronous Shaders или непосредственно связана с этой технологией. QRQ была впервые упомянута AMD около года назад, и тоже в связи с Asynchronous Shaders. Кроме этого, Quick Response Queue работает совместно с Asynchronous Time Warp, о чем мы напишем позднее. Эта функция призвана решить некоторые проблемы вычислений (и расстановки приоритетов), когда речь идет о использовании шлема виртуальной реальности.

Архитектура Polaris - Graphics Core Next 4.0
Архитектура Polaris - Graphics Core Next 4.0

На первом примере AMD показывает работу потоковых процессоров в простом сценарии Pre-Emption. В этом случае графические и другие вычисления выполняются последовательно друг за другом в зависимости от того, какое место они занимают в очереди. Общее время выполнения задач увеличивается из-за нерационального использования ресурсов. Ситуация немного меняется при использовании Asynchronous Shaders. Различные задачи в этом случае могут выполняться одновременно разными потоковыми процессорами. Благодаря этому, общее время вычислений значительно сокращается, но некоторые приоритетные задачи, которые необходимо завершить быстрее, будут выполняться дольше из-за одновременной загрузки потоковых процессоров.

Использование Asynchronous Shaders вместе с QRQ приводит к тому, что критические задачи получают больший приоритет. Поэтому наиболее важным процессам отдается больше ресурсов, и они выполняются быстрее. В итоге общее время вычислений немного увеличивается, но важные процессы выполняются гораздо быстрее, чем при использовании других сценариев.