Размещено на http://www.allbest.ru/

Реферат

«Особенности архитектуры и программирования графических ускорителей»



Введение

Идея применения специализированных арифметических ускорителей при построении суперкомпьютерных систем за последнее 5-10 лет стала довольно популярной благодаря возможности существенного повышения производительности при сохранении уровня энергопотребления и количества вычислительных узлов. Если проследить за эволюцией списка самых быстрых суперкомпьютеров мира Top500, то легко заметить, что переход к гетерогенным архитектурам не раз позволял соответствующим вычислительным системам занимать первые места с существенным отрывом от «классических» кластеров. Так, лидер списка Top500 2008 года суперкомпьютер RoadRunner, основную вычислительную мощность которого составили сопроцессоры IBM PowerXCell 8i , имел в 2,3 раза большую производительность, чем система корпорации IBM, занявшая тогда второе место.

Схожая ситуация наблюдалась и в 2010 году, когда из пяти самых быстрых суперкомпьютерных систем мира три были построены на базе графических ускорителей NVidiaTesla C2050, что позволило не только впервые преодолеть 2,5-петафлопсный барьер, но и легко обойти «классические» суперкомпьютеры как по пиковой, так и по реально достигнутой производительности. Согласно пресс-релизам компании Intel, очередного покорения вершин Top500 гетерогенными системами следует ожидать в 2012-2013 годах, когда увидят свет новые ускорители от Intel под кодовым названием Knight's Corner, которые позволят преодолеть рубеж в 10 петафлопс.

Применить технологии, отработанные при создании мощных игровых видеокарт для параллельных вычислений, впервые удалось NVIDIA, не остался в стороне и AMD со своим ускорителем FireStream. Использование графических ускорителей (GPGPU) позволяет получить значительную вычислительную мощность в десятки раз дешевле по деньгам и потребляемой мощности. В нынешнем списке TOP500 три из первой пятерки суперкомпьютеров используют ускорители NVIDIA TESLA. GPGPU -- единственная доступная по деньгам возможность получить «персональный суперкомпьютер» терафлопсной мощности в обычном настольном корпусе. Однако не все так просто, программирование для графических ускорителей не самое простое занятие. Также возникают вопросы, что выбрать -- дорогущую специализированную Tesla или топовую графическую карту, которая быстрее и дешевле? В любом случае, альтернативы множеству «легких» ядер пока не просматривается, а значит, приходится программировать все более параллельно. Сейчас выбор ПО, предназначенного для параллельной обработки данных с использованием не только лишь CPU весьма и весьма велик. В данном реферате будет кратко рассмотрена технология CUDA и OpenCL.

Основная часть

Развитие современных графических ускорителей или Graphic Processor Unit (в дальнейшем GPU) привело к появлению графических ускорителей с программируемым конвейером. Если раньше программист графических приложений мог использовать только фиксированную функциональность GPU, то теперь 2 стадии обработки информации в конвейере GPU стали программируемыми. Более точно программируемой стала обработка вершин, что позволило создавать, в частности, более разнообразные модели «освещения», а так же обработка фрагментов. Столь коренное изменение архитектуры GPU привело к возможности использования GPU не только для целей компьютерной графики, но и для задач, которые раннее решались на CPU, таким образом, появилась Технология Вычислений Общего Назначения на Графическом Ускорителе или General Purpose computation on Graphic Processor Unit (в дальнейшем просто GPGPU).



1. Преимущества GPGPU

Современные GPU обладают высокой скоростью доступа к своей собственной оперативной памяти, которая обычно именуется текстурной памятью, и имеют высокую вычислительную мощность.

Для примера приведем некоторые числа (см. [1]):

Если у Intel 3.0 GHz Pentium 4 пиковая вычислительная мощность оценивается как 12 GFLOPs, то у видеокарты ATI Radeon X1800XT 120 GFLOPs, для этого же оборудования пиковая скорость обмена данными между процессором и соответствующей памятью составляет соответственно 5.96 GB/s у CPU против 42 GB/s у GPU.



