AMD app sdk runtime что это

Содержание

Высокая производительность / AMD APP SDK: Compute Abstraction Layer (CAL)

AMD app sdk runtime что это

В первой части я рассказал о технологии AMD Intermediate Language (IL).

В этой статье, как можно догадаться из заголовка, речь пойдет о второй составляющей: AMD Compute Abstraction Layer (CAL).

Эти две технологии являются нераздельными друг от друга: невозможно использовать одну, не используя другую. Поэтому для понимания дальнейшего рекомендую ознакомиться с первой частью.

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

Вместо введения

Когда я только начинал разбираться с программированием под AMD GPU, меня спросили, что я для этого использую. «ATI CAL» — ответил я. «Да, ATI действительно CAL» — было мне в ответ.
В общем, как произносится аббревиатура CAL, я не знаю, но произношу через «О», чтоб не смущать людей.

Для краткости обозначим программу, описанную в первой части ядром (kernel).

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

Я не буду приводить полный текст какой-либо программы, работающей с GPU через AMD CAL, а просто расскажу про основные моменты работы:

  • инициализация драйвера
  • получение информации о всех поддерживаемых GPU
  • выделение и копирование памяти
  • компиляция и загрузка ядра на GPU
  • запуск ядра на исполнение
  • синхронизация работы с CPU

Для начала работы нам понадобятся два заголовочных файла из AMD APP SDK:

  • cal.h — описывает основные функции драйвера, функции имеют префикс «cal» (библиотека aticalrt.dll)
  • calcl.h — описывает основные функции компилятора текстового ядра в бинарный код, функции имеют префикс «calcl» (библиотека aticalcl.dll)

Как вы видите, в отличие от Nvidia CUDA, у которой есть Run-time API и Driver API, для AMD доступно только Driver API. Поэтому для работы вашего приложения не забудьте слинковаться с соответствующими библиотеками.

Большинство вызываемых функций возвращает значение типа CALresult. Всего доступно 11 кодов возврата. Самый важный для нас — код CAL_RESULT_OK, равный 0 (свидетельствует об успешном завершении вызова).

Итак, поехали.

Инициализация драйвера

Правило №1: перед началом работы с GPU вымыйте руки инициализируйте работу драйвера следующим вызовом:

CALresult result = calInit();

Правило №2: после работы с GPU не забываем смыть за собой завершить работу корректно. Это делается следующим вызовом:

CALresult result = calShutdown();

Эти два вызова всегда должны идти в паре. Их (таких пар вызовов) может быть несколько в программе, но никогда не работайте с GPU вне этих вызовов: такое поведение может повлечь за собой hardware exception.

Получение информации о GPU

Узнаем количество поддерживаемых GPU (их может быть меньше, чем общее число AMD GPU в системе):

unsigned int deviceCount = 0; CALresult result = calDeviceGetCount( &deviceCount );

В данной статье я буду указывать, где используется идентификатор GPU, но «работать» я буду с GPU под идентификатором 0. В общем случае этот идентификатор принимает значения от 0 до (deviceCount-1).

Узнаем информацию о GPU:

unsigned int deviceId = 0; // идентификатор GPU CALdeviceinfo deviceInfo; CALresult result = calDeviceGetInfo( &deviceInfo, deviceId ); CALdeviceattribs deviceAttribs; deviceAttribs.struct_size = sizeof( deviceAttribs ); CALresult result = calDeviceGetAttribs( &deviceAttribs, deviceId );

Самое важное в структуре CALdeviceinfo — идентификатор чипа GPU. Он именуется здесь Device Kernel ISA:

typedef struct CALdeviceinfoRec { CALtarget target; /**< Device Kernel ISA */ CALuint maxResource1DWidth; /**< Maximum resource 1D width */ CALuint maxResource2DWidth; /**< Maximum resource 2D width */ CALuint maxResource2DHeight; /**< Maximum resource 2D height */ } CALdeviceinfo; [su_box style="default" title="" box_color="#696969" radius="0"]

Остальные поля структуры определяют максимальный размер текстурной памяти по двум координатам, которую можно выделить на данном GPU.

[/su_box]

