Реалізація алгоритмів за допомогою обчислювальних шейдерів проти трубопроводів

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

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

Враховуючи алгоритм, який можна реалізувати обома способами, чи існують загальні (потенційні) переваги від продуктивності від використання обчислювальних шейдерів порівняно з проходженням звичайного маршруту? Чи є недоліки, на які слід звернути увагу (наприклад, чи є якісь незвичайні накладні витрати на перехід від / до обчислення шейдерів під час виконання)?

Чи є інші переваги чи недоліки, які слід враховувати при виборі між ними?

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

• Доступ до просторової інформації. у старому злому GLSL (ну це був хак!) дає лише невелику інформацію про фрагменти сусідів, оскільки він використовує текстурні координати. У обчислювальних шейдерах / CUDA / OpenCL доступ до просторової інформації набагато гнучкіший, тепер ви можете реалізувати такі алгоритми, як вирівнювання гістограми на графічному процесорі, з невпорядкованим доступом до текстури / буфера.
• Дає вам нитку синхронізацію та атоміку .
• Обчислювальний простір: старий злом GLSL жорстко передасть вершину / фрагмент для обчислення простору до вашого шейдера. Фрагмент шейдер буде працювати з кількістю фрагментів, вершина шейдер буде працювати з кількістю вершин. У обчислювальному шейдері ви визначаєте власний простір.
• Масштабованість : ваш обчислювальний шейдер / CUDA / OpenCL може масштабувати до кількості доступних SM-карт GPU (Streaming Multiprocessor) на відміну від вашого старого шейдера GLSL, який повинен бути виконаний на одній SM. (На підставі коментарів Натана Ріда, він каже, що це неправда, і шейдери повинні бути настільки ж хорошими, як і обчислювальні шейдери. Я все ще не впевнений, хоча мені потрібно перевірити документацію).
• Контекстна комутація : Має бути певна зміна контексту, але я б сказала, що це залежить від програми, тому найкраще зробити ваш профіль.

На мій погляд , якщо ви хочете пройти маршрут обчислювальних шейдерів, навіть якщо певні алгоритми можуть бути більш підходящими, вам слід врахувати певні міркування:

1. Сумісність апаратного забезпечення та зворотнього зв'язку . Обчислювальні шейдери доступні лише в більш новій техніці, і якщо ви збираєтесь комерційний продукт (наприклад, гра), ви повинні розраховувати, що багато користувачів можуть не мати можливості запустити ваш продукт.
2. Зазвичай вам потрібні додаткові знання в галузі архітектури GPU / CPU , паралельного програмування та багатопотокового редагування (наприклад, обмін пам’яттю, когерентність пам’яті, синхронізація потоків, атомія та це впливає на продуктивність), які зазвичай не потребують використання звичайних шейдерів rounte.
3. Навчальні ресурси , з досвіду є набагато менше навчальних ресурсів для Compute shadrs, OpenCL та CUDA (які також пропонують функціональну сумісність OpenGL), ніж звичайний шейдер.
4. Інструменти для налагодження , за відсутності належної налагодження, розробка інструментів може стати набагато важче, ніж більшість шейдерів, принаймні шейдери можуть бути налагоджені візуально.
5. Я очікую, що обчислювальні шейдери дають кращу продуктивність, ніж той самий алгоритм в інших шейдерах; якщо вони були зроблені правильно з урахуванням речей з пункту 2, оскільки вони були розроблені для уникнення зайвих кроків для візуалізації графіки. Але я не маю жодних конкретних доказів на підтвердження моєї вимоги.
6. Ви також повинні врахувати CUUDA / OpenCL для GPGPU, якщо ви їдете цим маршрутом.

Я не впевнений, що це чудово для майбутнього, і це буде чудовий досвід навчання. Щасти!