Но GPU не только быстры и мощны, но и что важно, их мощности растут очень быстрыми темпами. Так в [2] приводятся следующие данные:

Годовой рост производительности CPU - 1.4 раза, а для GPU - 1.7 раз для фрагментного процессора и 2.3 раза для вершинного.

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

· преобразования вершин;

· преобразования нормали, нормализации;

· генерирования текстурных координат;

· преобразования текстурных координат;

· настройки освещения;

· наложения цвета материала.

Фрагментный процессор - программируемый модуль, который выполняет операции над фрагментами и другими связанными с ними данными. Фрагментный процессор может выполнять следующие стандартные графические операции:

· операции над интерполированными значениями;

· доступ к текстурам;

· наложение текстур;

· создание эффекта дымки;

· наложение цветов.

Если учесть при этом относительно низкую стоимость видеокарт по сравнению с равномощными CPU, то станет понятно зачем использовать видеокарты для вычислений общего назначения.



2. Программируемость и гибкость

Шейдер - это программа, исполняемая непосредственно на GPU. Современные языки шейдеров разработанные с использованием синтаксиса «C» позволяют программистам относительно быстро начать писать эффективный программы для графического ускорителя. При этом язык шейдеров является достаточно гибким и удобным средством для разработки в том числе и сложных вычислительных подпрограмм, к тому же многие математические функции реализованы на GPU аппаратно, что добавляет быстродействия вычислительным программам.



3. Архитектура GPU

3.1 Конвейер GPU

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

Структура проведения операций на всех современных GPU может быть представлена конвейером (graphic pipeline), который устроен таким образом, чтобы обеспечить максимальную эффективность выполнения задач компьютерной графики при условии потоковой параллельной архитектуры.

На вход подается набор вершин, поступающий из приложения затем вершины обрабатываются в вершинных процессорах классифицируемых как MIMD, программа для вершинных процессоров называется вершинным шейдером. После этого результат работы вершинного шейдера поступает на сборку примитивов, таких как полигоны или линии, далее следует тесты видимости отсечения и прочие стандартные операции компьютерной графики, после них данные поступают на растеризацию. Здесь объемное изображение проецируется на плоский экран, и полученная картинка масштабируется в соответствии-с параметрами окна приложения. Результатом этой операции является картинка, текстура представляющая из себя прямоугольный массив так называемых пикселей. Пиксель может быть представлен 1-4 числами, например, в формате RGBA, те red, green, blue, alpha (коэфицент прозрачности).

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

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

3.2 Введение в модель программирования на GPU

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

Рассмотрим основные общие моменты структуры программы использующей описываемую технологию :

Разработчик определяет модель параллелизуемых процессов. Он разрабатывает вычислительное ядро программы, те ту часть программного кода, которая выполняет основные вычисления, именно эта часть и пишется непосредственно для видеокарты, для чего используется язык шейдеров. Каждое вычислительное ядро представляет собой набор команд языка шейдеров, причем каждое ядро работает независимо от другого, на вход шейдера поступают такие данные как текстуры (только на чтение) скаляры массивы чисел, на выход подается один тексел (максимум 4 float числа ) и глубина ( 1 float число ). Результат работы каждого ядра не может быть использован другим ядром, те данные на выходе только на запись. Другими словами данные текстуры на выходе образуют потоки, параллелизм которых обеспечивается ядром выполняемым на каждом процессоре независимо от другого. После того как ядра и потоки были определены, необходимо задать поток выходных данных. Для этого необходимо сделать несколько необычные для программиста не связанного с компьютерной графикой действия, а именно нарисовать некоторый графический примитив на экран средствами используемого графического API. Для целей GPGPU обычно рисуется четырехугольник, величиной с используемое окно, которое лучше назвать просто буфером кадра, т.к. собственно окно в привычном смысле не создается, т.е. на экран ничего не выводится, но выделяется область памяти на GPU, предназначенная для хранения результатов вычислений, эта область является ничем иным как буфером кадра в привычной терминологии компьютерной графики. Здесь же отмечу, что память на видеокарте не линейно адресуема, но двумерна и, хотя можно использовать одномерные тектуры, а так же трехмерные, все же наиболее быстрая работа обеспечивается именно для двумерных текстур, так же одно - и трехмерные текстуры существенно ограничены по размеру. После того как вами был нарисован примитив, растерайзер разбивает его на фрагменты, причем если четырехугольник размером с окно, то каждому пикселю соответствует единственный фрагмент. Фрагменты поступают в фрагментные процессоры и обрабатываются там фрагментным (он же пиксельный) шейдером. В итоге мы имеем некоторые данные в буфере кадра которые можно копировать в текстуру если тектуры не была определена как буфер кадра, что позволяют сделать некоторые расширения API например для OpenGL. Далее данные, хранимые в текстуре могут быть переданы в оперативную память или поступить на вход шейдера для дальнейших вычислений.