Намного более интересна структура CALdeviceattribs, отвечающая за атрибуты GPU (я приведу только несколько полей структуры):

typedef struct CALdeviceattribsRec { CALtarget target; /**< Asic identifier (тот же Device Kernel ISA) */ CALuint localRAM; /**< Размер локальной GPU RAM в мегабайтах */ CALuint wavefrontSize; /**< Размер warp'a (количество одновременно запускаемых потоков одним потоковым процессором) */ CALuint numberOfSIMD; /**< Количество мультипроцессоров */ CALboolean computeShader; /**< Поддерживается ли Compute Shader */ CALuint pitch_alignment; /**< Требуемая величина выравнивания размера памяти при вызове calCreateRes */ /* Другие поля */ } CALdeviceattribs;

Правило №3: поле CALdeviceattribs.pitch_alignment измеряется в элементах памяти, а не в байтах. Элементом памяти является 1-, 2- или 4-х компонентный вектор 8-, 16- или 32-битных регистров.

А теперь давайте внимательно посмотрим, какие же значания может принимать поле CALdeviceinfo.target (оно же CALdeviceattribs.target):

/** Device Kernel ISA */ typedef enum CALtargetEnum { CAL_TARGET_600, /**< R600 GPU ISA */ CAL_TARGET_610, /**< RV610 GPU ISA */ CAL_TARGET_630, /**< RV630 GPU ISA */ CAL_TARGET_670, /**< RV670 GPU ISA */ CAL_TARGET_7XX, /**< R700 class GPU ISA */ CAL_TARGET_770, /**< RV770 GPU ISA */ CAL_TARGET_710, /**< RV710 GPU ISA */ CAL_TARGET_730, /**< RV730 GPU ISA */ CAL_TARGET_CYPRESS, /**< CYPRESS GPU ISA */ CAL_TARGET_JUNIPER, /**< JUNIPER GPU ISA */ CAL_TARGET_REDWOOD, /**< REDWOOD GPU ISA */ CAL_TARGET_CEDAR, /**< CEDAR GPU ISA */ CAL_TARGET_RESERVED0, CAL_TARGET_RESERVED1, CAL_TARGET_WRESTLER, /**< WRESTLER GPU ISA */ CAL_TARGET_CAYMAN, /**< CAYMAN GPU ISA */ CAL_TARGET_RESERVED2, CAL_TARGET_BARTS, /**< BARTS GPU ISA */ } CALtarget;

Оказывается, это поле обозначает чип, на котором построен GPU.

Таким образом, узнать точно, как называется GPU в миру (к примеру, Radeon HD 3850) с помощью AMD CAL нельзя в принципе! Вот такая вот удобная технология… Зато интересно было наблюдать, что, к примеру, Radeon HD 5750 и Radeon HD 6750 являются на самом деле одной и той же видеокартой! Они лишь немного отличаются по частоте работы памяти (в пределах нескольких процентов).

Еще одно замечание: в этом списке нет Evergreen GPU, о котором я упоминал в первой части.

Мое предположение — GPU семейства Evergreen начинаются с чипа Cypress (CAL_TARGET_CYPRESS).

Все, что до этого, — предыдущее поколение без поддержки новых плюшек (циклический сдвиг, поддержка флагов операций и 64-битные операции).

Для дальнейшей работы нам надо создать дескриптор устройства (device), с помощью которого мы будем взаимодействовать с GPU:

unsigned int deviceId = 0; // идентификатор GPU CALdevice device; CALresult result = calDeviceOpen( &device, deviceId ); CALcontext context; result = calCtxCreate( &context, device );

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

Не забываем про парные вызовы после окончания работы с устройством:

calCtxDestroy( context ); calDeviceClose( device );

Вызовы должны идти именно в этом порядке, иначе получим hardware exception.

Итак, мы создали устройство и контекст для него, теперь можно приступить к

Читайте также  Ключ шифрования PSK что это

Выделение памяти

Для работы с памятью надо выделить ресурс.

Согласно документации, ресурс может располагаться в локальной памяти (local memory = stream processor memory) и удаленной памяти (remote memory = system memory).

