Подождите...Каталог
APU Kaveri: деталиЧипсетно-сокетное «ассорти»С выпуском APU Kaveri ситуация вокруг сокета и чипсета также претерпит изменения с сохранением некоторых отличий от чипов Richland. APU Kaveri подходят только к материнским платам с сокетом FM2+, который отличается от FM2 на 2 контакта, при этом чипы Richland/Trinity можно поставить в FM2+ гнездо. А вот APU Kaveri нельзя использовать в более старых платах с FM2. К семейству «бульдозерных» чипсетов добавляется новый набор системной логики – A88X, составляющий компанию чипсетам A55, A75 и A85X. Аналогично ситуации с APU Trinity и Richland, применение того или иного чипсета не будет решающим аргументом в пользу наличия в системной плате конкретного сокета – кроме A88X, который найдёт применение только в FM2+ платах. AMD ведёт работу в направлении создания решений, потенциально способных изменить правила игры на рынке платформ, и смена парадигмы программирования с «обычной» на HSA-ориентированную, конечно, обещает стать центральным моментом на фронте производства APU в обозримом будущем Итак, процессоры Kaveri предполагают установку в материнские платы с поддержкой нового сокета FM2+. Поскольку материнские платы FM2+ поддерживают APU с сокетом и FM2+, и FM2, их присутствие на рынке насчитывает многие месяцы. Однако поддержка APU Kaveri платами, представленными сегодня на рынке, может потребовать обновления BIOS, и поскольку в ассортименте компьютерных магазинов могут оказаться именно такие модели (со старой прошивкой), перед покупкой следует уточнить наличие в плате свежей BIOS. Демонстрация чипами Kaveri раздробленности поколений служит признаком давления рынка и отражает историю AMD, отражая желание пользователя видеть обратную совместимость либо совместимость снизу вверх для процессоров и материнских плат. В нашем случае совместимость процессоров демонстрирует следующая таблица:
Отсутствие совместимости APU Kaveri с FM2 платами на физическом уровне обеспечивают 2 дополнительные ножки. В рамках настоящего тестирования используются материнские платы ASRock FM2A88X Extreme6+ и FM2A88X-ITX+.  Усложняет ситуацию решение AMD использовать в FM2+ платах «ассорти» из старых и новых чипсетов. APU Kaveri будут работать с чипсетами A55, A78 и A88X, но не с A75, применяемым в платах для процессоров на ядре Llano с сокетом FM1. Ещё большую путаницу вызывает следующий факт: тогда как старые APU Richland можно ставить в FM2+ платы на базе A88X, более старые платы с поддержкой FM2 не будут использовать чипсет A88X. Для большей наглядности составим таблицу:
Хотя даже таблица не даёт предельно чёткой картины совместимости, она всё же помогает сориентироваться в ситуации. По сути, любая плата с A88X подойдёт для APU Kaveri. Касательно плат с A78, на данный момент складывается впечатление, что они тоже будут поддерживать только процессоры с сокетом FM2+ – здесь главное не спутать их с AM3 платами на более старом чипсете AMD 780L, где наличие данного чипсета отражается в названии платы в виде буквенно-цифрового кода “А78”. Чипсет A55 почти что универсален – в его ведении и FM1, и FM2 платы. Сравнение чипсетов
Что касается различий между A85X и A88X, то их немного, и главным из них, пожалуй, является поддержка PCIe 3.0 – любые платы с FM2+ и A88 в паре с APU Kaveri используют все возможности PCIe 3.0 при задействовании одного слота в режиме 16х либо двух слотов в режиме 8х/8х. В A88X – исходная поддержка тех же 6-ти портов SATA 6Gb/s и 4-х портов USB 3.0. Интегрированный контроллер поддерживает RAID 0, 1, 5 и 10. Другим улучшением, заслуживающим упоминания, является переход на XHCI 1.0. AMD в несвойственной для себя манере поскупилась на предоставление информации об эволюции чипсетов посредством обычных каналов. Линейка FX и серверный рынокПросочившиеся в Сеть сведения о планах AMD не очень благоволят линейке FX, и её король, 8-ядерный FX-9590, похоже, останется на троне ещё какое-то время. Не мудрено, что AMD никак официально не комментирует ситуацию с отсутствием в ближайшее время новых процессоров FX на ядре Steamroller.  Ситуация с предложениями AMD на рынке серверов разнится в зависимости от того, какой дорожной картой руководствоваться. По одним данным, в этом году нас ждут процессоры Warsaw («Варшава») с ядрами Piledriver в количестве 12-16 шт, при этом high-end процессоры из линейки Opteron с архитектурой Piledriver сегодня вообще не упоминаются. Эту мысль иллюстрирует официальная июльская дорожная карта AMD, куда входят и ARM-чипы. Однако дорожная карта, просочившаяся недавно в Сеть, свидетельствует о появлении ядер Steamroller в составе однопроцессорных вычислительных кластеров; вслед за ними в 2015 году выйдет ядро Excavator, но пока топовыми решениями остаются CPU на базе Piledriver с поддержкой 12-16 потоков.  С прицелом на 1080p30fps и вычисленияВ плане вычислений APU Kaveri и APU Richland довольно чётко дистанцируются друг от друга (далее этот вопрос будет рассмотрен подробнее), но на более высоком уровне AMD стремится к промежуточному варианту между десктопной моделью (CPU + дискретная графика) и мечтой Apple Mac Pro о разгрузке вычислительных мощностей за счёт различных дискретных видеокарт, воплощая эту мечту в рамках одного процессора. На мероприятии, посвящённом техническим аспектам APU Kaveri, AMD показала слайд:  Теперь, когда Intel тоже в игре, встроенная графика становится весомым аргументом. Можно долго спорить о целесообразности дальнейшего использования компанией AMD аббревиатуры APU вместо SoC, но факт остаётся фактом: найти процессор без встроенной графики сегодня становится всё труднее. В отсутствие вертикальной интеграции программная оптимизация всегда отстаёт от доступности железа. Если вспомнить, что переломный момент, когда чипы APU/SoC взяли верх на рынке, приходится на недавнее прошлое – 2011 год, становится ясна причина отсутствия агрессивных шагов со стороны разработчиков программного обеспечения в направлении использования ресурсов GPU в вычислениях общего назначения. Проблема, в том числе, заключалась в модели программирования, и решением этого вопроса AMD надеется заняться с выходом Kaveri/HSA. APU Kaveri в полном объёме поддерживают архитектуру гетерогенного однородного доступа к памяти (hUMA), реализующую возможность доступа топологии встроенной графики ко всему пространству памяти в распоряжении CPU, предлагая к услугам разработчиков ресурс устройств с поддержкой до 32 Гб оперативной памяти для вычислений. Ещё одна сложность, связанная с реализацией концепции вычислительных задач, –время. Обеспечение возможности общения CPU с GPU без HSA и hUMA требует нешуточных накладных расходов. В случае с вычислениями имеет место ситуация, когда CPU и GPU позволено совместно работать над одним и тем же массивом данных одновременно, вследствие чего все вычисления в рамках одной и той же задачи фактически выполняются без необходимости асинхронных вызовов, связанных с копированием данных из памяти, и дорогостоящих проверок памяти на согласованность действий.  В экосистеме HSA AMD столкнулась с проблемой необходимости привлечения разработчиков. Часто проводят такую аналогию: в первый день существования платформа iOS имела очень ограниченное число приложений, а сегодня их насчитывается миллионы. Здесь, возможно, кроется важный нюанс: Apple способна управлять своей платформой и в целом системой во всей полноте, тогда как AMD приходится конкурировать в том же сегменте, где «живут» продукты без HSA, и в этом смысле ей недостаёт возможностей для контроля. Тем не менее, AMD посредством HSAIL (HSA Instruction Layer) пытается осуществить как можно более плавную интеграцию средств программирования для HSA (и OpenCL 2.0) во все современные платформы с целью обеспечения данного функционала языками программирования, такими как Java, C++ и C++ AMP (а также библиотеками и инструментами API) не в ущерб коду или с его минимальным переписыванием.  Что касается игр, то 30 FPS на встроенной графике были целью AMD на протяжении двух поколений. Любой игре могут оказаться по плечу 30 FPS при условии достаточно сильной подкрутки настроек в меньшую сторону, но тут AMD использует ограничение в виде разрешения не меньше 1080p – весьма непростая задача для некоторых достаточно «тяжёлых» современных игр. В ходе нашего тестирования стало ясно, что у пользователя был выбор: начать с высокого разрешения и постепенно сбавлять настройки либо, удерживая настройки на среднем/высоком уровне, подбирать разрешение. Игры, наподобие BF4 и Crysis 3, вряд ли будут милосердны к графической подсистеме, особенно с включением дополнительных DirectX 11 функций – ambient occlusion, depth of field, global illumination, bilateral filtering и некоторых других, упомянутых AMD. «Ядерная» проблемаПереход на процессоры SoC (система на чипе), обладающие высокой степенью интеграции, акцентировал внимание на отсутствии единого подхода к подсчёту ядер. Рекламируя чипы SoC, Apple, Intel и Qualcomm продолжают считать CPU-ядра. В случае с Apple и Qualcomm картина неполная ввиду не особого желания обоих производителей распространяться на тему конфигураций GPU-ядер. Из недавнего: NVIDIA заняла весьма оригинальную позицию, учитывая ядра CUDA в составе GPU-сегмента в Tegra K1 SoC. Motorola пошла необычным путём, суммируя CPU, GPU и расположенные вне кристалла сопроцессоры в составе платформы X8 в смартфоне Moto X. В конце концов, придётся выработать какой-то подход, позволяющий охарактеризовать эти SoC высокой степени интеграции, особенно когда большинство реальных применений задействуют ресурсы и CPU-, и GPU-ядер. С выходом Kaveri наличие по-настоящему единой архитектуры для совместной работы CPU и GPU поставило AMD в уникальное положение, диктующее необходимость создания новой номенклатуры для использования в будущем. В условиях, когда 47% площади кристалла Kaveri отводится под нужды GPU, а сама архитектура рассматривает CPU- и GPU-компоненты равноправными партнёрами, становится понятным стремление AMD говорить о совокупности ядер в составе APU. AMD выбрала термин «вычислительное ядро» (Compute Core – СС), означающий либо x86 CPU-ядра (которые, в конце концов, могут превратиться в CPU-ядра на базе ARM), либо вычислительный модуль GCN. Схематично это выглядит так:
Таким образом, high-end модель A10-7850K суммарно содержит 12 вычислительных ядер: 4 ядра в CPU (2 модуля с архитектурой Steamroller, по 2 потока на каждый) и 8 ядер в IGP (8 вычислительных блоков в IGP серии R7).  Однако есть ряд оговорок. Технически AMD права: каждый вычислительный блок IGP и каждый поток CPU позволяет выполнить отдельный код. Реализация архитектуры GCN в графических процессорах Hawaii позволяет совладать с программными ядрами (kernel) в количестве, равном числу вычислительных блоков, тогда как пару поколений назад действовало ограничение – одновременно не более 1-го вычислительного программного ядра (kernеl) на GPU (задание просто фрагментировалось к выполнению вычислительными блоками). Однако имеющиеся 12 вычислительных блоков не равноценны, и для использования всей доступной вычислительной мощи программисту нужно писать код с учётом специфики CPU и GPU. Всякий раз, когда AMD или её партнёры рекламируют новый APU, AMD чётко озвучивает необходимость использовать два набора цифровых характеристик для Compute Cores – суммарное число и разбивку по CPU/GPU сегментам. В случае с A10-7850K это означает: «12 вычислительных ядер с разбивкой по схеме “4 CPU + 8 GPU”». Остаётся только приветствовать решение AMD не усложнять идентификацию пользователем внутренней конфигурации APU. Такой подход, кажется, наиболее рационален с точки зрения стремления AMD похвастаться суммарной вычислительной мощью APU, а также сообщить фактическую конфигурацию SoC тем пользователям, кто хотя бы немного «в теме». Наибольшую сложность представляет решение вопроса с информированием о фактическом положении вещей пользователей, автоматически рассуждающих в направлении «чем больше ядер, тем круче». Здесь корень проблемы во многом схож с тем, что имело место при обсуждении ситуации с рейтингом процессоров Athlon XP. Объяснение конечному пользователю хитросплетений программирования CPU/GPU ничем не отличается от объяснения большей значимости формулы «число исполняемых в секунду инструкций, помноженное на частоту» в сравнении с «голой» частотой.  При работе программиста с APU профилировщик OpenCL должен обнаружить 8 вычислительных блоков в составе GPU и отобразить их, при этом именно программист должен извлечь максимальную для конкретной ситуации пользу от работы потоков, даже с учётом наличия в процессорных модулях Bulldozer 3-го поколения и блоков операций над целыми числами, и блоков вычислений двойной точности с плавающей запятой. На момент релиза AMD предлагает следующие конфигурации:
Проблема с «перегонкой» вычислительной мощи APU в определённое количество ядер лежит главным образом в плоскости CPU. Тогда как частота GPU будет удерживаться примерно на одном уровне (720 МГц в случае с упомянутыми выше 3-мя моделями), частота CPU будет отличаться существенно, особенно в случае с A8-7600 с изменяемым TDP, который при 45 Ваттах лишится 300-400 МГц. Ключевые улучшения в архитектуре SteamrollerSteamroller – не претерпевшее радикальных изменений воплощение идей Bulldozer. Перед нами всё тот же 2-ядерный модуль с двумя независимыми блоками целочисленных операций и с одним разделяемым блоком вычислений с плавающей запятой, способным исполнять инструкции параллельно из двух потоков. Операционная система по-прежнему видит один модуль как два ядра/потока. В Bulldozer и Piledriver каждое целочисленное ядро имело свой независимый планировщик задач (Scheduler), но связь с загрузчиком (Fetch) и декодером (Decode), каждый в количестве 1 единицы на модуль, была общей. Инструкции поступали в обработку, и на каждый конвейер целочисленного блока поочерёдно, синхронно с циклами тактового генератора, в декодированном виде подавались команды на выполнение операций. Steamroller удвоил число декодеров – теперь по 2 на модуль (по одному на каждый целочисленный блок). Блок операций с плавающей запятой напрямую работает с двумя декодерами.  Размер кэша инструкций 1-го уровня (L1) возрос с 64 килобайт до 96 килобайт на модуль, что, по заявлению AMD, позволит снизить до 30% количество промахов при обращении в кэш. Обновленный блок предсказания ответвлений позволит сократить число неверно предсказанных ветвлений до 20%. И целочисленный, и векторно-вещественные регистровые файлы также увеличились в размере – как и окно планирования команд, что в совокупности позволило повысить до 25% количество отправок микроопераций (dispatch) на поток (thread). В кэш L1 данные теперь сохраняются для каждого из целочисленных модулей двух декодеров (против одного декодера в Bulldozer/Piledriver), способствуя 20%-му росту эффективности использования кэш-памяти L1. Просто удивительно, сколько всего «вкусного и полезного» в доступном виде хранит базовый дизайн «Бульдозера»! [N3-Графическая часть] К сожалению, архитектура VLIW4 (родом из семейства видеочипов AMD Cayman) в качестве основы встроенной графики в процессорах Trinity/Richland появилась сразу после завершения перехода десктопной части уравнения в направлении VLIW5/VLIW4 => GCN, а ведь наличие линейки продуктов с сильно разнесёнными графическими архитектурами никому особо не нужно, тем более разработчикам. Заглядывая вперёд, отметим, что решение следовать путём GCN было правильным, ведь сейчас GPU в Kaveri использует архитектуру GCN, которая находит применение и в десктопном high-end чипе R9-290X на ядре Hawaii.  Данный шаг позволил AMD с минимальными либо даже с нулевыми усилиями представить весь функционал, предлагаемый сегодня GPU Hawaii – например, технологию TrueAudio, а также улучшенные блоки Video Coding Engine и Unified Video Decoder. Другое дело, решит ли AMD создать APU с более чем 8-ю вычислительными блоками GCN, и в этом случае возникает вопрос о заинтересованности потребителя в APU AMD ещё более высокого класса с гораздо более мощной графикой. Хотя здесь возникают проблемы с пропускной способностью памяти, действительно важным является ответ на вопрос о потребности сообщества в таких APU – подобных тем, что используются в игровых консолях Xbox One и PS4. Llano, Trinity и Kaveri: сравнительный анализ железаСравнение предоставленного AMD чёткого снимка кристалла Kaveri с аналогичными фотографиями кристаллов APU двух предыдущих поколений даёт достаточно полное представление об эволюции APU AMD.
Переход с Llano на Trinity характеризуется «съёживанием» полноценной 4-ядерной системы до 2-модульной компоновки – актуального на сегодняшний день тренда в области APU AMD. Переход с Richland на Kaveri – более серьёзный шаг вперёд, чем можно себе представить. AMD APU: характеристики
Рассматривая ситуацию с APU Llano, Trinity и Richland в ретроспективном аспекте, чётко осознаёшь сложность проблемы, связанной с повышением плотности размещения транзисторов при переходе к техпроцессу GF 32 нм SOI, что хорошо демонстрирует представленная ниже таблица. Следует, однако, иметь в виду, что, кроме Intel, никто нормально не документирует процедуру подсчёта/оценки количества транзисторов, и в этой связи остаётся только надеяться на последовательность AMD в реализации метода подсчёта транзисторов для CPU и GPU (хотя здесь мы, возможно, выдаём желаемое за действительное). Плотность размещения транзисторов
Если AMD и в самом деле одинаково считает транзисторы во всех APU/GPU, тогда переход к Kaveri не выглядит таким уж экстремальным – скорее речь идёт о хорошем прогрессе с точки зрения промежуточного положения между APU предыдущих поколений и других графических решений AMD на базе GCN. При сравнении с чисто процессорными (не графическими) архитектурами AMD становится очевидна гораздо большая степень «утрамбовки» APU вследствие того, что значительная площадь кристалла APU приходится на встроенное видео. Технология TrueAudioВ рамках технологической составляющей APU Kaveri производитель фокусирует внимание на добавлении и обновлении специализированных функциональных блоков и модулей, призванных ускорить выполнение тех или иных задач. Переход к графической архитектуре GCN позволил разработчикам использовать преимущества технологии TrueAudio, реализованной в виде цифрового сигнального процессора (сопроцессора), для улучшения звуковой атмосферы в играх. Также обновлению подверглись блоки Video Codec Engine (VCE) и Unified Video Decoder (UVD). Все крупнейшие производителя графических решений для настольных компьютеров – AMD, NVIDIA, Intel – продвигают новые технологии, способствующие созданию более благоприятных условий пользования своими продуктами, что, очевидно, предполагает многообразие подходов с учётом различных аспектов: игры, вычисления, потребление контента, повышение энергоэффективности, увеличение производительности и т.д. Всё это объясняет распространение таких функций/технологий, как FreeSync, G-Sync, QuickSync, OpenCL и тому подобных. Новой функцией AMD является TrueAudio – полностью программируемый специализированный аппаратный блок с функцией разгрузки процессора в задачах обработки аудио.  Основная проблема, связанная с разработкой новых инструментов, сводится к ответу на вопрос о том, предполагает ли их реализация следование общим принципам или ставка делается на специализированное железо. Это, в свою очередь, сводится к разграничению между встроенными в CPU ресурсами и специализированным железом в виде чипа ASIC (application-specific integrated circuit – интегральная схема специального назначения) в качестве исполнительного элемента для той или иной задачи. Если задача специфична и статична (не подвержена изменению во времени), целесообразно использовать ASIC благодаря малым размерам, связанным с энергопотреблением низким накладным расходам и высокой пропускной способностью. Выбор в пользу CPU предпочтителен для изменяемой во времени задачи, лишённой чётких очертаний, и здесь открываются новые горизонты в плане гибких возможностей в обмен на компромисс с производительностью на Ватт. Мощность современных процессоров обуславливает доступность целого ряда технологий в области аудио с оптимизацией алгоритмов обработки. Единственным ограничением в этом плане является воображение разработчика и широта художественного замысла дизайнера. Реализация фильтра аудиоэффектов в игре на лету посредством CPU может вызвать весьма серьёзную нагрузку, особенно при сохранении эффекта в течение длительного времени. На слайде AMD показан пример добавления одного эффекта реверберации (convolution reverb) к аудиосэмплу, демонстрирующий возрастание нагрузки на CPU с увеличением длительности эффекта.  Данный пример характеризует применение одного фильтра к одному аудиосэмплу. А теперь представьте игровую сцену: пожар, со всех сторон звучат выстрелы, шум воды из пожарных гидрантов, гремят взрывы… Применение эффектов ко всем этим действиям с последующим перемещением источника звука с учётом его фактического местонахождения в игровой сцене влетит в копеечку с точки зрения вычислительных ресурсов – всё ради реализма. Вот здесь на сцену выходит технология TrueAudio, призванная переложить всё на плечи специализированного железа, заточенного под быстрое решение подобного рода задач.  TrueAudio также реализована в видеокартах новейшего поколения R9 260 и R9 290 – по существу, везде, где графическая архитектура представлена как минимум платформой GCN в версии 1.1 и выше. Между тем, известно, что блок обработки аудио в PlayStation 4 также базируется на технологии TrueAudio. Впрочем, изолированный характер эволюции игровых консолей не позволяет сделать однозначный вывод касательно использования одних и тех же API в этих разных платформах. AMD, со своей стороны, сотрудничает с разработчиками звуковых плагинов уровня связующего программного обеспечения (wwise, Bink) с целью содействия развитию экосистемы TrueAudio, так что даже в случае различающихся API разработчики связующего ПО могут абстрагироваться от этих различий, сфокусировав внимание на общих моментах в основе аппаратной платформы. Как это обычно бывает с дополнительным аппаратным функционалом подобного рода, использование TrueAudio в играх потребует написания особого кода, и как таковая реализация преимуществ TrueAudio будет определяться конкретной игрой. В то же время сегодня на рынке не представлены игры, способные использовать преимущества новейшей технологии AMD в области звука, и в этом случае аппаратная часть опередила программную. Вот три первых игровых проекта с поддержкой TrueAudio в списке AMD: Murdered: Soul Suspect, Thief, Lichdom. Во многом аналогично технологии FreeSync, здесь, вероятно, действует правило «лучше 1 раз увидеть, чем 100 раз услышать». UVD и VCE в новой редакцииОтдельного упоминания заслуживают обновлённые функциональные блоки UVD (Unified Video Decoder) и VCE (Video Codec Engine) в чипах Kaveri. Перед нами UVD 4, обновлённый с учётом способности быстро справляться со сбоями в обработке видео формата Н.264, и VCE в версии 2. Из этих решений наибольший интерес представляет улучшенный VCE. Способность ссылаться на два соседних кадра в потоке как результат добавления поддержки B-кадров при кодировании видеопотока в формат H.264 должна помочь повысить качество изображения на выходе VCE-блока и/или снизить нужный битрейт с учётом уровня качества в каждом конкретном случае. Между тем, добавление поддержки более качественного цветового пространства YUV444 в кодировщике H.264 позволит улучшить сжатие преимущественно штриховой графики или текста, что, в свою очередь, имеет немаловажное значение для чёткости картинки, передаваемой на беспроводной дисплей.   Рассматривая тематику архитектуры гетерогенных систем (HSA – Heterogeneous System Architecture), технологии общей памяти (hUMA – Heterogeneous Unified Memory Architecture) и гетерогенной очереди (hQ – Heterogeneous Queuing), штатный эксперт AnandTech Рауль Гарг (Rahul Garg) обсуждает рабочие моменты, связанные с реализацией, смысловым наполнением и применением данных концепций. Графическая архитектура заточена под решение хорошо распараллеленных задач, к числу которых относятся, например, операции с матрицами, которые обычно «дружат» с GPU. Однако не каждая задача такого рода подходит для решения средствами GPU. В современных условиях использование GPU в большинстве задач требует копирования данных между CPU и GPU. Для дискретной видеокарты типична картина, когда данные по шине PCIe копируются из системной памяти в видеопамять, там происходит обсчёт, по завершении которого готовый результат обратно пересылается по шине PCIe. Например, прибавление матрицы является хорошо распараллеливаемой операцией, выполнение которой достаточно подробно описано и задокументировано как для CPU, так и для GPU, однако в зависимости от структуры оставшейся части приложения выполнение этой задачи средствами GPU может оказаться нецелесообразным, если копирование данных по PCIe вредит быстродействию приложения в целом. В приведённом примере передача данных как таковая зачастую обходится дороже, чем выполнение операции сложения для матрицы средствами CPU. Необходимость копирования данных между CPU и GPU также усложняет процесс написания программного обеспечения.  Необходимость скоростной передачи данных в современных условиях обусловлена двумя причинами. Во-первых, обсчёт средствами GPU сегодня обычно предполагает наличие дискретной графики, подключённой к компьютеру по шине PCIe. Дискретные видеоадаптеры имеют собственную память, объём которой обычно варьируется в диапазоне 1-4 Гб, но может достигать и 12 Гб в некоторых современных графических ускорителях для серверов. Видеопамять (например, GDDR5) может обладать высокой пропускной способностью, позволяющей скрыть задержки в промежутке между переключениями контекста потока, поэтому её иногда называют чашей Грааля в вычислениях, требующих активного обращения к памяти. В такой конфигурации, даже с учётом допущения о возможности GPU осуществлять чтение/запись данных при работе с системной памятью по шине PCIe, зачастую более эффективно единоразово пробросить все необходимые данные в видеопамять GPU, где вычислительные ядра будут читать/записывать данные с обращением к родной графической памяти в противовес к обращению к системной памяти по шине PCIe в ущерб быстродействию. Во-вторых, CPU и GPU имеют дело с разными адресными пространствами, которые до появления HSA они «не разумели». Даже встроенная графика, использующая ту же физическую память, лишена механизма, необходимого для работы с общим адресным пространством. Технология HSA призвана решить эту проблему. Арсенал средств, позволяющих избежать накладных расходов при передаче данных, довольно обширен. Например, можно попытаться передать данные в параллельном режиме, попутно возложив часть вычислений на плечи CPU и обеспечив частичное совпадение во времени вычислительных процессов и процессов передачи данных. В ряде случаев можно обойтись без CPU – например, пробросив данные в виде файлов с SSD, оснащённого интерфейсом PCIe, напрямую в GPU посредством технологии GPUDirect. Однако такие методы не всегда применимы и требуют от программиста значительных усилий. В конечном счёте, наличие по-настоящему общей памяти для CPU и GPU позволит решить множество проблем, хотя дискретная графика с быстрой видеопамятью отлично подходит для множества других задач, несмотря на проблему накладных расходов при копировании данных. Общая память: как это было до HSAТермины «совместно используемая память» (shared memory), или «общая память» (unified memory), довольно свободно используются в отрасли и могут иметь разные значения в зависимости от контекста. Рассмотрим текущую ситуацию с учётом специфики поставщиков платформ. NVIDIA впервые упоминает термин «общая память» (unified memory) в связи с технологией CUDA. Однако для видеочипов NVIDIA текущего поколения реализация данной концепции, предполагающая задействование программной части в качестве основы, является скорее решением для облегчения труда программистов, скрывающимся за спиной API для простоты использования. Перенос данных всё так же идёт в ущерб производительности, и инструментарий NVIDIA просто скрывает некоторые сложности, связанные с работой ПО. Концепцию по-настоящему общей памяти NVIDIA, как ожидается, предложит в продуктах с архитектурой Maxwell, которая, вероятно, увидит свет в преемнике чипа Tegra K1 в 2015-2016 гг. AMD хвалится «нулевым копированием» в чипах Llano и Trinity в OpenCL-программах, хотя в основном это лишь обеспечивает возможность в ограниченном числе случаев быстро скопировать данные с CPU в GPU и способность вновь считать данные с GPU. На практике функция нулевого копирования имеет ограниченное применение вследствие ряда факторов, включая «дороговизну» этапа инициализации. В большинстве случаев в условиях реальной эксплуатации придётся копировать данные между CPU и GPU. Сегодня Intel предлагает некоторую поддержку разделяемой памяти в графике 7-го поколения в составе процессоров Ivy Bridge и Haswell, выраженную посредством OpenCL и DirectX. В плане перспективы совместного доступа к памяти предложенный Intel механизм интеграции CPU с GPU впечатляет больше, чем таковой в APU Llano/Trinity, но его задействование по-прежнему ограничено несколькими простыми случаями из-за невозможности совместного доступа к памяти с использованием указателей адресов, вызова страниц по запросу и обеспечения по-настоящему совместного использования памяти CPU и GPU, предлагаемых в рамках концепции HSA, что позволяет говорить о значительном превосходстве AMD в этом вопросе. Другие компании, такие как ARM, Imagination Technologies, Samsung и Qualcomm, также входят в состав консорциума HSA Foundation и, вероятно, работают над созданием аналогичных решений. Графические ядра Mali T600 и T700 демонстрируют некоторую способность совместного использования GPU- и CPU-компонентами графической буферной памяти посредством OpenCL 1.1. Однако есть мнение, что в ближайшем будущем лишь AMD сможет обеспечить полный спектр возможностей HSA. По состоянию на сегодняшний день, реализованная в чипах Kaveri модель HSA – самый прогрессивный пример тесного взаимодействия CPU и GPU, являющийся наиболее полным решением такого рода. HSA и hUMAА теперь о том, как функционал общей памяти реализован в рамках HSA. Основные преимущества от единой памяти в рамках HSA сводятся к адресуемому пространству памяти. Снижение платы за возможность доступа CPU и GPU к одним и тем же данным позволяет добиться повышения эффективности решения вычислительных задач или разгрузки вычислительных ресурсов, не беспокоясь о цене такой операции.  Отказ от копирования данных от CPU к GPU и обратно: теперь GPU может осуществлять доступ ко всему адресному пространству CPU без необходимости копирования. Примером является упомянутое выше сложение матриц. Система с поддержкой HSA позволяет избежать копирования входных данных в GPU и копирование результата назад в CPU. Доступ к адресному пространству в полном объёме: помимо выигрыша в производительности в результате отказа от копирования данных, GPU также лишается ограничений по объёму встроенной видеопамяти, что обычно имеет место в случае с дискретными видеокартами. Даже топовые ускорители графики сегодня имеют максимум 12 Гб видеопамяти, в то время как CPU выгодно отличается способностью осуществлять доступ к потенциально гораздо большему пространству памяти. Во многих случаях, таких как научное моделирование, это означает способность GPU оперировать намного большими наборами данных без особых усилий со стороны программиста, который в противном случае должен ухитриться втиснуть данные в ограниченное адресное пространство GPU. APU Kaveri позволяют задействовать до 32 Гб памяти DDR3, и в этом случае ограничивающим фактором становится уже потребность рынка в нерегистровых модулях памяти объёмом 16 Гб без ECC. Наличие задержек при работе APU с памятью DRAM означает возможность улучшения ситуации в будущем за счёт использования объёмного кэша L3 либо памяти eDRAM, особенно в сценариях, когда даёт о себе знать не бесконечная пропускная способность памяти либо при загрузке данных с необходимостью предварительного освобождения памяти. Адресация общей памяти на аппаратном уровне – значимое нововведение для Kaveri и HSA, которое на данный момент не предлагает ни одна другая система. Приложения выделяют под свои нужды часть памяти в пространстве виртуальной памяти CPU, при этом операционная система ведёт таблицу трансляции (пересчёта) виртуальных адресов в физические. При получении команды на загрузку CPU преобразует виртуальный адрес в физический, и здесь ему на помощь может прийти операционная система. GPU также имеет собственное виртуальное адресное пространство, и раньше GPU ничего не смыслил в адресном пространстве CPU. В системах с общей памятью предыдущего поколения, таких как Ivy Bridge, приложению приходилось просить видеодрайвер составить таблицу соответствия страницам памяти GPU по конкретному диапазону виртуальных адресов CPU. Это работало в случае с простыми структурами, такими как массивы, но не работало для более сложных структур. Инициализация таблицы соответствия страницам GPU сопровождалась дополнительными непроизводственными затратами в ущерб производительности.  HSA позволяет GPU напрямую осуществлять загрузку/сохранение при работе с виртуальным адресным пространством CPU. Таким образом, приложение может напрямую передать центральному процессору указатели, способствуя использованию преимуществ GPU значительно более обширным классом приложений. Например, совместный доступ к связному списку и другим структурам данным, использующим указатели, теперь возможен без ухищрений со стороны приложения. Отсутствие накладных расходов в работе драйвера при совместном доступе к указателям способствует повышению эффективности.  Такое решение позволяет CPU и GPU осуществлять одновременный доступ к одному и тому же набору данных и его совместную обработку, способствуя реализации программистами рабочих сценариев с высокой загрузкой мощностей и достижению уровня, близкого к рассчитанным AMD 800 GFLOPS и выше для одного Kaveri. При наличии до 12 вычислительных ядер, несмотря на различия в способе использования вычислительных ядер в CPU и GPU и на различия в исполняемых программных ядрах (kernel), все они, по крайней мере, могут осуществлять доступ к одним и тем же данным с нулевыми накладными расходами. Обеспечение совместного использования данных путём устранения барьеров и преодоления препятствий при работе с потоками всё же остаётся в ведении программиста. Вызов страниц по запросу. В приведённом выше описании за кадром осталась одна деталь. Пересчёт виртуальных адресов в физические - задача не простая, и страница, содержащая требуемые данные с учётом необходимости их нахождения в физической, т.е. оперативной, памяти, может фактически отсутствовать в оперативной памяти, предполагая, таким образом, необходимость загрузки этой страницы, скажем, с диска, что требует вмешательства операционной системы. Это называется вызов страниц по запросу (demand-driven paging). До выхода Kaveri графическое ядро было лишено возможности подкачки страниц из виртуальной памяти по запросу. Напротив, приложению приходилось заранее знать диапазон адресов, к которым осуществляется доступ, и привязывать его к объекту данных, находящемуся в видеопамяти; затем видеодрайвер блокировал соответствующие страницы в оперативной памяти. Однако зачастую бывает так, что программист, пишущий приложение, не знает заранее схему доступа к данным. Использующие указатели структуры данных, такие как связанные списки, где узловые структуры могут содержать указание на любое место в памяти, представляли сложность для программиста. Вызов страниц по запросу вместе с общей адресацией позволяет осуществлять совместный доступ CPU и GPU к произвольным структурам данным, значительно расширяя список приложений, получающих возможность ускоренного выполнения средствами GPU. Тесное взаимодействие CPU и GPU. Ранее обсуждалась возможность выполнения GPU-частью операций чтения/записи с обращением к адресному пространству CPU без необходимости копировать данные. Однако это ещё не вся история, т.к. порой CPU и GPU хотят объединить усилия для выполнения той или иной задачи. В ряде случаев решающее значение имеет взаимная способность CPU и GPU видеть записываемые результаты вычислений – непростая задача в силу ряда проблем, включая работу кэш-памяти. Модель памяти HSA обеспечивает дополнительную связность в работе CPU и GPU посредством инструкций, использующих временное блокирование доступа к определённой части памяти со стороны других исполнительных устройств. Однако, поскольку такая связность не проходит даром для производительности, HSA предоставляет в распоряжение программиста механизмы, позволяющие чётко обозначить отсутствие необходимости совместной работы CPU и GPU. Помимо инструкций, предполагающих обращение к связной памяти, HSA допускает возможность использования атомарных инструкций, позволяющих CPU и GPU осуществлять атомарные запись/чтение по конкретному месту в памяти. Эти атомарные действия в рамках данной платформы рассчитаны на функционирование как обычные атомарные действия, что предполагает выполнение операции по схеме «чтение-изменение-запись» в рамках одной инструкции без создания специфичных препятствий/блокирований в отношении элемента данных или набора данных. HSAILСтремление HSA Foundation обеспечить работу одних и тех же приложений на базе гетерогенных вычислений в среде всех систем с поддержкой HSA вызвало необходимость стандартизации программного интерфейса, поддерживаемого любой HSA-системой. HSA Foundation хотела создать низкоуровневый API для железа, которое может служить целевой платформой для компиляторов в разных языках программирования. Обычно компиляторы ориентируются на поддерживаемый тем или иным процессором набор команд, однако в условиях нацеленности концепции HSA на разнофункциональное аппаратное обеспечение (центральный процессор, графический процессор, специализированный сопроцессор) истинная стандартизация наборов команд не представляется возможной. В противоположность этому HSA Foundation подвергла стандартизации псевдонабор команд, получивший название HSAIL (HSA Intermediate Language). |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Источник: www.anandtech.com/