3.3 Модель памяти GPU

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

GPU так же как CPU имеет свои собственные регистры и кэш, для ускорения доступа к данным во время вычислений. Помимо этого GPU имеет свою собственную основную память (графическая память), поэтому для того, чтобы программист мог выполнять вычисления на GPU он должен предварительно передать данные из оперативной памяти CPU в память GPU. Эта операция традиционно является достаточно дорогостоящей с точки зрения производительности ввиду относительно не высокой скорости передачи данных между памятью приложения и памятью видеокарты, хотя современны шины PCI Express и специальные чипы на материнской плате ( такие как NV3 и NV4 ) заметно ускорили этот процесс.

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

4. Архитектура графических адаптеров Nvidia

Одним из наиболее распространенных видов гибридных машин является гибридная машина на основе графических адаптеров компании Nvidia. Для того чтобы эффективно уметь программировать под такого рода машины необходимо детально понимать устройство графического адаптера с аппаратной точки зрения. Любая графическая карта может быть схематически изображена следующим образом (Рис. 1).

Рисунок 1 Схематичное изображение графического адаптера

программирование адаптер графический

Все вычислительные ядра на графическом адаптере объединены в независимые блоки TPC (Texture process cluster) количество которых зависит как от версии чипа (G80 - максимум 8, G200 - максимум 10), так и просто от конкретной видеокарты внутри чипа (GeForce 220GT - 2, GeForce 275 - 10). Так же, как от видеокарты к видеокарте может меняться количество TPC, так же может меняться и количество DRAM партиций и соот ветственно общий объем оперативной памяти. DRAM партиции имеют кэш второго уровня и объединены между собой коммуникационной сетью, в которую, так же подключены все TPC. Любая видеокарта одключается к CPU через мост, который может быть, как интегрирован в CPU (Intel Core i7), так и дискретным (Intel Core 2 Duo). От чипа к чипу (от G80 до G200) менялись детали в TPC, а общая архитектура оставалась одинаковой. В новом чипе Fermi произошли изменения и в общей архитектуре, поэтому о нем речь пойдет отдельно.



5. Архитектура чипа G80

Основные составляющие TPC:

· TEX - логика работы с текстурами, содержит в себе участки конвейера, предназначенные для обработки особой текстурной памяти о которой речь пойдет позже.

· SM - потоковый мультипроцессор, самостоятельный вычислительный модуль, именно на нем осуществляется выполнение блока. В архитектуре чипа G80 в одном TPC находится 2 SM.

Основные составляющие SM:

· SP - потоковый процессор, непосредственно вычислительный модуль, способен совершать арифметические операции с целочисленными операндами и с операндами с плавающей точкой (одинарная точность). Не является самостоятельной единицей, управляется SM.

· SFU - модуль сложных математических функций. Проводит вычисления сложных математических функций (exp, sqr, log). Использует вычислительные мощности SP.