Насколько я понял, remote memory является ничем иным, как оперативной памятью, тогда как local memory — память самой GPU.

Зачем нужна remote memory, если есть local memory? Во-первых, она нужна для разделения одной и той же памяти между несколькими GPU.

То есть, remote memory можно выделить один раз и работать с ней из нескольких GPU. Во-вторых, не все GPU поддерживают прямое обращение к своей памяти (см.

ниже «Получение прямого доступа к памяти»).

CALresource resource; unsigned int memoryWidth; unsigned int memoryHight; CALformat memoryFormat; unsigned int flags; // Выделение ресурса в удаленной памяти // 1D память CALresult result = calResAllocRemote1D( &resource, &device, 1, memoryWidth, memoryFormat, flags ); /* Так как удаленную память можно разделять между несколькими GPU, то второй параметр — массив указателей на соответствующие дескрипторы, третий параметр — количество элементов в этом массиве (1 в нашем случае) */ // 2D память CALresult result = calResAllocRemote2D( &resource, &device, 1, memoryWidth, memoryHeight, memoryFormat, flags ); // Выделение ресурса в локальной памяти // 1D память CALresult result = calResAllocLocal1D( &resource, device, memoryWidth, memoryFormat, flags ); /* Обратите внимание, что здесь уже принимается только один дескриптор, а не массив указателей на дескрипторы */ // 2D память CALresult result = calResAllocLocal2D( &resource, device, memoryWidth, memoryHeight, memoryFormat, flags );

Ширина и высота выделяемого ресурса измеряется в элементах памяти.
Сам же элемент памяти описывается параметром memoryFormat:

Источник: https://www.pvsm.ru/amd-app/2987

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.

В данной статье будет рассмотрена технология IL, ее область применения, ограничения, преимущества по сравнению с OpenCL. Кому интересно, прошу под кат.

Введение

Для начала, приведу некоторые сравнения с Nvidia CUDA SDK:

  1. Язык программирования высокого уровня:
    • Nvidia: CUDA C++ Extension
    • AMD: OpenCL 1.1 либо Compute Abstraction Layer (CAL)

  2. Язык программирования низкого уровня (псевдо ассемблер*):
    • Nvidia: Parallel Thread Execution (PTX)
    • AMD: Intermediate Language (IL)

  3. Соотношение «количество попугаев в секунду» (к примеру, количество перебираемых хешей в секунду) к «цене GPU»:
    • Nvidia: x
    • AMD: ~2x при использовании связки CAL/IL

* означает, что язык хоть и похож на ассемблер, он все же оптимизируется компилятором и преобразовывается в разный код для разных GPU За счет чего же можно получить такой выигрыш в производительности?

Особенности архитектуры AMD GPU

Если внимательно почитать спецификацию Nvidia PTX и спецификацю AMD IL, то можно заметить, что операнды в Nvidia PTX являются однокомпонентыми векторами (то есть простыми n-битными регистрами), в то время как операнды AMD IL являются 4-х компонентыми векторами n-битных регистров. Это станет более понятно, если рассмотреть операцию умножения в обоих языках: # Nvidia PTX mul.u32 %r0, %r1, %r2 # AMD ILumul r0.xyzw, r1.xyzw, r2.xyzw
Таким образом, за одну (почти за одну) операцию AMD GPU может изменить вплоть до 4-х n-битных регистров, а Nvidia GPU — только один n-битный регистр (имеется в виду в пределах одного GPU-потока). Но ведь OpenCL также позволяет объявлять многокомпонентные вектора и работать с ними! Тогда в чем отличие и зачем вообще нужен этот IL?

Отличие от OpenCL

А все отличия заключаются банально в том, что разработчикам AMD APP SDK было либо сложно, либо технически невозможно создать компилятор, переводящий код, написанный по спецификации OpenCL, в код, написанный на AMD IL. Отсюда и возникли ограничения по поддержке стандарта OpenCL:

  • OpenCL 1.0 поддерживается начиная примерно с Radeon HD 4000 Series (Beta Level Support) (возможно, отсутствует поддержка image object, т.е. текстурной памяти)
  • OpenCL 1.1 поддерживается начиная примерно с Radeon HD 5000 Series
  • OpenCL 1.2 поддерживается начиная примерно с Radeon HD 7000, но при этом еще даже не вышло SDK, поддерживающее эту версию стандарта

