Кроссплатформенный низкоуровневый графический 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-интерфейса. Или, может быть, я неправильно читаю ваш комментарий ..
NocturnDragon

Ответы:

6

Самый низкий уровень, который имеет смысл с моей точки зрения, это то, что говорит о ресурсах, задействованных в рендеринге - vb / ib, рендеринг поверхностей, текстур, шейдеров, блоков состояния и т. Д.

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

Все, что вы затем делаете на более высоком уровне, это настраивает конвейеры с подключенными ресурсами и передает их в графический процессор. Вы обнаружите, что таким образом не все может быть абстрагировано, особенно, если вы используете аппаратные приемы. Но это хорошее начало.

(Замечание: если вы рассматриваете трюки, специфичные для платформы, как особый вид ресурса, вы можете далеко продвинуть эту концепцию.)

Таким образом, в некотором роде вы создадите две вещи: менеджер аппаратных ресурсов и набор инструментов для настройки DAG из этих ресурсов.

Рейчел Блум
источник
Я никогда не думал о том, чтобы относиться к вещам, связанным с платформой, как к ресурсам. Это звучит как очень хорошая идея! Спасибо.
NocturnDragon
10

Учитывая широкий диапазон API-интерфейсов, которые вы хотите охватить, типичный подход обертывания, вероятно, будет неэффективным и сопряжен с трудностями при сопоставлении концепций API с несколькими другими API-интерфейсами, которые могут в той или иной степени поддерживать определенные функции.

В результате самым разумным подходом было бы создание функционально-ориентированного API. Хотя этот подход не позволяет пользователю API использовать все доступные функциональные возможности, он значительно упрощает реализацию каждого бэкэнда и обеспечивает оптимизацию для конкретного бэкэнда, которая иначе была бы невозможна.

Это также значительно упрощает управление неподдерживаемой функциональностью для пользователя API; им больше не нужно проверять, существует ли функция X, и определять, на какие функции это влияет, но вместо этого им нужно только запросить саму функцию, чтобы узнать, поддерживается ли она в текущей конфигурации. Даже если вы поддерживаете частичные или ограниченные режимы для функций, предоставляемый контекст значительно облегчает управление.

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

Джейсон Козак
источник
На самом деле это хорошая идея. И это часть дизайна, который я пытаюсь создать, но я хотел реализовать эти функции поверх обычного низкоуровневого API. Но может случиться так, что для некоторых функций вам все же нужно углубиться в нативный API для некоторых более конкретных случаев.
NocturnDragon
Часть идеи заключается в том, чтобы избежать создания общего низкоуровневого API и необходимости иметь дело с переносом с использованием метода наименьшего общего знаменателя. Перемещая уровень абстракции на ступеньку выше, вы несколько ограничиваете набор функций, но также получаете возможность использовать каждую платформу. Чтобы удовлетворить случайную потребность в более глубоком доступе, я предпочитаю предоставлять заголовок, который предоставляет заголовки платформы и некоторые внутренние помощники; это может сломать версию к версии, но она есть, если вам это нужно.
Джейсон Козак
1

Начнем с того, что каждый API работает по-своему, поэтому само собой разумеется, что перенос всех вышеперечисленных API будет затруднен. Тем не менее, иногда это необходимо сделать: в какой-то момент игра просто должна работать на более чем одной платформе, независимо от того, насколько сложно это сделать.

Я думаю, что лучший способ сделать это - предложить функциональность, которая может быть реализована на всех базовых API, и абстрагировать это и только это. Если вы разрабатываете мультиплатформенную игру, вы бы не реализовали все неясные функциональные возможности, которые поддерживает каждый API, вы бы реализовали только то, что вам нужно. Это также помогает поддерживать API небольшим и быстрым.

Чтобы избежать путаницы реализации каждого отдельного API в выходные данные, компиляция должна выполняться с использованием нейтрально-зависимых от платформы заголовочных файлов и файлов кода конкретной платформы. Тогда файл кода, специфичный для целевой платформы, будет единственным, скомпилированным, сохраняя API небольшим.

Шон Джеймс
источник
0

Об этом есть статья Эмиля Перссона (Humus) на GPU Pro.

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