Изпълнение на OpenCL на хардуер от смесени доставчици

Играх си с внедряването на ATI OpenCL в техния Stream 2.0 beta. OpenCL в текущата бета версия засега използва само CPU, следващата версия трябва да поддържа GPU ядра. Изтеглих Stream, защото имам ATI GPU в работната си машина.

Пиша софтуер, който ще има огромна полза от печалбите чрез използване на GPU. Въпреки това този софтуер работи на клиентски машини, аз нямам лукса (както имат много научни компютърни среди) да избера точния хардуер, за който да се разработи, и да го оптимизирам за това. Така че въпросът ми е, ако разпространявам реализацията на ATI OpenCL с моето приложение, това ще означава ли, че никога няма да може да използва напр. NVidia видео карти? И ако използвам NVidia OpenCL SDK, че никога няма да работи оптимално на AMD чипове (като се има предвид връзката ATI/AMD)?

С други думи, кой в ​​крайна сметка е отговорен за осигуряването на внедряването на OpenCL? Ще могат ли потребителите напр. инсталират OpenCL „драйвер“ за тяхната видеокарта NVidia, заедно с „драйвер“, който им осигурява оптимална производителност на техния процесор AMD?

Като настрана, има ли добри/активни форуми за поддръжка за OpenCL освен таблата за съобщения на Khronos, или това е мястото, където да отидете? Видях, че ATI има платка, а NVidia вероятно има своя собствена, къде се мотае общността на потребителите/разработчиците на OpenCL? Обединено ли е вече на едно място?


opencl gpgpu
person Roel    schedule 07.09.2009    source източник

Отговори (2)


arrow_upward
6
arrow_downward

В крайна сметка OpenCL ще работи по същия начин като OpenGL. Това означава, че потребителите ще инсталират текущите драйвери от своите производители на хардуер (ATI, NVIDIA, Intel). Вие като разработчик просто ще се свържете с OpenCL библиотека, когато създавате вашите приложения. Когато потребителите стартират вашето приложение, то ще пренасочи към съответните библиотеки, специфични за доставчика, предоставени от драйверите.

Това е начинът, по който ще работи, но все още не работи по този начин.

Друго важно нещо, което трябва да имате предвид, е, че все още вероятно ще трябва да предоставите специфични за доставчика пътища за код, тъй като кодът, изпълняван на CPU с помощта на OpenCL, вероятно ще използва различни оптимизирани параметри на ядрото от кода, изпълняван на GPU. Същото вероятно важи и за разликите между доставчиците на GPU.

