OpenGL проти OpenCL, який вибрати і чому?

Які особливості роблять OpenCL унікальним для вибору серед OpenGL із GLSL для розрахунків? Незважаючи на графічну термінологію та непрактичні типи даних, чи існує реальне застереження до OpenGL?

Наприклад, паралельна оцінка функції може бути виконана шляхом надання а текстурі за допомогою інших текстур. Зменшувальні операції можна виконати шляхом ітераційного відтворення до дедалі менших текстур. З іншого боку, випадковий доступ до запису неможливий будь-яким ефективним способом (єдиний спосіб зробити це рендерінг трикутників за допомогою текстурованих вершинних даних). Чи можливо це з OpenCL? Що ще можливо, неможливо з OpenGL?

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

У OpenCL ви просто формулюєте свої обчислення за допомогою ядра обчислення в буфері пам'яті, і все готово. Це насправді ВЕЛИКИЙ виграш (кажучи, що з точки зору продумування та реалізації обох варіантів).

Шаблони доступу до пам'яті однакові (ваш розрахунок все ще відбувається на графічному процесорі, але графічні процесори стають все більш гнучкими в наші дні).

Але що ще ви очікуєте, ніж використання більше десятка паралельних "процесорів", не розбиваючи голови про те, як перекладати - наприклад (дурний приклад) Фур'є до трикутників і квадратиків ...?

Щось, про що досі не згадувалося в жодних відповідях, це швидкість виконання. Якщо ваш алгоритм може бути виражений графікою OpenGL (наприклад, відсутність розсіяних записів, відсутність локальної пам'яті, робочих груп тощо), він дуже часто буде працювати швидше, ніж аналог OpenCL. Мій конкретний досвід у цій роботі полягає у фільтруванні (збиранні) ядер у графічних процесорах AMD, nVidia, IMG та Qualcomm. Реалізації OpenGL незмінно працюють швидше навіть після жорсткої оптимізації ядра OpenCL. (крім: я підозрюю, що це пов’язано з роками роботи апаратного забезпечення та драйверів, спеціально налаштованих на графічне навантаження.)

Моя порада буде те , що якщо ваша програма обчислень відчуває , як він відображає красиво графіки домен потім використовувати OpenGL. Якщо ні, OpenCL є більш загальним і простішим для вираження обчислювальних проблем.

Ще один момент, про який слід згадати (або запитати) - чи пишете ви як любитель (тобто для себе) чи комерційно (тобто для розповсюдження серед інших). Хоча OpenGL підтримується майже скрізь, OpenCL повністю не має підтримки на мобільних пристроях, і, на жаль, навряд чи він з'явиться на Android або iOS протягом найближчих кількох років. Якщо метою є широка сумісність між платформами з однієї бази коду, то OpenGL може бути нав'язаний вам.

Які особливості роблять OpenCL унікальним для вибору серед OpenGL із GLSL для розрахунків? Незважаючи на графічну термінологію та непрактичні типи даних, чи існує реальне застереження до OpenGL?

Так: це графічний API. Тому все, що ви робите в ньому, має бути сформульовано відповідно до цих термінів. Ви повинні упакувати свої дані як певну форму "візуалізації". Ви повинні зрозуміти, як поводитися з вашими даними з точки зору атрибутів, єдиних буферів та текстур.

З обчислювальними шейдерами OpenGL 4.3 та OpenGL ES 3.1 все стає дещо заплутанішим. Шейдер обчислень може отримувати доступ до пам'яті через SSBOs / Image Load / Store аналогічно обчислювальним операціям OpenCL (хоча OpenCL пропонує фактичні вказівники, тоді як GLSL цього не робить). Їх взаємодія з OpenGL також набагато швидша, ніж взаємодія OpenCL / GL.

Незважаючи на це, обчислювальні шейдери не змінюють одного факту: обчислювальні операції OpenCL працюють з абсолютно різною точністю, ніж обчислювальні шейдери OpenGL. Вимоги до точності з плаваючою комою GLSL не дуже жорсткі, а OpenGL ES ще менш жорсткі. Отже, якщо точність з плаваючою точкою є важливою для ваших розрахунків, OpenGL не буде найефективнішим способом обчислення того, що вам потрібно обчислити.

Крім того, для обчислювальних шейдерів OpenGL потрібно апаратне забезпечення, що підтримує 4.x, тоді як OpenCL може працювати на значно гіршому апаратному забезпеченні.

Крім того, якщо ви обчислюєте, вибравши конвеєр візуалізації, драйвери OpenGL все одно вважатимуть, що ви робите рендеринг. Тож він буде приймати рішення щодо оптимізації, виходячи з цього припущення. Це дозволить оптимізувати призначення ресурсів шейдерів, якщо припустити, що ви малюєте картину.

Наприклад, якщо ви здійснюєте візуалізацію до буфера з плаваючою крапкою, драйвер може просто вирішити надати вам буфер кадрів R11_G11_B10, оскільки він виявляє, що ви нічого не робите з альфою, і ваш алгоритм може переносити нижчу точність. Якщо ви використовуєте завантаження / зберігання зображень замість буфера кадрів, ви набагато рідше отримаєте цей ефект.

OpenCL не є графічним API; це обчислювальний API.

Крім того, OpenCL просто надає вам доступ до більшої кількості матеріалів. Це дає вам доступ до рівнів пам'яті, які неявно стосуються GL. Певна пам'ять може бути спільно використана між потоками, але окремі екземпляри шейдерів у GL не можуть впливати безпосередньо один на одного (поза Image Load / Store, але OpenCL працює на обладнанні, яке не має до нього доступу).

OpenGL приховує те, що робить обладнання, за абстракцією. OpenCL піддає вас майже точно тому, що відбувається.

Ви можете використовувати OpenGL для довільних обчислень. Але ти не хочеш ; не поки є цілком життєздатна альтернатива. Обчислення в OpenGL діє для обслуговування графічного конвеєру.

Тільки причина , щоб вибрати OpenGL для будь-якого виду НЕ-рендеринга операції обчислювальному є підтримка апаратних засобів , які не можуть працювати OpenCL. В даний час сюди входить багато мобільного обладнання.

Однією помітною особливістю буде розсіяність записів, іншою - відсутність "розумності Windows 7". Як ви, мабуть, знаєте, Windows 7 вб'є драйвер дисплея, якщо OpenGL не змине приблизно 2 секунди (не забивайте мені точний час, але я думаю, що це 2 секунди). Це може дратувати, якщо у вас тривала операція.

Крім того, OpenCL, очевидно, працює з набагато більшим розмаїттям апаратних засобів, ніж просто графічна карта, і він не має жорсткого графічно-орієнтованого конвеєру зі "штучними обмеженнями". Також простіше (тривіально) запустити кілька паралельних потоків команд.

Хоча в даний час OpenGL буде кращим вибором для графіки, це не постійно.

Для OpenGL може бути практичним з часом об’єднатись як розширення OpenCL. Ці дві платформи приблизно на 80% однакові, але мають різні синтаксичні хитрощі, різну номенклатуру приблизно однакових компонентів обладнання. Це означає дві мови для вивчення, два API для з’ясування. Розробники графічних драйверів воліють об’єднання, оскільки їм більше не доведеться розробляти дві окремі платформи. Це залишає більше часу та ресурсів для налагодження драйверів. ;)