При этом стоит отметить, что AMD IL позволяет использовать для GPGPU-вычислений некоторые карточки из Radeon HD 3000 Series и даже из Radeon HD 2000 Series! (если быть совсем точным, то это GPU на чипах R600, RV610, RV630 и RV670) Далее для краткости будем обозначать все GPU, начиная с Radeon HD 5000 Series, как Evergreen GPUs (это чип Radeon HD 5700), потому что только для этих карточек поддерживаются некоторые интересные операции.

Прежде чем перейти к объяснению принципов написания кода на AMD IL, я бы хотел заострить ваше внимание на

Особенности работы с памятью

Как я уже упоминал, 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 КБ, если мне не изменяет память, в расчете на один потоковый процессор) и возможность обращения к памяти по вещественным координатам. При выходе за границы текстуры можно либо считывать граничный элемент, либо закольцовываться и считывать сначала (координата берется по модулю ширины/длины текстуры). А теперь приступим к самому интересному:

Работа с регистрами

Сперва небольшое пояснение, как происходит обмен между регистрами в операциях. Выходной регистр на месте компоненты вектора может содержать либо имя компоненты, либо знак «_», что означает, что данная компонента не будет изменена.

Каждый входной регистр на месте каждой компоненты может содержать любое имя из четырех компонент, либо «0», либо «1». Это означает, что в операции над соответствующей компонентой выходного регистра участвует либо компонента входного регистра, либо константа.

Поясню сказанное на примере:

# r0.x = r1.z# r0.y = r1.w# r0.w = r1.ymov r0.xy_w, r1.zwyy # r0.y = 1# r0.z = 0mov r0._yz_, r1.x100

Шейдеры

Код для 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

il_ps_2_0 ; Константный буфер (cb0):; cb0[0].x — искомая константа; cb0[0].y — количество потоков; cb0[0].

zw — мусорdcl_cb cb0[1] ; Входная текстура с данными (i0); тип текстуры — двумерная (обращение по двум координатам), ненормированная (иначе значения были бы типа float от 0 до 1); всем компонентам нужно задать один и тот же тип (в нашем случае uint)dcl_resource_id(0)_type(2d,unnorm)_fmtx(uint)_fmty(uint)_fmtz(uint)_fmtw(uint) ; Это нужно для получения идентификатора потокаdcl_input_position_interp(linear_noperspective) vWinCoord0.xy__ ; Выходной буфер (g[]) ; Константа, хранится в памяти командdcl_literal l0, 0xFFFFFFFF, 0xABCDEF01, 0x3F000000, 2 ; Считываем вещественные координаты потока с преобразованием в целочисленные; r0.x — координата по x для i0 для потока (float) (равна локальному идентификатору потока в блоке); r0.y — координата по y для i0 для потока (float) (равна глобальному идентификатору блока)ftoi r0.xyzw, vWinCoord0.xyxy ; Вычисляем r0.z — глобальный идентификатор потока (uint)umad r0.__z_, r0.wwww, cb0[0].yyyy, r0.zzzz ; Сохраняем первую часть данных в регистрftoi r1.x___, vWinCoord0.xxxxmov r1._y__, r0.zzzzmov r1.__z_, cb[0].xxxxmov r1.___w, l0.yyyy ; Вычисляем смещение для выходного буффера g[]umul r0.__z_, r0.zzzz, l0.wwww ; Сохраняем первую часть данных в памятьmov g[r0.z+0].xyzw, r1.xyzw ; Загружаем данные из текстуры i0; предварительно переводим координаты во float и прибавляем 0.5itof r0.xy__, r0.xyyyadd r0.xy__, r0.xyyy, l0.zzzzsample_resource(0)_sampler(0)_aoffimmi(0,0,0) r1, r0 ; sample_resource(0) — читаем из i0; _sampler(0) — с помощью sampler'a #0; _aoffimmi(0,0,0) — смещения по x, y, z; если нужно считать соседний элемент в строке текстуры, то _aoffimmi(1,0,0); в столбце — _aoffimmi(0,1,0) ; Сохраняем вторую часть данных в памятьmov g[r0.z+1].xyzw, r1.xyzw ; Выход из главной функцииendmain ; Завершение кода программыend

