Як дізнатися, чи я занадто щільно абстрагуюсь графічні API?

23

Створюючи візуалізатор, який підтримує декілька графічних API, ви, як правило, хочете абстрагувати свій код у якійсь бібліотеці низького рівня, яка пов'язана з деякими графічними API, такими як OpenGL, Vulkan, D3D11 тощо;

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

Як я можу знати, чи я занадто сильно роблю абстракцію?

graphics-programming

— Габріеле Вієрті
джерело

5

Ви на 100% впевнені, що ваша обгортка + Vulkan або D3D11 швидша, ніж завжди, використовуючи OpenGL?

— Mooing Duck

@Mooing Duck при правильному використанні, так.

— Габріеле Вієрті

4

Я б серйозно сумнівався в цьому. Більшість заробітків у Вулкані припадає на те, що він дуже низький і робить справи дуже своєрідним, специфічним чином. Щось достатньо загального для того, щоб зробити те ж саме в OpenGL або D3D, майже напевно не може цього зробити. Повторне виконання тих же речей, що і OpenGL (як і багато підручників Вулкана, як не дивно) призводить до 99,99% тієї ж продуктивності, що в 20 разів перевищує роботу.

— Деймон

@Damon це правильно, але новіші API спеціально розроблені (а не адаптовані як OpenGL) для роботи над сучасними gpus; Якщо говорити про Vulkan, то ви можете в значній мірі використовувати один і той же API на будь-якій підтримуваній платформі, навпаки до OpenGL, де потрібно використовувати версію "Embedded Systems". Крім менших накладних процесорів і фантазійних функцій, у нас не так багато, але в майбутньому ми можемо мати досить дивовижні методи, які можуть працювати швидше, використовуючи Vk або D3D12, а не OGL або D3D11

— Gabriele Vierti

44

Перш за все, подумайте, чи дійсно варто підтримувати більше одного графічного API. Просто використання OpenGL охопить більшість платформ і буде "достатньо хорошим" для всіх, крім найбільш графічно амбітних проектів. Якщо ви не працюєте в дуже великій ігровій студії, яка може дозволити собі занурити кілька тисяч людей-годин на реалізацію та тестування кількох функцій візуалізації, і якщо немає певних функцій DirectX або Vulcan, якими ви дійсно хочете показати себе, зазвичай не варто зайвих клопотів. . Особливо враховуючи, що ви можете заощадити багато роботи, використовуючи шар абстракції, який створив хтось інший (стороння бібліотека або ігровий движок).

Але припустимо, що ви вже оцінили свої варіанти і прийшли до висновку, що це і життєздатно, і варто витратити час на те, щоб зробити свій власний.

Тоді головним суддею програмної архітектури вашого шару абстракції є ваші передні програмісти.

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

Якщо так, то вам це вдалося.

— Філіп
джерело

2

Ще одна пропозиція: чи варто підкреслити, що мета полягає в тому, щоб досягти цілей у кульових точках з мінімальним рівнем зусиль - просто вдарити в ціль і не йти далі? Інакше кожен з них може перетворитися на кролячу нору для типового розробника, який (включаючи і мене) часто не знає, коли залишити достатньо хорошого в спокої. :) А також, що єдиний надійний спосіб судити про успішність - це розробляти та тестувати API ітеративно з фактичними користувачами; точно неможливо здогадатися, і це призводить до сценарію надмірної інженерії кролячої нори.

— боб

5

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

— позов Фонду Моніки

Я не графічний розробник, але дивлячись на рамки сумісності з історії баз даних та ОС, я додам, що це майже точно не варто робити власні загальні рамки. Рамка майже напевно повинна пожертвувати продуктивністю заради сумісності, що, ймовірно, означає, що ви все одно не можете багато зробити з цими спеціалізованими функціями. Існуючі рамки майже впевнені, щоб вирішити ці проблеми краще завдяки більш широкому використанню. Тепер, якщо у вас є великий обсяг бюджету, який ви описуєте, і хочете створити спеціалізовану структуру (скажімо, для однієї гри або серії), це може бути більш доцільним.

— jpmc26

6

Спочатку визначте, що вам потрібно насправді з "обгорткової" частини API. Це, як правило, дуже-дуже просто: вам потрібні основні ресурси (буфери, шейдери, текстури, стан конвеєра) та спосіб використовувати ці ресурси для побудови кадру, подаючи кілька дзвінків на малюнок.

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

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

Регулярно оцінюйте стан свого API. Як правило, вона повинна мати меншу площу поверхні, ніж основні загорнуті API; якщо ви виявите, що створюєте типи обгортки "один на один" для кожної структури D3D або для кожного виклику функції OpenGL, ви, ймовірно, відхиляєтесь від курсу.

Подивіться, яка робота пішла раніше. Sokol і BGFX - це API, які забезпечують рівень агностицизму, який може бути корисним вам і порівняно простий для розуміння (колишній особливо).

— Джош
джерело

3

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

— суперкат
джерело