Інша річ, яку слід врахувати, полягає в тому, що походження OpenGL та OpenCL різне: OpenGL почав та набирав обертів у перші дні фіксованого конвеєру над мережею, і повільно додавався та припинявся у міру розвитку технології. OpenCL, в деякому сенсі, це еволюція в OpenGL в тому сенсі , що OpenGL почав використовуватися для цифрової обробки , як (незаплановані) гнучкість графічних процесорів дозволило так. "Графіка проти обчислень" насправді є більше семантичним аргументом. В обох випадках ви завжди намагаєтеся зіставити свої математичні операції з апаратним забезпеченням з максимально можливою продуктивністю. Є частини апаратного забезпечення графічного процесора, які ванільний CL не використовуватиме, але це не буде перешкоджати цьому робити окреме розширення.

То як OpenGL може працювати під CL? Спекулятивно, рослини-трикутники можна поставити в чергу як спеціальне завдання CL. Спеціальні функції GLSL можуть бути реалізовані у ванільному OpenCL, а потім замінені на апаратно прискорені інструкції драйвером під час компіляції ядра. Написання шейдера в OpenCL, очікуючи на розширення бібліотеки, зовсім не звучить болісно.

Називати одного, щоб мати більше функцій, ніж інший, не має особливого сенсу, оскільки вони обидва отримують на 80% однакові функції, просто під різною номенклатурою. Стверджувати, що OpenCL не годиться для графіки, оскільки вона призначена для обчислень, не має сенсу, оскільки обробка графіки - це обчислення.

Інша основна причина полягає в тому, що OpenGL \ GLSL підтримуються лише на відеокартах. Незважаючи на те, що багатоядерне використання почалося з використання графічного обладнання, багато постачальників обладнання працюють на багатоядерній апаратній платформі, націленій на обчислення. Наприклад, див. Intels Knights Corner.