person Eric    schedule 07.09.2009
comment
Разликата с OpenGL е, че за OpenGL доставчикът на GPU пише драйверите - точка. OpenGL работи само на видеокартата. Но за OpenCL в идеалния случай доставчикът на CPU пише драйвера за ядрата на CPU, а доставчикът на GPU пише драйверите за ядрата на GPU, тъй като ядрата на OpenCL могат да работят на нишки на CPU или GPU нишки. Така ли трябва да работи в бъдеще? - person Roel; 07.09.2009
comment
OpenGL винаги поддържа софтуерен път, когато хардуерът не поддържа определени операции. Като такива, доставчиците на операционни системи трябва да предоставят софтуерна реализация на OpenGL (MS Windows OpenGL е заседнал на OpenGL 1.1). Нещо подобно вероятно ще се случи с OpenCL. Във всеки случай, AMD/ATI вероятно ще пуснат версия на OpenCL, която ще поддържа както техните процесори, така и техните графични процесори. По същия начин Intel вероятно ще пусне OpenCL, който поддържа обикновените процесори и графичните процесори Larrabee. Не знам достатъчно за внедряването на OpenCL на Apple, за да знам какво поддържа. - person Eric; 07.09.2009
comment
Добре, мога ли да заключа от това, че ако клиентът има видеокарта ATI и процесор Intel, той няма да има оптимална производителност? Че в зависимост от това какъв OpenCL драйвер/имплементация са инсталирали, те ще изпълняват ядра на CPU или GPU? Искам да кажа, че знам, че вероятно ще работи на машината, това не е моя грижа; притеснението ми е дали ще работи бързо (така че използвайки целия хардуер на машината, всички CPU ядра и всички GPU „ядра“). - person Roel; 07.09.2009
comment
Краткият отговор е, че е твърде рано да се каже, особено в сценарии на различни доставчици. Освен това може да има разлика от порядъци между използването на целия хардуер и оптималното използване на целия хардуер. Поддържането на архитектурата на паметта и оптималния размер на работната група и на различните платформи ще бъде от решаващо значение, за да получите максимална производителност от вашето приложение. Дори ако се насочите само към CPU и GPU на AMD, вероятно ще трябва да настроите параметрите на ядрото си за всеки, за да получите най-добрата производителност. - person Eric; 07.09.2009
comment
Освен това мисля, че оптимизирате преждевременно. OpenCL е пътят на бъдещето, ако искате междуплатформени, високопроизводителни изчисления. Съсредоточете се върху изучаването на подробностите сега и оптимизирането за текущата ви платформа. След това по-късно можете да се тревожите за множество доставчици/платформи. - person Eric; 07.09.2009
comment
Е, там не съм съгласен с теб. Ако трябва да изчакам още година или две, преди драйверите да са в Windows (единствената платформа, която ме интересува), и междувременно не мога да разчитам на производителност на всички (или повечето) CPU и GPU, по-добре е да разработя директно за CUDA и казвам на клиентите си, че „ще работи бързо само с карта nVidia“. CUDA е по-зрял от OpenCL, по-добри инструменти, оптимизиран за една хардуерна платформа, единствената причина да изберете OpenCL сега е хардуерната поддръжка на различни производители. Ако това е неуспешно, повечето предимства на OpenCL (за мен) са изчезнали. Както и да е, благодаря за вашите прозрения. - person Roel; 07.09.2009
comment
Мисля, че пропускате идеята, която се опитвам да кажа. Дори когато OpenCL е междуплатформен, пак ще трябва да правите много персонализирани разработки. Най-добре е да започнете тази разработка сега на някаква платформа, на която може да работи оптимално междувременно. Ако все пак изберете CUDA, която е добра платформа, и планирате да преминете към поддръжка на ATI карти по-късно, тогава препоръчвам да използвате ниско ниво, Driver API, тъй като е по-близо до OpenCL API. - person Eric; 08.09.2009
comment
Мисля, че тук спорим за различни случаи. Осъзнавам, че за да получа /оптимална/ производителност от OpenCL, ще трябва да настроя за различни ядра - gpu, cpu, конкретни доставчици, ... Причината първо да обмисля OpenCL (над CUDA или Stream или друг специфичен за доставчика API) е, защото ще ми позволи да напиша паралелен код, който ще работи на всички GPU и всички CPU ядра - т.е. максимален паралелизъм. (Съгласен съм, че по-ранният ми коментар за „оптимално представяне“ беше преувеличено, това, което имах предвид, беше „основен паралелизъм, тъй като това ще даде на моя специфичен случай на употреба значително увеличение на скоростта“). - person Roel; 08.09.2009
comment
(глупаво ограничение от 600 знака) Но ако OpenCL не ми даде дори основен паралелизъм в случаите, когато клиентите имат комбинации gpu/cpu от различни доставчици, тогава може би е по-добре да се откажа от универсален подход и да отида за „един доставчик“ (напр. nvidia) поддръжка. Ако направя това, бих могъл поне наистина да оптимизирам за тази платформа (ако избера OpenCL, няма да пиша персонализирани ядра за всяко GPU поколение - ще трябва да се задоволя с един „достатъчно добър“ подход, поради времето/ бюджетни ограничения). - person Roel; 08.09.2009
comment
В крайна сметка това е проблем с оптимизацията и повечето от променливите дори не мога да измеря (колко от моите клиенти ще имат смесени доставчици CPU/GPU комбинации? Как ще се окаже качеството на внедряване на OpenCL? Колко време бих отделил за оптимизиране на моя код за CUDA чипсети? и т.н.). Просто казвам, че въпросът „OpenCL/CUDA/Поток“ не е ясният избор, който би бил, ако OpenCL в бъдеще можеше да използва оптимално целия хардуер, независимо от доставчика. - person Roel; 08.09.2009
comment
По-добре беше да публикувате отговор, отколкото коментар. - person whatnick; 26.09.2009

arrow_upward
9
arrow_downward

Знам, че това е стар въпрос със стари отговори по-горе. Мислех, че ще го актуализирам с актуален отговор.

Да, една реализация на OpenCL ядра и код ще работи на голямо разнообразие от устройства днес с правилно написана платформа и код за изброяване на устройства. Доста лесно е да напишете правилен код за изброяване на платформа и устройство, сложната част е да изберете коя платформа или устройство. Вероятно трябва да представите опция за конфигуриране в приложението си, където потребителят може да избере една или да изпълни микробенчмарк срещу всеки един и динамично да изберете един и да кешира резултата от теста.

Хората могат и ще имат повече от една платформа. Например моята система има GTX 580 SLI, така че има две устройства в платформата NVidia. Освен това има Intel OpenCL SDK, така че моят процесор CoreI7 990x Extreme също се предлага като устройство в платформата на Intel.

Да, двоичен файл, разработен и изграден с помощта, например, на NVidia OpenCL SDK, ще работи на ATI или Intel OpenCL и обратно. Вече няма нужда да се тревожите за това.

Очевидно е, че крайният потребител може да няма никакъв OpenCL, така че може да се наложи да отложите зареждането или LoadLibrary opencl.dll и динамична връзка.

Горещо препоръчвам да тествате кода си спрямо Intel OpenCL SDK, на NVidia GPU И на AMD GPU. Вероятно ще намерите грешки, които причиняват проблеми на една платформа, но работят добре на други. Вероятно също така ще откриете, че напълно финият код мистериозно не дава правилни резултати на една от тези платформи поради грешки в драйверите.

person doug65536    schedule 10.03.2012
comment
Благодаря за това, писах нов въпрос, за да знам дали нещата са се променили след първия отговор... - person Mikarnage; 10.01.2013