Compute Shader

Все отличие будет заключаться только в вычислении идентификаторов потока, остальное все то же самое. il_cs_2_0dcl_num_thread_per_group 64 ; Константный буфер (cb0):; cb0[0].x — искомая константа; cb0[0].

yzw — мусорdcl_cb cb0[1] ; Входная текстура с данными (i0); тип текстуры — двумерная (обращение по двум координатам), ненормированная (иначе значения были бы типа float от 0 до 1); всем компонентам нужно задать один и тот же тип (в нашем случае uint)dcl_resource_id(0)_type(2d,unnorm)_fmtx(uint)_fmty(uint)_fmtz(uint)_fmtw(uint) ; Выходной буфер (g[]) ; Константа, хранится в памяти командdcl_literal l0, 0xFFFFFFFF, 0xABCDEF01, 0x3F000000, 2 ; номер блокаmov r0._y__, vThreadGrpIDFlat.xxxx ; номер потока в блокеmov r0.x___, vTidInGrpFlat.xxxx ; глобальный номер потокаmov r0.__z_, vAbsTidFlat.xxxx ; Сохраняем первую часть данных в регистрmov r1.x___, vTidInGrpFlat.xxxxmov r1._y__, vAbsTidFlat.xxxxmov r1.__z_, cb[0].xxxxmov r1.___w, l0.yyyy ; Вычисляем смещение для выходного буффера g[]umul r0.__z_, r0.zzzz, l0.wwww ; Сохраняем первую часть данных в памятьmov g[r0.z+0].xyzw, r1.xyzw ; Загружаем данные из текстуры i0; предварительно переводим координаты во float и прибавляем 0.5itof r0.xy__, r0.xyyyadd r0.xy__, r0.xyyy, l0.zzzzsample_resource(0)_sampler(0)_aoffimmi(0,0,0) r1, r0 ; sample_resource(0) — читаем из i0; _sampler(0) — с помощью sampler'a #0; _aoffimmi(0,0,0) — смещения по x, y, z; если нужно считать соседний элемент в строке текстуры, то _aoffimmi(1,0,0); в столбце — _aoffimmi(0,1,0) ; Сохраняем вторую часть данных в памятьmov g[r0.z+1].xyzw, r1.xyzw ; Выход из главной функцииendmain ; Завершение кода программыend

Различия шейдеров

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

Заключение

Я попытался рассказать в данной статье, как написать на AMD IL простой код для выполнения на самой GPU.

В качестве заключения несколько слов об оптимизации скорости работы:

  • Не пытайтесь применять техники оптимизации, свойственные для ассемблера (предвычисление операций с константами, перестановка независимых операций). Не забывайте, что это все же псевдо ассемблер, поэтому оптимизацию за вас сделает компилятор. Лучше подумайте над алгоритмом.
  • Загружайте на карточку как можно больше данных. Желательно использовать все 32 бита всех 4-х компонент вектора.
  • Если у вас есть однотипные вычисления над входными данными (к примеру, вычисление хеша), то стоит поэкспериментировать над количеством компонент в операциях: иногда быстрее будет работать r0.x___, иногда r0.xy___, а иногда r0.xyzw.
  • Хоть AMD и утверждает, что количество потоков в блоке может быть любым, кратным и при этом GPU будет корректно себя вести, на самом деле это не так. В природе я видел только =32 или 64, и у меня GPU работала корректно только при количестве потоков в блоке, равном . Более того, Radeon HD 4650 при запуске с 32 потоками в блоке (а по техническим данным, для этой карточки =32) на одном из моих алгоритмов выдавала некорректные данные, зато с 64 потоками в блоке работала на ура. Вывод: запускайте алгоритм только с 64 потоками в блоке (а количество блоков уже можно варьировать).
  • GPU Evergreen поддерживают несколько прикольных особенностей: циклический сдвиг, поддержку флагов переполнения, поддержку 64-битных операций (для этого резервируются 2 компоненты). К сожалению, GPU семейства младше Evergreen все эти плюшки не поддерживают. Если кто подскажет, как на них написать 64-битные операции, буду признателен.

