Amd app acceleration что это
Что может сделать AMD APP Acceleration для вас
После внедрения технологии NVIDIA® CUDA ™ компания Tipard Studio использовала новейшее AMD APP Acceleration, которое может помочь конверсионным приложениям Tipard продемонстрировать превосходную производительность преобразования.
Что такое AMD APP Acceleration?
AMD App Acceleration является сокращением для AMD Accelerated Parallel Processing, направленной на улучшение качества видео и повышение производительности приложений. Это набор технологий, доступных на AMD Radeon ™ HD 6000 и более высоких графических процессорах, и предназначен для улучшения качества видео и повышения производительности приложений. Полное включение некоторых функций требует поддержки технологии AMD Accelerated Parallel Processing (APP) и / или универсального видеодекодера AMD (UVD). Технология AMD Accelerated Parallel Processing работает с приложениями, предназначенными для использования возможностей ускорения GPU.
Внедрение AMD APP Acceleration
Поскольку технология NVIDIA® CUDA ™ сэкономила много времени для тех пользователей ПК, на которых установлен графический процессор с поддержкой CUDA, разработчики программного обеспечения Tipard уже начали беспокоиться о других пользователях ПК с GPU с поддержкой AMD APP. Затем, чтобы дать пользователям AMD сверхвысокую скорость конвертирования и превосходную производительность обработки видео, после постоянных исследований и разработок AMD APP Acceleration была принята к продукту Tipard ( Видео конвертер Ultimate, DVD RipperИ т.д.).
Как AMD APP Acceleration влияет на процессор?
Когда AMD APP Acceleration включена, больше мест и ресурсов вашего компьютера CPU можно зарезервировать для других задач при разрыве BD / DVD или конвертации видеофайлов. Пользователи могут по желанию включить / отключить ускорение GPU после обнаружения графической карты AMD. Здесь Tipard предлагает включить AMD APP Acceleration при конвертировании видеофайлов HD, чтобы вы могли конвертировать DVD в HD-видео с минутами.
Демонстрация превосходной производительности конвертации с AMD APP Acceleration
Очевидно, что правильная графика ясно показала, что волшебное AMD APP Acceleration может значительно экономить пользователей при конвертировании практически любого видеофайла в другой видеоформат с кодеком H.264 на вашем ПК, работающем на GPU с поддержкой AMD APP. На этом этапе вы можете быстро импортировать видео AVCHD, а затем конвертировать MTS / M2TS в iMovie, или Adobe Premiere совместимые видеоформаты, как вам нравится.
Загрузите и установите драйвер графики AMD
Чтобы использовать AMD APP Acceleration, вы должны сначала установить Драйвер Graphics Graphics. Следуйте приведенному ниже руководству, чтобы завершить установку: https://www.tipard.com/install-amd-driver.html.
Примечание: 1. Приведенный выше рисунок является лишь одним примером. Фактическая ситуация с ускорением зависит от другого исходного файла, формата вывода и обстоятельств ПК (ОС, процессор, графическая карта и т. Д.).
2. AMD APP Acceleration может работать только в том случае, если конвертер выводит формат с кодеком H.264. Во-вторых, это будет более очевидно при конвертировании файлов HD-видео.
Поддерживаемая графическая карта:
Примечание. Все режимы видеокарты, упомянутые выше, являются только ссылкой. Вся информация AMD распространяется на официальный сайт AMD
Хотите иметь легкий доступ для конвертирования MP4 видео в MP3 аудио? Следующая статья предлагает конвертеры 20.
Здесь мы включаем лучшие решения для кодирования фильмов и записи фильмов на DVD. Навсегда любите свои любимые фильмы на большом экране.
Ищете обучение DVD Shrink и его лучшую альтернативу? Вы можете найти обзор DVD Shrink и лучшие альтернативы здесь.
Преобразование видео на DVD с высоким качеством и сверхбыстрой скоростью, а также поможет вам конвертировать видео в DVD.
Copyright © 2021 Типард Студия. Все права защищены.
AMD APP SDK: Compute Abstraction Layer (CAL)
В первой части я рассказал о технологии AMD Intermediate Language (IL). В этой статье, как можно догадаться из заголовка, речь пойдет о второй составляющей: AMD Compute Abstraction Layer (CAL). Эти две технологии являются нераздельными друг от друга: невозможно использовать одну, не используя другую. Поэтому для понимания дальнейшего рекомендую ознакомиться с первой частью.
Я постараюсь осветить основные аспекты работы на верхнем уровне с AMD GPU, опишу ограничения данной технологии и возможные проблемы при работе с ней. Кому интересно, прошу под кат.
Вместо введения
Большинство вызываемых функций возвращает значение типа CALresult. Всего доступно 11 кодов возврата. Самый важный для нас — код CAL_RESULT_OK, равный 0 (свидетельствует об успешном завершении вызова).
Инициализация драйвера
Правило №1: перед началом работы с GPU вымыйте руки инициализируйте работу драйвера следующим вызовом:
Правило №2: после работы с GPU не забываем смыть за собой завершить работу корректно. Это делается следующим вызовом:
Эти два вызова всегда должны идти в паре. Их (таких пар вызовов) может быть несколько в программе, но никогда не работайте с GPU вне этих вызовов: такое поведение может повлечь за собой hardware exception.
Получение информации о GPU
Узнаем количество поддерживаемых GPU (их может быть меньше, чем общее число AMD GPU в системе):
В данной статье я буду указывать, где используется идентификатор GPU, но «работать» я буду с GPU под идентификатором 0. В общем случае этот идентификатор принимает значения от 0 до (deviceCount-1).
Узнаем информацию о GPU:
Самое важное в структуре CALdeviceinfo — идентификатор чипа GPU. Он именуется здесь Device Kernel ISA :
Остальные поля структуры определяют максимальный размер текстурной памяти по двум координатам, которую можно выделить на данном GPU.
Намного более интересна структура CALdeviceattribs, отвечающая за атрибуты GPU (я приведу только несколько полей структуры):
Правило №3: поле CALdeviceattribs.pitch_alignment измеряется в элементах памяти, а не в байтах. Элементом памяти является 1-, 2- или 4-х компонентный вектор 8-, 16- или 32-битных регистров.
А теперь давайте внимательно посмотрим, какие же значания может принимать поле CALdeviceinfo.target (оно же CALdeviceattribs.target):
Еще одно замечание: в этом списке нет Evergreen GPU, о котором я упоминал в первой части. Мое предположение — GPU семейства Evergreen начинаются с чипа Cypress (CAL_TARGET_CYPRESS). Все, что до этого, — предыдущее поколение без поддержки новых плюшек (циклический сдвиг, поддержка флагов операций и 64-битные операции).
Для дальнейшей работы нам надо создать дескриптор устройства (device), с помощью которого мы будем взаимодействовать с GPU:
Контекст необходим для работы в пределах вашего приложения с данным GPU. Вся работа с GPU производится при помощи этого контекста. Как только вы удаляете контекст, все выделенные ресурсы считаются освобожденными, а все незавершенные задачи на GPU в принудительном порядке завершаются.
Не забываем про парные вызовы после окончания работы с устройством:
Вызовы должны идти именно в этом порядке, иначе получим hardware exception.
Итак, мы создали устройство и контекст для него, теперь можно приступить к
Выделение памяти
Для работы с памятью надо выделить ресурс. Согласно документации, ресурс может располагаться в локальной памяти (local memory = stream processor memory) и удаленной памяти (remote memory = system memory). Насколько я понял, remote memory является ничем иным, как оперативной памятью, тогда как local memory — память самой GPU.
Зачем нужна remote memory, если есть local memory? Во-первых, она нужна для разделения одной и той же памяти между несколькими GPU. То есть, remote memory можно выделить один раз и работать с ней из нескольких GPU. Во-вторых, не все GPU поддерживают прямое обращение к своей памяти (см. ниже «Получение прямого доступа к памяти»).
Ширина и высота выделяемого ресурса измеряется в элементах памяти.
Сам же элемент памяти описывается параметром memoryFormat:
Жаль, что 64-битные операции на старых видеокартах (не Evergreen) можно выполнять только с данными типа float…
Правило №4: формат элемента описывает лишь способ, которым GPU будет трактовать данные, лежащие в этом элементе. Физически элемент всегда занимает 16 байт памяти.
Это можно понять, если вспомнить, что в первой части мы описали ресурс следующим образом:
Правило №5: соблюдайте типы, которые вы объявляет в ядре и при выделении ресурса. При их несовпадении вы не сможете привязать ресурс к ядру.
Правило №6: для константной памяти тип элемента всегда должен быть типа float.
Почему так сделано, мне не ясно, так как все равно можно загружать из константной памяти целочисленные значения (что мы и делаем в примере).
Еще пара слов о флагах, которые необходимы при выделении памяти:
Со вторым флагом я никогда не работал, когда он дает преимущество, я не знаю. Да и судя по знаку вопроса в комментарии самих авторов, они тоже не в курсе (smile).
А вот первый флаг нужен для выделения глобального буфера(«g[]»).
Теперь применим теорию на практике. Помня о примере, описанном в предыдущей статье, зададимся еще и параметрами запуска ядра:
После того, как ресурсы уже не понадобятся, их надо будет освободить:
Копирование памяти
Получение прямого доступа к памяти
Если GPU поддерживает mapping своей памяти (отображение адресов своей памяти в адресное пространство процесса), то мы можем получить указатель на эту память, а дальше работать с ней, как и с любой другой памятью:
А после того, как мы закончим работу с памятью, необходимо освободить указатель:
Правило №7: всегда помните, что при работе с памятью GPU нужно учитывать выравнивание. Это выравнивание характеризуется переменной pitch.
Правило №8: pitch измеряется в элементах, а не в байтах.
Зачем нужно знать про это выравнивание? Дело в том, что в отличие от оперативной памяти, память GPU не всегда является непрерывной областью. Особенно это проявляется при работе с текстурами. Поясню сказанное на примере: если вы хотите работать с текстурой 100х100 элементов, а функция calResMap() вернула значение pitch равное 200, то это значит, что на самом деле GPU будет работать с текстурой 200х100, просто в каждой строке текстуры будут учитываться только первые 100 элементов.
Копирование в память GPU с учетом значения pitch можно организовать следующим образом:
Естественно, данные в dataBuffer должны быть подготовлены с учетом типа элемента. Но при этом помните, что элемент всегда имеет размер 16 байт.
То есть для элемента формата CAL_FORMAT_UNSIGNED_INT16_2 его побайтовое представление в памяти будет следующим:
Копирование данных между ресурсами
Копирование данных производится не напрямую между ресурсами, а между их отображенными на контекст значениями. Операция копирования является асинхронной, поэтому, чтобы узнать о завершении операции копирования, используется системный объект типа CALevent:
Компиляция и загрузка ядра на GPU
«Смерть Кощея в игле, игла в яйце, яйцо в утке, утка в зайце, заяц в сундуке. »
Процесс загрузки ядра на GPU можно описать следующим образом: исходник (txt) компилируется в объектник (object), затем один или несколько объектников линкуются в образ (image), который после этого загружается в модуль GPU (module), а уже из модуля можно получить указатель на точку входа ядра (по этому указателю мы сможем запустить ядро на исполнение).
А теперь, как это реализуется:
Правило №9: точка входа в ядро всегда одна, так как там только одна функция после линковки — функция «main».
Загрузка образа в модуль объясняется тем, что образ нужно подгрузить в выделенный контекст GPU. Следовательно, описанный процесс компиляции нужно делать для каждой GPU (за исключением случая, когда 2 одинаковые GPU: достаточно один раз скомпилировать и слинковать, но все равно придется загрузить образ в модуль для каждой карточки).
Хочу обратить внимание на возможность линковки нескольких объектников. Может, кому-нибудь эта возможность пригодится. На мой взгляд ее можно применить в случае различной реализации одной и той же подфункции: эти реализации можно вынести в различные объектники, так как в AMD IL нет директив препроцессора наподобие #ifdef.
После того, как завершится выполнение ядра на GPU, надо будет освободить соответствующие ресурсы:
Запуск ядра на исполнение
Установка параметров запуска ядра
Итак, у нас есть выделенные ресурсы, заполненная память и скомпилированное ядро. Остается только привязать ресурсы к нашему конкретному ядру и запустить его. Для этого нужно получить из ядра его параметры запуска, а ресурс отобразить на контекст.
И теперь делаем это в рамках нашего примера:
После того, как завершится выполнение ядра на GPU, надо будет отвязать ресурсы от ядра. Это можно сделать так:
Теперь ядро знает, откуда брать данные. Остается дело за малым:
Запуск ядра
Здесь function — та точка входа в ядро, что мы получили на этапе загрузки ядра на GPU (см. выше «Компиляция и загрузка ядра на GPU»).
Правило №11: величина threads должна соответствовать величине, пробитой в исходном коде ядра. Ядро будет запущено в любом случае, однако можно либо выйти за пределы памяти (запуск меньшего количества потоков, чем было объявлено в ядре), либо не все входные данные будут обработаны (запуск большего количества потоков, чем было объявлено в ядре).
Done! Ядро запущено, и если все прошло успешно, то в выходной памяти («g[]») лежат обработанные данные. Осталось их только скопировать наружу (см. выше раздел «Копирование памяти»).
Полезные функции
Осталось только упомянуть некоторые функции, которые могут пригодиться в быту.
Межпоточая синхронизация
В отличие от Nvidia CUDA, вам не надо производить дополнительные действия с контекстом, если вы работаете с GPU из разных потоков. Но все же есть некоторые ограничения.
Правило №14: только один поток приложения в один момент времени может работать с конкретным контекстом.
AMD APP SDK: Intermediate Language (IL)
ATI Stream SDK было переименовано в AMD Accelerated Parallel Processing (APP) SDK, на смену основного языка программирования GPGPU вычислений Brook+ пришел OpenCL. Однако, не многие догадываются, что писать код для ATI-шных карточек можно при помощи другой технологии: AMD Compute Abstraction Layer (CAL) / Intermediate Language (IL). Технология CAL предназначена для написания кода, взаимодействующего с GPU и выполняющегося на CPU, в то время как технология IL позволяет писать код, который будет выполняться непосредственно на GPU.
Введение
2x при использовании связки CAL/IL
* означает, что язык хоть и похож на ассемблер, он все же оптимизируется компилятором и преобразовывается в разный код для разных GPU
За счет чего же можно получить такой выигрыш в производительности?
Особенности архитектуры AMD GPU
Отличие от OpenCL
Особенности работы с памятью
Как я уже упоминал, AMD GPU работает с 4-х компонентыми векторами n-битных регистров, где n=32 (о том, как работать с 64-битными регистрами, далее). Это накладывает основное ограничение на память: выделять память можно только объемом, кратным 16 байтам. При этом нужно помнить, что при загрузке дынных из памяти минимальным объемом передачи являются опять же эти 16 байт. То есть совершенно неважно, укажите вы, что ваша память состоит из 4-х компонентых векторов по 1 байту (char4), что из 4-х компонентых векторов по 4 байта (int4), результат будет один — из памяти за одну операцию обмена загрузятся 16 байт.
Далее, в отличие от Nvidia GPU, AMD GPU выделяет локальную память в глобальной области (а это означает очень медленную скорость обмена данных), так что забудьте про локальную память. Используйте регистры и глобальную память.
И на последок: опять же в отличие от Nvidia GPU, есть только одна глобальная память, работающая на чтение-запись (далее это будет «g[]»), и много различных источников текстурной памяти (далее это будет «i0», «i1» и т.д.) и константной памяти (далее это будет «cb0», «cb1» и т.д.), работающих только на чтение.
Особенностью константной памяти является наличие кеширования при доступе всеми GPU-потоками к одной области данных (работает также быстро, как и регистры).
Особенностью текстурной памяти является кеширование чтения (от 8 КБ, если мне не изменяет память, в расчете на один потоковый процессор) и возможность обращения к памяти по вещественным координатам. При выходе за границы текстуры можно либо считывать граничный элемент, либо закольцовываться и считывать сначала (координата берется по модулю ширины/длины текстуры).
А теперь приступим к самому интересному:
Структура кода для AMD IL
Работа с регистрами
Сперва небольшое пояснение, как происходит обмен между регистрами в операциях.
Выходной регистр на месте компоненты вектора может содержать либо имя компоненты, либо знак «_», что означает, что данная компонента не будет изменена.
Каждый входной регистр на месте каждой компоненты может содержать любое имя из четырех компонент, либо «0», либо «1». Это означает, что в операции над соответствующей компонентой выходного регистра участвует либо компонента входного регистра, либо константа. Поясню сказанное на примере:
Шейдеры
Код для AMD GPU оформляется в виде шейдеров. Есть возможность запускать как компьютерный шейдер (Compute Shader, CS), так и пиксельный шейдер (Pixel Shader, PS). Однако CS поддерживается, начиная только с Radeon HD 4000 Series. При этом скорость их работы почти одинаковая.
Известно, что количество одновременно запускаемых потоков на GPU определяется параметрами запуска: количество блоков, количество потоков на блок. Каждый мультипроцессор (от 8 штук) GPU берет на исполнение один блок. Затем делит запрошенное количество потоков на блок на куски (warp, кратно 32) и отдает каждому своему поточному процессору на исполнение один warp. Таким образом, реальное количество одновременно работающих потоков равно:
Именно поэтому для наиболее быстрой работы требуется, чтобы в рамках одного warp’a потоки выполняли одну и ту же операцию, без ветвлений. Тогда эта операция выполнится за один раз.
Для того чтобы не рассматривать сферического коня в вакууме, рассмотрим простую задачу: каждый поток вычисляет свой локальный идентификатор в пределах блока (32 бита), глобальный идентификатор (32 бита), считывает константы (64 бита) из памяти команд и из памяти данных, считывает элемент из текстуры (128 бит). Все это он записывает в выходную память, каждому потоку для этого потребуется 256 бит.
Примечание: каждая строка текстуры содержит данные для потоков одного блока.
Pixel Shader
Compute Shader
Все отличие будет заключаться только в вычислении идентификаторов потока, остальное все то же самое.
Различия шейдеров
Кроме поддержки на разных карточках, основное отличие шейдеров заключается в месте хранения количества запускаемых потоков на блок. Для PS это значение можно хранить в памяти, для CS это значение нужно пробивать в коде. Кроме того, для CS проще вычислять идентификаторы потока.
Новейшая технология обработки графики от AMD для настольных ПК и ноутбуков обогащает игровые возможности и повышает производительность приложений
Процессоры AMD Radeon HD 8000M Mobile и HD 8000 Desktop Graphics для OEM-производителей оснащены архитектурой GCN, полной поддержкой DirectX 11.1 и обладают хорошей производительностью на ватт потребляемой мощности –
ЛАС-ВЕГАС, CES-2013 — 10 января 2013 г. — Компания AMD выпустила мобильные графические процессоры (GPU) AMD Radeon™ HD 8000M, обеспечивающие производительность уровня дискретных видеокарт при обработке графики на ноутбуках самых различных форм-факторов, включая портативные тонкие модели. AMD Radeon HD 8000M ― это первые GPU для ноутбуков, оснащенные архитектурой AMD Graphics Core Next (GCN) и технологией AMD Enduro™ 1,2, которые обеспечивают исключительную вычислительную мощность и производительность при длительном сроке службы аккумулятора. В настоящее время они уже устанавливаются в ноутбуках ASUS и Samsung, в ближайшее время появятся в ноутбуках от Lenovo и в системах от других производителей.
Графические процессоры AMD Radeon HD 8800M, HD 8700M, HD 8600M и HD 8500M идеально подходят пользователям, которые хотят модернизировать свой ноутбук и ищут наилучшее графическое решение для этого. AMD Radeon HD 8000M оснащены энергосберегающей технологией AMD Enduro, позволяющей регулировать степень нагрузки и потребляемую мощность процессора в зависимости от необходимости в обработке графики. Усовершенствованный интерфейс с полным управлением профилями интеллектуально определит источник питания и GPU без ущерба для работы приложений. Параметры, установленные по умолчанию в новом интерфейсе, идеально подойдут большинству пользователей, а специальный режим управления включает в себя дополнительные настройки для опытных компьютерных энтузиастов.
Особенности графических процессоров AMD Radeon HD серии 8000M
· Повышенная производительность: технология AMD App Acceleration повышает возможности процессора при работе с Windows 8, увеличивая производительность обработки графики и ускоряя работу приложений; в то время как передовые вычислительные возможности GPU позволяют успешно работать сразу с несколькими приложениями, наслаждаться воспроизведением высококачественного видео и молниеносным геймплеем.4
· Стабильность и надежность: технология AMD Catalyst™ дает возможность пользователям полностью управлять работой процессора и обеспечивает стабильность в работе, позволяя ощутить все преимущества каждой новой версии драйвера.
· Захватывающие 3D-эффекты: технология AMD HD3D обеспечивает многие ПК приложения поддержкой 3D-изображения, позволяя просматривать, создавать, передавать и загружать полноценные стереоскопические 3D-кинофильмы5.
Графические процессоры AMD Radeon HD 8000 для OEM-производителей настольных ПК
Видеокарты AMD Radeon HD 8000 превращают повседневные задачи в интересный и продуктивный процесс. Оснащенные архитектурой GC N, они оснащены технологией AMD App Acceleration для легкой работы с Windows 8 и повышения производительности при работе с офисными приложениями и веб-браузерами4. Благодаря поддержке DirectX 11.1, а также PCI Express 3.01, пользователям станут доступны превосходное качество изображения и хорошая производительность. Графика AMD Radeon HD 8000 использует технологию AMD ZeroCore Power, что дает возможность рационально использовать энергию, когда компьютер работает в режиме ожидания3. Графические процессоры AMD Radeon HD серии 8000 будут применяться в настольных системах основных OEM-производителей, начиная с конца января 2013 года.
Информационные ресурсы
· Информация о видеокартах AMD Radeon™ HD 8000M
· Следите за новостями графики AMD в Твиттере: @AMDRadeon
1. Архитектура GCN и ее компоненты (PCI Express ® 3.0, поддержка DirectX ® 11.1, AMD Enduro™, технология AMD ZeroCore Power и т.д.) применяются в избранных графических процессорах AMD Radeon™ HD серий 7000/HD 7000M и HD 8000/HD 8000M (но не в процессорах AMD Radeon™ серий HD 8350 и HD 8400). Все технологии поддерживаются не во всех конфигурациях систем — за сведениями о возможностях конкретной модели обращайтесь к производителю системы.
3. AMD PowerTune и AMD PowerTune with boost, AMD ZeroCore и другие технологии управления питанием AMD ― это семейство технологий, предлагаемых с определенными графическими продуктами AMD Radeon™ (они не поддерживаются графическими процессорами для настольных ПК AMD Radeon ™ серий HD 8350 и HD 8400), которые предназначены для интеллектуального управления энергопотреблением при определенных условиях нагрузки GPU. Не все продукты поддерживают все эти технологии ― о конкретных возможностях справляйтесь у производителя компонентов или системы.
4. AMD App Acceleration – это набор технологий, призванных улучшить качество изображения и повысить производительность приложений. Для полноценной работы некоторых функций требуется поддержка OpenCL™ или DirectCompute (включая AMD Universal Video Decoder (UVD)). Не все продукты обеспечивают всю функциональность, и для поддержки некоторых возможностей могут потребоваться дополнительные компоненты.