Чи дійсно мені потрібно використовувати графічний API?

Чи потрібно використовувати графічні API, щоб отримати апаратне прискорення в 3D-грі? Наскільки можливо звільнитись від API графічних карт, таких як OpenGL, DirectX , CUDA, OpenCL чи ще?

Чи можу я створити власний графічний API чи бібліотеку для своєї гри? Навіть якщо це важко, чи теоретично можливо, щоб мій 3D-додаток самостійно зв’язався з графічним драйвером і передавав усе на GPU?

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

Windows, Linux, OSX тощо забороняють прямий доступ до апаратних засобів до довільних програм. Це важливо з міркувань безпеки: ви не хочете, щоб будь-яка випадкова програма могла читати довільну пам'ять GPU з тієї ж причини, якщо ви не хочете, щоб будь-яка випадкова програма могла читати системну пам'ять. Такі речі, як фреймбуфер для вашого банківського рахунку або що-небудь ще не зберігається в пам'яті GPU. Ви хочете, щоб ці речі були ізольованими та захищеними та доступом контролюється ваша ОС.

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

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

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

Єдиною реалістичною альтернативою є те, що ви не використовуєте 3D-прискорення, а замість цього перейдіть до візуалізації програмного забезпечення, яке, за умови, що воно написане на чомусь справді портативному, наприклад, C, зможе працювати на будь-якій системі / пристрої. Це чудово для менших ігор ... щось на зразок SDL підходить для цієї мети ... є й інші. Але для цього не вистачає властивих 3D-можливостей, тож вам доведеться будувати їх самостійно ... що не є тривіальним завданням.

Також пам’ятайте, що візуалізація процесора неефективна і має низьку ефективність порівняно з GPU.

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

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

Завантажте комп'ютер у MS-DOS. Потім, використовуючи свою копію Енциклопедії програмістів ПК для ігор , ви можете записувати безпосередньо в регістри VESA карти та у відеопам'ять. У мене ще є код, який я написав 20 років тому, щоб зробити це і зробити рудиментарний 3D в програмному забезпеченні.

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

Існує також екстремальний підхід до створення власного відео обладнання .

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

Однак це не означає, що ви повинні бути на 100% залежними від одного конкретного API. Ви завжди можете кодувати свій власний шар абстракції, а потім поміняти місцями і вимкнути більш конкретні реалізації (наприклад, реалізація DirectX, реалізація OpenGL, ...).

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

Підсумовуючи: Теоретично можна, але це неможливо, і ви не отримаєте жодної переваги. API обмежень сьогодні з кожним днем ​​стає менше, у вас є CUDA та OpenCL та шейдери. Тож повний контроль більше не є проблемою.

Повніше пояснення:

Відповідь на це - нудне так . Справжнє питання - чому ?

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

За допомогою графічних процесорів ви отримуєте «кращу» продуктивність, але втрачаєте багато свободи. Графічні розробники наполягають на тому, щоб повернути цю свободу. Отже, більше налаштування трубопроводів щодня. Ви можете робити майже все, використовуючи CUDA / OpenCL та навіть шейдери, не торкаючись драйверів.

Ви хочете поговорити з обладнанням. Потрібно скористатися способом спілкування з обладнанням. Таким чином є інтерфейс до обладнання. Ось що таке OpenGL, DirectX, CUDA, OpenCL та всі інші.

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

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

Щодо картки NVIDIA, вам слід ознайомитись із проектом модерну з відкритим кодом . У них є колекція великих ресурсів тут .

Для інших марок відеокарт ви можете знайти подібні проекти та документацію.

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

Позбавлення DirectX або OpenGl не призведе до усунення залежностей, воно ввело б їх більше. Інші відповіді вже містять кілька хороших моментів, чому, можливо, навіть неможливо безпосередньо поговорити з графічним обладнанням (принаймні, це неможливо), але моя перша відповідь була б: якщо ви насправді написати бібліотеку, яка резюмує всі загальні 3d графічні програмні засоби в єдиний API, які ви ефективно переписали б DirectX / OpenGl. Якби ви використовували свій код для написання гри, ви додали б свою нову бібліотеку як нову залежність, як і тепер у вас залежність DirectX / OpenGl.

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

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

Перш за все, CUDA та OpenCL - це не графічний апарат. Вони є обчислювальної апісом.

Проблема з написанням власної графічної api полягає в тому, що вона дуже складна. Ви можете безпосередньо взаємодіяти з обладнанням, але немає гарантії, що якщо він працює в системі з X CPU, X GPU, X кількістю оперативної та операційної системи X, він буде працювати в системі з процесором Y, Y GPU і т.д. Хорошим моментом є те, що DirectX працює з драйверами в режимі ядра. Вона вкорінена в ядро. Також графічний apis не побудований для підтримки графічних процесорів. Графічні процесори (та їх драйвери) створені для їх підтримки. Таким чином, ви майже не можете створити графічний api, якщо ви не створите власну ОС і не використовуєте x86 за умови переривання VGA. Але ви все одно не зможете належним чином взаємодіяти з графічним процесором, і ви застрягли б при низькій роздільній здатності.

Я розумію, що ви хочете все створити самостійно, а не використовувати двигун чи щось подібне. Але створення власної графічної api просто створить незручності для користувача.

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

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