GPGPU *

Недавно я опубликовал статью о распределенном рендеринге на GPU — поступили некоторые вопросы и предложения. Поэтому считаю нужным рассказать о теме более развернуто (и с картинками, а то без картинок статьи практически не читают), тем самым привлечь к этой теме больше читателей.
Думаю, этим вопросом заинтересуются обладатели мощных вычислительных систем: майнеры, геймеры, админы других мощных вычислительных систем.

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


Красота моя бестоковая!

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

Но, наряду с хранением информации, будет не менее полезным для нас сервис облачно-распределенных вычислений, и в частности, рендеринга.

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

Итак, что такое «рендеринг»? Рендеринг — это вычислительный процесс, в ходе которого, мы получаем красивую картинку по 3д модели с помощью программы «рендера».
Что такое «распределенный»? Это когда хранение или вычисление данных распределяют между множеством компьютеров или серверов, объединенными одной сетью (см. распределенные вычисления).
Распределенный рендеринг — вычислительный процесс, по созданию изображений, распределенный между компьютерами. Вычисления также могут на себя брать облака.

Всем доброго дня,

Надеюсь, при прочтении этого блока в своём ридере, моя картинка вас не напугала. Но сегодня, я хочу описать применение взаимодействия технологии CUDA с OpenGL на примере моего небольшого pet-примера, первую версию которого я описывал в статье ранее. Тех, кому интересен раздел, известный под английским названием CUDA and OpenGL interoperability,

Данная статья написана с целью продемонстрировать как с помощью технологии CUDA можно смоделировать простое взаимодействие заряженых частиц (см. Закон Кулона). Для вывода статической картинки я использовал библиотеку freeglut.
Как пишут частенько на Хабре:

Здравствуй, Хабр!

Несколько лет назад в прикладных целях я реализовал обычный Force-based визуализатор графов.

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

Со временем возникло несколько идей, что интересного можно смоделировать.

Вот что получилось с одной из них (в кадре мелкие объекты, смотреть в HD):

Как создать рендерер, который бы работал даже на компьютере вашей бабушки? Изначально перед нами стояла немного другая задача — создать unbiased рендер для всех моделей GPU: NVidia, ATI, Intel.
Хотя идея такого рендера для всех видеокарт витала в воздухе давно, до качественной реализации, тем более на Direct3D, дело не доходило. В своей работе мы пришли к весьма дикой связке и дальше расскажем, что нас к ней привело и как она работает.

При использовании средств параллельных вычислений весьма вероятно может сложиться ситуация, когда алгоритм содержит два таких последовательных этапа: i) каждый j-ый поток сохраняет некоторый промежуточный результат вычисления в j-ой ячейке памяти, а, затем, ii) этот поток должен использовать результаты одного или более «соседних» потоков. Очевидно, что необходимо организовать в коде программы некий барьер по времени, который каждым потоком преодолевается уже после того, как все сохранят свои промежуточные результаты в соответствующих ячейках памяти (этап (i)). В противном случае, какой-то поток может перейти к этапу (ii), пока какие-то другие потоки еще не завершили этап (i). Как это ни прискорбно, но создатели CUDA посчитали, что такой специальный встроенный механизм синхронизации любого числа потоков на одном GPU не нужен. Так как же можно бороться с этой напастью? Хотя Google, судя по подсказкам, и знаком с данным вопросом, но готового удовлетворительного рецепта под свою задачу найти не удалось, а на пути к достижению желаемого результата для новичка (которым я и являюсь) имеются некоторые подводные камни.

Вступление

Недавно, почитав различных статей и презентаций про GPGPU, я решил тоже попробовать для себя программирование под видеокарты. Фактически, выбор технологий в этой области не велик — сейчас живы и развиваются только CUDA (проприетарный стандарт nVidia) и OpenCL (свободный стандарт, работает на GPU от ATI, nVidia, а также на центральных процессорах). В связи с тем, что мой ноутбук располагает видеокартой ATI (Mobility Radeon 5650 HD), то выбор и вовсе свёлся к одному варианту — OpenCL. В этой статье речь пойдёт о процессе изучения OpenCL с нуля, а также о том, что из этого получилось.

На Github выложен исходный код компилятора Rootbeer, с помощью которого можно почти любой Java-код запустить на графическом процессоре, а также легко разделить Java-программу на фрагменты для CPU/GPU.

Компилятор опубликован под лицензией MIT, он прошёл тщательное тестирование и вполне пригоден для использования. По словам автора, это самый продвинутый транслятор байткода Java на платформу CUDA. Судя по всему, OpenCL тоже поддерживается.

Автор программы — преподаватель Сиракузского университета Фил Пратт-Желига (Phil Pratt-Szeliga).

В последнее время параллельные вычисления прочно входят в жизнь, в частности, с использованием GPU.