· Регистровый файл - единый банк регистров, на каждом SM имеется 32Кб. Самый быстрый тип памяти на графическом адаптере.

· Разделяемая память - специальный тип памяти, предназначенный для совместного использования данных тредов из одного блока. На каждом SM - 16Кб разделяемой памяти.

· Кэш констант - место кэширования особого типа памяти (константной). Об особенностях применения речь пойдет позже.

· Кэш инструкций, блок выборки инструкций - управляющая система SM. Не играет роли при программировании.

Итого, чип G80 имеет максимально 128 вычислительных модулей (SP) способных выполнять вычисления с целыми числами и числами с плавающей точкой с одинарной точностью. Такого функционала было недостаточно для многих научных задач, требовалась двойная точность.



6. CUDA. OpenCL

CUDA (англ. Compute Unified Device Architecture) -- программно-аппаратная архитектура параллельных вычислений, которая позволяет существенно увеличить вычислительную производительность благодаря использованию графических процессоров фирмы Nvidia.

OpenCL (Open Computing Language) -- открытый стандарт параллельного программирования для гетерогенных платформ (в частности, для GPGPU), включающих центральные, графические процессоры и другие дискретные вычислительные устройства. OpenCL позволил использовать мощности GPU на различных программных и аппаратных платформах.

Для технологии CUDA существует два API:

· CUDA RunTime API (Программа и вычислительные ядра компилируются компилято-ром, графический ускоритель получает уже готовый PTX код для себя)

· CUDA Driver API (Программа компилируется компилятором, ядра компилируются драй-вером устройства)

Для OpenCl существует только один API - OpenCL Driver API (OpenCL).

CUDA Driver API является более сложным, но при этом в большинстве научных задач в нем нет необходимости, поэтому он не будет рассмотрен

CUDA Driver API:

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

2. Выбор устройства (GPU)

3. Создание контекста

OpenCL API:

1. Выбор платформы

2. Создание контекста, привязанного к платформе

3. Выбор устройства из контекста

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



7. Модель платформы OpenCL

Модель платформы (platform model) дает высокоуровневое описание гетерогенной системы. Центральным элементом данной модели выступает понятие хоста (host) - первичного устройства, которое управляет OpenCL-вычислениями и осуществляет все взаимодействия с пользователем. Хост всегда представлен в единственном экземпляре, в то время как OpenCL-устройства (devices), на которых выполняются OpenCL-инструкции могут быть представлены во множественном числе. OpenCL-устройством может быть CPU, GPU, DSP или любой другой процессор в системе, поддерживающийся установленными в системе OpenCL-драйверами. OpenCL-устройства логически делятся моделью на вычислительные модули (compute units), которые в свою очередь делятся на обрабатывающие элементы (processing elements). Вычисления на OpenCL-устройствах в действительности происходят на обрабатывающих элементах. На рис. 12 схематически изображена OpenCL-платформа из 3-х устройств.



8. Подробное рассмотрение OpenCL

OpenCL первоначально был разработан в компании Apple Inc. Apple внесла предложения по разработке спецификации в комитет Khronos. Вскоре компания AMD решила поддержать разработку OpenCL (и DirectX 11), который должен заменить фреймворк Close to Metal.

Версии:

18 ноября 2008 г. - OpenCL 1.0

14 июня 2010 г. - OpenCL 1.1

15 ноября 2011 г. - OpenCL 1.2

2 июля 2013 г. - OpenCL 2.0

Программная модель.

Ядро (kernel) -- функция, исполняемая устройством. Имеет в описании спецификацию __kernel.

Программа (program) -- набор ядер, а также, возможно, вспомогательных функций, вызываемых ими, и константных данных.

Приложение (application) -- комбинация программ, работающих на управляющем узле и вычислительных устройствах.

Команда (command) -- операция OpenCL, предназначенная для исполнения (исполнение ядра на устройстве, манипуляции с памятью и т. д.)

Объекты

Объект (object) -- абстрактное представление ресурса, управляемого OpenCL API (объект ядра, памяти и т. д.)