О том, как же передавать данные на карточку и забирать данные с нее, написано во второй части про AMD Compute Abstraction Layer (CAL).

Ссылки для ознакомления

Источник: https://habr.com/post/138954/

AMD OpenCL ™ APP SDK 2.6 и AMD Catalyst ™ Разработчик драйвера доступны для загрузки

Саннивейл, Calif.  -1/11/2012 

AMD (NYSE: AMD) выпустила новые версии AMD APP SDK и AMD Catalyst ™ разработчиков драйверов, которые включают в себя много новых функций, в том числе несколько возможностей недавно опубликованной OpenCL ™ 1,2 спецификация.

Новые функции предоставляют разработчикам значительные кодирования улучшения производительности, что делает его гораздо легче писать OpenCL использованием C.Кроме того, новые возможности доставить во время выполнения повышения производительности.Более подробную информацию о AMD APP SDK 2.

6 и драйверы AMD Catalyst разработчик см. соответствующие AMD Developer блог post.

“AMD делает упор на OpenCL позволяет разработчикам с большей легкостью использовать возможности гетерогенных вычислений”, сказал Манджу Хедж, корпоративный вице-президент AMD Fusion Experience Program.”Последний релиз SDK и драйверов разработчика повышает производительность труда разработчиков за счет внедрения новых функций, таких как C API оболочки и ядра статические C языковая поддержка”.

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

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

Основные функции, поддерживаемые в SDK 2.6 и AMD Catalyst 11,12 водителя:

        

  • Включение Khronos C API Wrapper
  •     

  • OpenCL выполнения интеграции в Linux в дополнение к Windows ® Catalyst drivers.
  •     

  • Multi GPU поддержка Linux platforms
  •     

  • Поддержка расширений AVX для процессоров, поддерживающих эту extension
  •     

  • Поддержка расширений в FMA4 OpenCL встроенной функцией библиотеки для процессоров, поддерживающих эту extension

Дополнительные возможности предварительного просмотра снабжена разработчиков Driver:

        

  • Статическое ядро ​​C language
  •     

  • OpenCL ™ 1.2 Возможности просмотра:    
              

    • Host флаги доступа для объектов памяти обеспечивает более эффективную обработку буфера
    •         

    • План основе GPU буфера и инициализации изображения устраняет потребность в определенных буфер / изображение transfers
    •         

    • Память объекты миграции поддерживает передачу буфера до need
    •         

    • Новый образ обобщенного создание API
    •         

    • Enhanced Image / буфер карты operations

AMD OpenCL™ APP SDK 2.6 and AMD Catalyst™ Developer Driver Available for Download

SUNNYVALE, Calif. —1/11/2012 

AMD (NYSE: AMD) released new versions of the AMD APP SDK and AMD Catalyst™ developer drivers which include many new features, including several capabilities of the recently published OpenCL™ 1.2 specification.

The new features provide developers with significant coding productivity enhancements, making it much easier to write OpenCL using C++. In addition, the new features deliver run-time performance enhancements. For more details on the AMD APP SDK 2.

6 and AMD Catalyst developer drivers see the related AMD Developer blog post.

“AMD is focusing on OpenCL to enable developers to more easily harness the power of heterogeneous computing,” said Manju Hegde, corporate vice president, AMD Fusion Experience Program. “The latest SDK and developer drivers release enhances developer productivity by introducing new features the C++ wrapper API and Static C++ kernel language support.”

AMD is driving industry support for OpenCL with developers and technology companies around the world, contributing to the establishment of OpenCL as a top tool for developers. For consumers, they will continue to see more software applications coming to market that are optimized on OpenCL.

The new applications will leverage the full processing capabilities of the CPU and GPU, which enables faster run-times, longer battery life and smoother playback in their favorite software applications when running in a broad range of notebook, desktop and all-in-one PCs VISION Technology from AMD.

