Графічний API низькорівневої платформи

11

При створенні системної абстракції краще мати на платформі різні API, приховані загальним інтерфейсом на найнижчому рівні, що має сенс.

Враховуючи різні сучасні (без фіксованої функції конвеєра) вітчизняні графічні API: OpenGLES 2.0+, OpengGL 3.0+, DirectX 10.0+, Xbox DirectX 9, LibGCM

Якби створити графічний API з низьким рівнем без громадянства, щоб сидіти над ними, який би кращий спосіб зробити, щоб зробити його максимально тонким та швидким?

— NocturnDragon
джерело

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

— SpoonMeiser

Уникнення непотрібних змін стану все ще може бути здійснено на більш високому рівні, наприклад, шляхом сортування дзвінків виклику відповідно до їх стану перед тим, як подавати їх на пристрій. І встановивши стан, лише якщо він відрізняється від поточного.

— NocturnDragon

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

— SpoonMeiser

Так, для кожного дзвінка, який вам потрібен, даних сітки, стану змішування, текстур для зв’язування, станів вибірки тощо. Оптимізації можна зробити пізніше, не змінюючи API tho. А може, я неправильно читаю ваш коментар ..

— NocturnDragon

6

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

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

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

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

Таким чином, ви створите дві речі: Менеджер апаратних ресурсів, а також інструментарій для встановлення DAG цих ресурсів.

— Рейчел Блюм
джерело

Я ніколи не замислювався над тим, щоб розглядати конкретні платформи як ресурси. Це звучить як дуже гарна ідея! Дякую.

— NocturnDragon

10

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

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

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

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

— Джейсон Козак
джерело

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

— NocturnDragon

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

— Джейсон Козак

1

Для початку кожен API робить все по-різному, тому не слід говорити про те, що обгортання всіх вищевказаних API буде складно. Однак, іноді це потрібно зробити: в якийсь момент гру просто потрібно запустити на більш ніж одній платформі, незалежно від того, наскільки важко це зробити.

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

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

— Шон Джеймс
джерело

0

Про це є стаття про GPU Pro від Еміля Перссона (Humus)

http://gpupro.blogspot.com/2009/12/making-it-large-beautiful-fast-and.html

Міжплатформенний інтерфейс для візуалізації. Переваги наявності одного, а також те, як ми втілили DX10 у загальний інтерфейс з консолями DX9 та підтримували хороші показники.

— NocturnDragon
джерело

-4

Ви можете перевірити бібліотеку SDL або Allegro . Обидві вони є низькорівневими, високо портативними ігровими бібліотеками, які мають змогу підключити їх до OpenGL-контексту, щоб ви могли візуалізувати там свою графіку. SDL має славу того, що він використовує програму Loki Games для передачі популярних ігор від 2000-х до Linux, а Allegro працює багато часу і має велике співтовариство розробників аматорських ігор.

— chiguire
джерело

4

Це насправді не відповідає на питання, не кажучи вже про те, що обробляти OpenGL і DirectX дуже можливо (див. Ogre3D, Irrlicht тощо).

— Джейсон Козак

Розгляньте ігри, в які ви грали. Скільки з них мають варіанти використання DirectX або OpenGL? Ось скільки створюють обгортки для двох бібліотек, щоб мати можливість підтримувати будь-яку. У вас обмежена фантазія. :-P

— Рікет

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

— chiguire

1

питання стосується міжплатформного API низького рівня без громадянства. SDL та Allegro не мають нічого спільного.

— NocturnDragon

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

— a_m0d