Дескриптор (handle) -- непрозрачный тип, ссылающийся на объект, выделяемый OpenCL. Любая операция с объектом выполняется через дескриптор.

Очередь команд (command-queue) -- объект, содержащий команды для исполнения на устройстве.

Объект ядра (kernel object) -- хранит отдельную функцию ядра программы вместе со значениями аргументов.

Объект события (event object) -- хранит состояние команды. Предназначен для синхронизации.

Объект буфера (buffer object) -- последовательный набор байт. Доступен из ядра через указатель и из управляющего узла при помощи вызовов API.

Объект памяти (memory object) -- ссылается на область глобальной памяти.

Устройства

Рабочий элемент (work-item) -- набор параллельно исполняемых ядер на устройстве, вызванных при помощи команды.

Рабочая группа (work-group) -- набор взаимодействующих рабочих элементов, исполняющихся на одном устройстве. Исполняют одно и то же ядро, разделяют локальную память и барьеры рабочей группы.

Обрабатывающий элемент (processing element) -- виртуальный скалярный процессор. Рабочий элемент может выполняться на одном или нескольких обрабатывающих элементах.

Вычислительный узел (compute unit) -- исполняет одну рабочую группу. Устройство может состоять из одного или нескольких вычислительных элементов.

Контекст

Контекст (context) -- среда, в которой выполняются ядра, а также область определения синхронизации и управления памятью. Включает:

§ набор устройств;

§ память, доступную устройствам;

§ свойства памяти;

§ одну или несколько очередей команд.

Объект программы (program object) -- включает:

§ ссылку на связанный контекст;

§ исходный текст или двоичное представление;

§ последний удачно собранный код, список устройств, для которых он собран, настройки и журнал сборки;

§ набор текущих связанных ядер.

Функции

1) Функция «Обнаружение платформ»

cl_int clGetPlatformIDs(

cl_uint nNumEntries,

cl_platform_id *pPlatforms,

cl_uint *pnNumPlatforms );

2) Функция «Обнаружение устройств на платформе»

cl_int clGetDeviceIDs(

cl_platform_id platformID,

cl_device_type nDeviceType,

cl_uint num_entries,

cl_device_id *pDevices,

cl_uint *pnNumDevices);

nDeviceType	Описание
CL_DEVICE_TYPE_CPU	Центральный процессор
CL_DEVICE_TYPE_GRU	Видеокарта
CL_DEVICE_TYPE_ ACCELERATOR	специализированный ускоритель
CL_DEVICE_TYPE_DEFAULT	устройство по молчанию в системе
CL_DEVICE_TYPE_ALL	все доступные устройства OpenCL

3) Функция «Создание контекста»

cl_context clCreateContext(

const cl_context_properties *pProperties,

cl_uint num_devices,

const cl_device_id *pDevices,

void (CL_CALLBACK *pfnNotify)( const char *pcszErrInfo, const void *pvPrivateInfo, size_t uSizePrivateInfo, Void *pvUserData),

void *pvUserData,

cl_int *errcode_ret);

4) Функция «Создание очереди команд»

cl_command_queue clCreateCommandQueue(

cl_context context,

cl_device_id deviceID,

cl_command_queue_properties nProperties,

cl_int *pnErrCodeRet);

nProperties	Описание
CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE	исполнение не по порядку;
CL_QUEUE_PROFILING_ENABLE	включение профилирования.

5) Функция «Создание объекта программы»

cl_program clCreateProgramWithSource(

cl_context context,

cl_uint uCount,

const char **ppcszStrings,

const size_t *puLengths,

cl_int *pnErrCodeRet);

6) Функция «Сборка программы»

cl_int clBuildProgram(

cl_program program,

cl_uint uNumDevices,

const cl_device_id *pcDeviceIDList,

const char *pcszOptions,

void (CL_CALLBACK *pfnNotify)( cl_program program, void *pvUserData),

void *pvUserData);