Key features supported in SDK 2.6 and AMD Catalyst 11.12 driver:

  • Inclusion of the Khronos C++ Wrapper API
  • OpenCL runtime integration into Linux in addition to Windows® Catalyst drivers.
  • Multi GPU support on Linux platforms
  • Support for AVX extensions for CPUs that support this extension
  • Support for FMA4 extensions in OpenCL built-in function libraries for CPUs that support this extension

Additional preview capabilities provided with the Developer Driver:

  • Static C++ kernel language
  • OpenCL™ 1.2 preview capabilities:
    • Host access flags for memory objects enables more efficient buffer handling
    • Pattern based GPU buffer and image initialization eliminates need for certain buffer/image transfers
    • Memory objects migration supports transfer of buffer prior to need
    • New generalized image creation API
    • Enhanced image/buffer map operations

Resources

Источник: http://news.instore.kz/2012/01/6180

Как установить AMD APP SDK в Kali Linux 2

Источник: http://www.blackmoreops.com/2013/11/22/install-amd-app-sdk-kali-linux/ (материал актуализирован)

Эта статья является частью цикла, в который входят следующие заметки:

Проверка установки FGLRX

Начнём с проверки, установлен ли модуль fglrx:

lsmod | grep fglrx

Вы должны получить что-то вроде этого:

root@HackWare:~# lsmod | grep fglrx fglrx 13303808 150 button 16384 1 fglrx

Если модуль не установлен, то переходите к инструкции «Как установить драйвер AMD Catalyst 15.7 (ATI fglrx) на Kali Linux 2».

Что такое технология AMD APP?

Технология AMD APP — это набор продвинутых аппаратных и программных технологий, которые задействуют ядра графических процессоров AMD (GPU) для совместной работы с системными процессорами x86 (CPU) для гетерогенного выполнения, в результате чего многие приложения, не только графические, увеличивают свою производительность. Это позволяет лучше сбалансировать платформы, эффективнее использовать их вычислительные ресурсы по выполнению задач на недостижимой ранее скорости, а также даёт возможность разработчикам программного обеспечения ещё одну возможность оптимизировать их программы для AMD Accelerated Processing Units (APUs).

Что такое AMD APP Software Development Kit?

The AMD APP Software Development Kit (SDK) — это полная платформа разработчиков от AMD, которая позволяет вам быстро и просто создавать приложения, способные использовать технологию AMD APP. SDK содержит примеры, документацию и другие материалы для быстрого старта с использованием OpenCL™, Bolt, or C++ AMP в ваших C/C++ программах или Aparapi для ваших Java приложений.

Чтобы узнать больше, посмотрите OpenCL™ Zone.

Загрузка AMD APP SDK 3.0

Загрузите AMD APP SDK 3.0 со страницы загрузки архивов AMD.

Я скачиваю AMD APP SDK 3.0 for 64-bit Linux.

Установка SDK

Процесс установки указан для конкретной версии SDK. Более того, предполагается, что скачивание произошло в папку /root/Загрузки, а ваша текущая директория /root. Текущую директорию можно проверить командой pwd.

Если у вас другие пути или другая версия, то измените команды в соответствии с вашими данными. Или воспользуйтесь графической оболочкой для этих процедур.

mkdir amdappsdk mv /root/Загрузки/AMD-APP-SDKInstaller-v3* amdappsdk/ cd amdappsdk tar xvjf AMD-APP-SDKInstaller-v3* sh `ls AMD-APP-SDK* | grep -E 'sh'`

Скачиваем AMD APP SDK с помощью скрипта:

wget https://gist.githubusercontent.com/vchuravy/1faa40c2df51e3a9ee55/raw/8d79b81781f4990dd09583ca39b6373700725a8e/amd_sdk.sh sh amd_sdk.sh tar xvjf AMD-SDK.tar.bz2 sh `ls AMD-APP-SDK* | grep -E 'sh'`

Установка происходит в интерактивном режиме. Нам будет показана лицензия, которую нужно пролистать до конца клавишей [Enter]. Затем у нас спросят подтверждение:

By clicking accept, you confirm that you are neither a resident nor a national of Cuba, Iran, North Korea, the Sudan or Syria.

