Текуща практика за внедряване на GPU код за семейство графични процесори

Ситуацията е следната; набор от изчисления (написани на C++), които биха били направени най-добре, като се използва какъвто и GPU да е наличен в системата на потребителя или неговия CPU, ако такъв GPU не съществува, където тази потребителска система не е машината за изграждане и ще бъде от неизвестен (но доста стандартна десктоп) конфигурация.

Понастоящем мога да пиша код с помощта на Thrust, но (освен ако не съм разбрал погрешно) в момента на действителното му изграждане, целта е зададена (най-общо казано, Nvidia или само CPU) и двоичният файл ще използва само GPU хардуер на машината на потребителя ( възможно дори няма да работи иначе), ако е от същата фамилия GPU, за която е създаден двоичният файл.

Това, което бих искал в един вълшебен идеален свят, е двоичен файл, който ще идентифицира какво (ако има такова) семейство GPU (Nvidia, ATI, резервен към обикновен CPU) е налично на машината, на която работи, и ще го използва. Необходимостта да се изградят три отделни версии и да се уверите, че всеки потребител получава правилната за своята конкретна машина, не е начинаещ (целите са доста стандартни настолни компютри; Windows, Linux и Solaris - нека оставим това настрана, тъй като има различна компилация за всяка от тези три е напълно приемлива; целта е да има двоичен файл за всяка от тези три цели, който идентифицира и използва наличния графичен процесор сам по себе си, независимо дали е Nvidia, ATI или просто CPU).

Въвеждам някои обнадеждаващи термини в Google, но все още не намерих нищо, което да се отнася до това; доколкото знам, това е напълно решен проблем и просто не съм написал правилните думи.

Може ли някой да ми каже какъв (ако има такъв) е стандартният начин да направя това?

Редакции: премахната е лошата информация за тягата, добавена е бележка за крайния целеви хардуер


person Moschops    schedule 19.07.2015    source източник
comment
За ATI няма такова нещо като тяга. Това е библиотека с шаблони само за CUDA. На платформите на NVIDIA можете да създавате за колкото искате CUDA архитектури, а изборът на GPU архитектура е автоматичен, не е необходимо да правите нищо   -  person talonmies    schedule 19.07.2015
comment
това, въпросите, които nvidia-nsight задава, са за проекти, които използват функциите на cuda директно   -  person Behrooz    schedule 19.07.2015
comment
Това наистина е въпрос за препоръчване на ресурс извън сайта (език/среда за програмиране на GPU).   -  person Puppy    schedule 19.07.2015
comment
Това наистина е въпрос относно препоръчването на ресурс извън сайта, Боже, нали? Мислех, че това е въпрос за това каква е текущата най-добра практика. Мога сам да намеря купища ресурси извън сайта за програмиране на GPU. Това, което не мога да намеря, е как други хора се справят с необходимостта от насочване към множество системи за крайни потребители.   -  person Moschops    schedule 19.07.2015


Отговори (2)


Мисля, че си струва да опитате: Зареждане на споделена библиотека по път по време на изпълнениеЗа да работи, трябва да разделите приложението си на фронтенд и бекенд части. компилирайте бекенда за всяко семейство и накарайте интерфейса да зареди правилния бекенд по време на изпълнение.

person Behrooz    schedule 19.07.2015

AFAIK, единственият стандарт, работещ на AMD/ATI и Nvidia GPGPU, е OpenCL. CUDA е собствена технология на Nvidia. Разбира се, изисква внедряване на OpenCL, за да бъде налично (и да си струва използването).

Може да се интересувате от PIPS4U, OpenACC, OpenMP или дори MPI и т.н. Погледнете и към многонишкови, напр. с C++11 поддръжка на нишка.

Забележете, че някои компютри (напр. много сървъри) нямат GPGPU. Други може да имат GPGPU, който е по-бавен от техния процесор, така че не си струва да се използва за изчислителни задачи. Някои AMD чипове имат APU. Други имат HSA. Хетерогенното изчисление чрез GPGPU е не добре стандартизирано.

Имайте предвид, че софтуерът GPGPU трябва да бъде настроен (или конфигуриран) за конкретния хардуер, на който работи... Ето защо е трудно да се кодира ефективен OpenCL (или Cuda) софтуер.

BTW, може да има някаква странна конфигурация. Представете си система с процесор с вграден графичен процесор (напр. Intel i4770K, Intel i5775C), един висок клас AMD GPGPU и графична карта и друг висок клас NVIDIA GPGPU и графична карта.... Може да искате да стартирате OpenCL и на трите...

Бихте могли да обмислите някаква архитектура на плъгин (напр. използване на dlopen & dlsym от POSIX). Бихте могли да помислите за някаква C++ рамка (Qt, POCO), предоставящ интерфейси към плъгини по независим от операционната система начин.

Но има няма сребърен куршум ; може би добър подход би бил да се дефинира и публично документира архитектура на плъгин (напр. правила за именуване и извикване на плъгин), след което да се публикува като безплатен софтуер, няколко реализации (над OpenCL, Cuda, OpenACC, OpenMP, MPI, ....) на подобни плъгини, които се вписват в тази архитектура. Внимавайте за объркани имена, така че декларирайте като extern "C" публичните функции на вашите добавки. Може да смесите това с някакъв подход за метапрограмиране, като вашето приложение генерира C++ (и/или OpenCL и т.н. ..) код по време на изпълнение, след което се компилира и зарежда като плъгин (на машината на потребителя).

person Basile Starynkevitch    schedule 19.07.2015
comment
Разбира се, но OpenCL задава ли целевия хардуер по време на компилиране или по време на изпълнение? От това, което прочетох, мисля, че може да го направи по време на изпълнение, със специфичен за системата набор от OpenCL библиотеки, които потребителят ще трябва да е инсталирал. - person Moschops; 19.07.2015
comment
Това е хардуерен агностик. Работи, докато драйверът поддържа OpenCL - person Behrooz; 19.07.2015
comment
Не е отговор. OpenCL няма да работи, ако машината няма инсталирана OpenCL реализация, което е нормално за доста стандартна конфигурация. - person stgatilov; 19.07.2015
comment
@Moschops OpenCL не настройва нищо, получавате списък с устройства и изпращате команди до които искате. - person RamblingMad; 19.07.2015
comment
@stgatilov Със сигурност е вярно, че идеалното би било за доста стандартна конфигурация, но при липса на по-добър отговор, засега ще взема OpenCL, но трябва да разпространите някои OpenCL библиотеки, които потребителите ще трябва да инсталират на своята конкретна машина ако това е най-доброто, което можем да направим днес. - person Moschops; 19.07.2015
comment
@stgatilov не е по-различно от зависимостта от библиотека на трета страна. - person RamblingMad; 19.07.2015
comment
AFAIK Всички nvidia, intel и amd доставят opencl библиотеки със своите графични драйвери. на linux можете да ги инсталирате отделно. - person Behrooz; 19.07.2015