7) Функция «Создание ядра»

cl_kernel clCreateKernel(

cl_program program,

const char *pcszKernelName,

cl_int *pnErrCodeRet);

8) Функция «Создание буфера»

cl_mem clCreateBuffer(

cl_context context,

cl_mem_flags nFlags,

size_t uSize,

void *pvHostPtr,

cl_int *pnErrCodeRet);

nFlags	Описание
CL_MEM_READ_WRITE	чтение/запись;
CL_MEM_WRITE_ONLY	только запись;
CL_MEM_USE_HOST_PTR	использовать pvHostPtr;
CL_MEM_ALLOC_HOST_PTR	выделять память управляющего узла;
CL_MEM_COPY_HOST_PTR	копировать память управляющего узла.

9) Функция «Задание аргументов ядра»

cl_int clSetKernelArg(

cl_kernel kernel

cl_uint uArgIndex,

size_t uArgSize,

const void *pcvArgValue );

10) Функция «Исполнение ядра»

cl_int clEnqueueNDRangeKernel(

cl_command_queue command_queue,

cl_kernel kernel,

cl_uint uWorkDim,

const size_t *pcuGlobalWorkOffset,

const size_t *pcuGlobalWorkSize,

const size_t *pcuLocalWorkSize,

cl_uint uNumEventsInWaitList,

const cl_event *pEventWaitList,

cl_event *pEvent);

11) Функция «Отображение буфера в память управляющего узла»

void *clEnqueueMapBuffer(

cl_command_queue command_queue,

cl_mem buffer,

cl_bool bBlockingMap,

cl_map_flags nMapFlags,

size_t uOffset,

size_t uBytes,

cl_uint uNumEventsInWaitList,

const cl_event *pEventWaitList,

cl_event *pEvent,

cl_int *pnErrCodeRet);

nMapFlags	Описание
CL_MAP_READ	Чтение
CL_MAP_WRITE	Запись

12) Функция «Завершение отображения буфера»

cl_int clEnqueueUnmapMemObject(

cl_command_queue command_queue,

cl_mem memobj,

void *pvMappedPtr,

cl_uint uNumEventsInWaitList,

const cl_event *pEventWaitList,

cl_event *pEvent);

13) Функция «Удаление объекта и освобождение памяти управляющего узла»

clRelease* ( имя_объекта );

14) Функция «Завершение работы устройства»

clFinish ( имя_объекта );



Заключение

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

Так или иначе, видеокарты хорошо зарекомендовали себя в параллельных вычислениях. Они дают высокий прирост производительности при относительно малом потреблении электроэнергии.



Список использованных источников

1. MikeHouston. General Purpose Computation on Graphics Processors.

2. David Luebke. General-Purpose Computation on Graphics Hardware. University of Virginia.

3. Кривов М.А. «Оптимизация приложений для гетерогенных архитектур. Проблемы и варианты решения».

4. Модели параллельных вычислений [Электронный ресурс] // Сайт дистанционного образования института ИКИТ. - Режим доступа: http://distant.ikit.sfu-kras.ru/course/view.php?id=33

5. Казённов А.М. «ОСНОВЫ ТЕХНОЛОГИИ CUDA И OpenCL».

6. Лыков К.О. «Библиотека для работы с конечными множествами, использующая графический процессор в качестве основного вычислительного устройства».

7. Всё о суперкомпьютерах [Электронный ресурс] // Блог о суперкомпьютерах. - Режим доступа: http://www.parallelcomputing.ru/?p=722

8. О проекте OpenCL [Электронный ресурс] // Официальный сайт OpenCL. - Режим доступа: http://opencl.ru/about

9. Лыков К.О. «Технология вычислений общего назначения на графическом ускорителе».

10. OpenCL 1.0 Reference Pages [Электронный ресурс] // Официальный сайт комитета Khronos. - Режим доступа: https://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/

11. Калгин К.В. «Эффективное программирование графических ускорителей».

Размещено на Allbest.ru

...