Розробка коду для обчислень за допомогою OpenGL \ GLSL не дозволить вам використовувати будь-яке обладнання, яке не є графічною картою.

Ну а щодо OpenGL 4.5 це ті функції, які OpenCL 2.0 має, що OpenGL 4.5 цього не робить (наскільки я міг сказати) (це не охоплює тих функцій, які OpenGL має, а OpenCL - ні):

Події

Краща атоміка

Блоки

Функції робочої групи: work_group_all та work_group_any work_group_broadcast: work_group_reduce work_group_inclusive / exclusive_scan

Виділити ядро ​​з ядра

Покажчики (хоча, якщо ви виконуєте на графічному процесорі, це, мабуть, не має значення)

Кілька математичних функцій, яких OpenGL не має (хоча їх можна створити самостійно в OpenGL)

Спільна віртуальна пам’ять

(Докладніше) Параметри компілятора для ядер

Легко вибрати певний графічний процесор (або іншим способом)

Може працювати на центральному процесорі, коли немає графічного процесора

Більша підтримка тих нішових апаратних платформ (наприклад, FGPA)

На деяких (усіх?) Платформах для обчислення вам не потрібне вікно (та його прив’язка до контексту).

OpenCL дозволяє трохи більше контролювати точність обчислень (включаючи деякі через ці параметри компілятора).

Багато з перерахованого здебільшого стосується кращої взаємодії процесора та графічного процесора: події, спільна віртуальна пам’ять, покажчики (хоча це може також принести користь іншим речам).

OpenGL отримав можливість сортувати речі за різними областями пам’яті клієнта та сервера, оскільки було зроблено багато інших публікацій. Зараз OpenGL має кращий бар’єр пам’яті та підтримку атомів і дозволяє розподіляти речі між різними регістрами в графічному процесорі (приблизно в однаковій мірі може OpenCL). Наприклад, ви можете спільно використовувати регістри в локальній групі обчислень зараз у OpenGL (використовуючи щось на зразок графічних процесорів AMD LDS (локальний обмін даними) (хоча ця особливість у цей час працює лише з обчислювальними шейдерами OpenGL). деякі платформи (наприклад, драйвери з відкритим кодом Linux). OpenGL має доступ до апаратного забезпечення з більш фіксованою функцією (як сказано в інших відповідях). Хоча це правда, що іноді апаратного забезпечення з фіксованою функцією можна уникнути (наприклад, Crytek використовує "програмне забезпечення" реалізація буфера глибини) апаратне забезпечення з фіксованою функцією може чудово управляти пам'яттю (і, як правило, набагато краще, ніж хтось, хто не працює в апаратній компанії GPU), і в більшості випадків просто значно перевершує. Я повинен визнати, що OpenCL має досить хорошу підтримку текстур фіксованих функцій, що є однією з основних областей фіксованої функції OpenGL.

Я стверджую, що Intels Knights Corner - це графічний процесор x86, який контролює себе. Я також міг би стверджувати, що OpenCL 2.0 з його текстурними функціями (які насправді є в менших версіях OpenCL) можуть бути використані приблизно з тим самим ступенем продуктивності, який пропонував user2746401.

OpenCL (у версії 2.0) описує неоднорідне обчислювальне середовище, де кожен компонент системи може як виробляти, так і споживати завдання, генеровані іншими системними компонентами. Більше не потрібно понять CPU, GPU (тощо) - у вас є лише Host & Device (s).

Навпаки, OpenGL суворо поділяється на процесор, який є виробником завдань та графічним процесором, який є споживачем завдань. Це непогано, оскільки менша гнучкість забезпечує більшу продуктивність. OpenGL - це просто більш вузький інструмент.

На додаток до вже існуючих відповідей, OpenCL / CUDA не тільки більше підходить для обчислювальної області, але і не надто абстрагує базове обладнання. Таким чином, ви можете отримати прямий прибуток від таких речей, як спільна пам'ять або злитий доступ до пам'яті, які в іншому випадку були б використані при реальній реалізації шейдера (що саме по собі є не чим іншим, як спеціальним ядром OpenCL / CUDA, якщо хочете).

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

Після того, як ви зробите щось більш складне, ніж прості підпрограми BLAS рівня 1, ви, безсумнівно, оціните гнучкість та загальність OpenCL / CUDA.

"Особливість", що OpenCL призначена для загальних обчислень, тоді як OpenGL - для графіки. Ви можете робити все, що завгодно в GL (це по Тьюрінгу), але тоді ви забиваєте цвях, використовуючи ручку викрутки як молоток.

Крім того, OpenCL може працювати не тільки на графічних процесорах, але і на центральних процесорах та різних виділених прискорювачах.