Здесь было много статей на эту тему, поэтому ограничусь лишь поверхностным описанием технологии. GPGPU — использование графических процессоров для задач общего назначения, т.е. не связанных напрямую с рендерингом. Пример — библиотека Nvidia PhysX для расчёта физики в некоторых современных играх. Эта технология выгодна тем, что GPU хороши на параллельном выполнении с множеством потоков. Правда, потоков должно быть много, иначе производительность сильно упадет. Ещё из-за особенностей работы с памятью приходится несколько хитрить с передачей данных из оперативной памяти в видеопамять. Известные реализации: CUDA (Nvidia, только для видеокарт), OpenCL (Khronos Group, для гетерогенных систем) и AMD FireStream. Здесь будет обсуждаться только OpenCL.

Итак, приступим к практике. В качестве языка основной программы выберем Python. Он, конечно, не очень быстр сам по себе, зато отлично работает как «клей» — во многих применениях основной расчёт идёт в OpenCL, а код на Python только «подносит патроны». Существует отличная библиотека PyOpenCL, которой и будем пользоваться.

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

Всем привет!
В начале апреля я увидел анонс новой видеокарты от nVidia, с новым мажорным индексом compute capability – 3.0. Внимательно изучив спеки был удивлён – по всему выходило, что теперь ветвления будут приводить к самым худшим последствиям: большим потерям производительности. Мне нравилось, что от версии к версии ветвления играют всё меньшую роль, а Kepler показался в этом плане шагом назад. Мозгом я понимал, что такое вряд ли возможно и решил немного выждать.
И вот на этой неделе мне пришёл whitepaper по новой числодробилке на архитектуре Kepler и многое прояснил.

Краткое содержание: Создан быстрый кодер FVJPEG для сжатия изображений по алгоритму JPEG на видеокартах NVIDIA. Значительное ускорение получено при распараллеливании алгоритма, его реализации и оптимизации с помощью технологии CUDA. По скорости сжатия кодер FVJPEG превосходит все существующие в настоящее время программные и аппаратные решения для компрессии изображений по алгоритму Baseline JPEG.

Рассмотрим следующую ситуацию: есть приложение, которое использует AMD GPU для своих вычислений. Как правило, на GPU выносятся самые ресурсоемкие операции. Поэтому если приложение работает быстрее своих конкурентов, то может возникнуть желание узнать, какой же алгоритм реализован в этой программе. Но что делать, если программа является проприетарной и распространяется по лицензии, запрещающей reverse engineering и дизассемблирование?

Чтобы не нарушать лицензии, можно воспользоваться одной маленькой хитростью, оставленной разработчиками AMD APP SDK. Однако чтобы эта хитрость сработала, необходимо выполнение еще одного условия (помимо использования разработчиками приложения указанного SDK): приложение должно использовать OpenCL для вычислений на GPU.

В первой части я рассказал о технологии AMD Intermediate Language (IL). В этой статье, как можно догадаться из заголовка, речь пойдет о второй составляющей: AMD Compute Abstraction Layer (CAL). Эти две технологии являются нераздельными друг от друга: невозможно использовать одну, не используя другую. Поэтому для понимания дальнейшего рекомендую ознакомиться с первой частью.

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

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 на базе LLVM. Сорцы не раздаются направо и налево, а доступны только для «квалифицированных исследователей и разработчиков». Для их получения нужно зарегистрироваться, заполнить форму и указать, для каких проектов вы намерены применять компилятор. Так что пока непонятно, под какой лицензией опубликован компилятор и вообще — свободная ли это лицензия. В пресс-релизе компания намекает на более открытый доступ к исходникам в будущем.



С помощью компилятора и нового CUDA Toolkit 4.1 можно будет приспособить платформу GPGPU для других архитектур и процессоров, в том числе AMD GPU и x86 CPU, а также создавать гетерогенные суперкомпьютерные системы.

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

Реальное доказательство того, что GPU может осуществлять сортировку данных (алгоритм radix) в несколько раз быстрее, чем CPU.

Дуэйн Мэррилл (Duane Merrill) и Эндрю Гримшоу (Andrew Grimshaw) с кафедры вычислительной техники Виргинского университета в Шарлотсвилле опубликовали под свободной лицензией свой метод сортировки SRTS Radix Sort, в котором GTX 480 показывает скорость сортировки более 1 млрд 32-битных ключей в секунду: примерно вчетверо быстрее, чем на процессоре Core i7.

Метод подходит для любых CUDA-устройств. Текущая версия поддерживает сортировку любых встроенных числовых типов данных C/C++ (например, signed char, float, unsigned long long), а также автоматическую оптимизацию в случаях, если все ключи имеют одинаковую длину (ускорение сортировки в пять раз).

Разделяемая (shared) память является очень эффективным средством оптимизации за счет очень быстрого доступа (в 100 раз быстрее чем глобальная память). Однако, при неправильном использовании ее возможны конфликты банков, которые существенно замедляют быстродействие. В данной статье пойдет речь о том, как эти конфликты возникают, и как их избежать.