Принимая, вы подтверждаете, что вы не резидент и не гражданин стран Куба, Иран, Северная Корея, Судан или Сирия.

Если вы принимаете условия лицензии и не являетесь гражданином какой-либо из этих самых лучших стран, то нажимаете y.

Далее у нас спрашивают:

Enter the Installation directory. Press ENTER for choosing the default directory: [/opt]

В какой каталог установить программу. Если вы просто нажмёте [Enter], то программа установится в дефолтный каталог /opt — именно это нам и нужно.

Отредактируйте файл /root/.bashrc

leafpad /root/.bashrc

Чтобы узнать путь, куда программа установилась:

ls -ld /opt/AMDAPPSDK-3*

Добавьте в самый конец следующие строки:

# AMD APP SDK export AMDAPPSDKROOT=/opt/AMDAPPSDK-3.0/ export AMDAPPSDKSAMPLESROOT=/opt/AMDAPPSDK-3.0/ export LD_LIBRARY_PATH=${AMDAPPSDKROOT}lib/x86_64:${LD_LIBRARY_PATH} export ATISTREAMSDKROOT=$AMDAPPSDKROOT

Сохраните и закройте, затем наберите в терминале команду:

source ~/.bashrc

Проверить успешность можно следующей командой:

env | grep -i amd

Вывод должен быть таким:

AMDAPPSDKSAMPLESROOT=/opt/AMDAPPSDK-3.0/ LD_LIBRARY_PATH=/opt/AMDAPPSDK-3.0/lib/x86_64:/opt/AMDAPPSDK/lib/x86_64: ATISTREAMSDKROOT=/opt/AMDAPPSDK-3.0/ AMDAPPSDKROOT=/opt/AMDAPPSDK-3.0/ PWD=/root/amdappsdk

Разработчики AMD APP SDK долго перекладывали файлы, необходимые для компиляции CAL++, по разным папкам своего SDK. Из-за этого при изменении версий SDK возникали проблемы с компиляцией CAL++. В конце-концов файлы, необходимые для CAL++, просто исчезли. Чтобы вернуть их обратно, накатываем этот патч.

svn checkout https://github.com/clockfort/amd-app-sdk-fixes/trunk/include/CAL $AMDAPPSDKROOT/include/CAL

По сути, мы копируем каталог /include/CAL из SDK версии 2.7 в нашу SDK 3.0. Честно говоря, можно было просто установить версию AMD APP SDK 2.7.

Как установить AMD APP SDK в Kali Linux?

Эксклюзивное предложение для авторов статей

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

Эта инструкция из серии о том, Как установить GLRX, AMD APP SDK, CAL++ и Pyrit в Kali Linux.

Идея в том, чтобы установить корректные драйвера в Kali Linux для вашей видеокарты и использовать комбинацию из CPU+GPU с программой Pyrit для увеличения скорости обработки данных.

Практическим примером использования этой комбинации является «Взлом Wi-Fi пароля (WPA/WPA2), используя pyrit и cowpatty в Kali Linux».

Сама по себе установка AMD APP SDK в Kali Linux ничего не даёт. Это всего лишь промежуточный шаг для установки CAL++. Установка CAL++ тоже является всего лишь промежуточным шагом для установки Pyrit.

Для чего вся эта морока? Посмотрите на следующие два бенчмарка Pyrit. Первый — без подключённого CAL++, а второй с подключённым CAL++

В первом бенчмарке работает только процессор — i7, с турбобустами и прочими свистоперделками. Во втором бенчмарке подключается видеокарта — результат превышает первый в более чем 8 раз! Фактически, всю производительность в подобного рода вычислениях определяет графический процессор.

Если у вас более слабый процессор или более мощная видеокарта (моему ноуту уже несколько лет), а также если у вас настольный компьютер с полноценной видеокартой (а не ноут), то у вас выигрыш от подключения к вычислениям графического процессора будет в ещё большее число раз.

Читатели, пожалуйста, следуйте инструкциям из этой серии в следующем порядке:

Загрузка AMD APP SDK 3.0 Beta

Загрузите AMD APP SDK 3.0 Beta со страницы загрузки архивов AMD.

Понравилась статья? Поделить с друзьями: