Как узнать, что я слишком плотно абстрагирую графические API?

23

При создании средства визуализации, поддерживающего несколько графических API, вы, как правило, захотите абстрагировать код в какую-то низкоуровневую библиотеку, связанную с некоторыми графическими API, такими как OpenGL, Vulkan, D3D11 и т. Д .;

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

Как я узнаю, что делаю слишком много жесткой абстракции?

graphics-programming

— Габриэле Виерти
источник

5

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

— Mooing Duck

@ Угу, если правильно, да.

— Габриэле Виерти

4

Я бы серьезно усомнился в этом. Большинство достижений в Vulkan происходят из-за того, что они очень низкого уровня и делают вещи очень своеобразным, специфическим способом. То, что достаточно универсально, чтобы делать то же самое в OpenGL или D3D, почти наверняка не может этого сделать. Повторная реализация того же, что и OpenGL (как это ни парадоксально делают многие учебные пособия по Vulkan), приводит к 99,99% той же производительности, что в 20 раз больше работы.

— Деймон

@ Дэймон, верно, но новые API специально разработаны (и не адаптированы, как OpenGL) для работы на современных графических процессорах; Говоря о Vulkan, вы можете в значительной степени использовать один и тот же API на каждой поддерживаемой платформе, в отличие от OpenGL, где вам нужно использовать версию «Embedded Systems». Помимо меньших накладных расходов процессора и необычных функций у нас не так много, но в будущем у нас могут появиться некоторые довольно удивительные методы, которые могут работать быстрее с использованием Vk или D3D12, а не OGL или D3D11

— Gabriele Vierti

44

Прежде всего, подумайте, стоит ли на самом деле поддерживать более одного графического API. Простое использование OpenGL охватит большинство платформ и будет «достаточно хорошим» для всех проектов, кроме самых амбициозных в графическом отношении. Если вы не работаете в очень большой игровой студии, которая может позволить себе потратить несколько тысяч человеко-часов на реализацию и тестирование нескольких бекендов рендеринга, и если нет каких-то специфических функций DirectX или Vulcan, которые вы действительно хотите продемонстрировать, то это обычно не стоит хлопот , Особенно учитывая, что вы можете сэкономить много работы, используя слой абстракции, созданный кем-то другим (сторонняя библиотека или игровой движок).

Но давайте предположим, что вы уже оценили свои варианты и пришли к выводу, что он и жизнеспособен, и стоит потратить время на свои собственные.

Тогда главным судьей архитектуры программного обеспечения вашего уровня абстракции будут ваши внешние программисты.

Могут ли они реализовать игровые системы, которые они хотят внедрить, не задаваясь вопросом о деталях низкого уровня?
Могут ли они полностью игнорировать наличие более одного графического API?
Будет ли теоретически возможно добавить еще один рендеринг, не изменяя какой-либо интерфейсный код?

Если так, то вам это удалось.

— Philipp
источник

2

Еще одно предложение: стоит ли подчеркнуть, что цель состоит в том, чтобы достичь целей в пунктах пули с минимальным уровнем усилий - просто поразить цель и не идти дальше? В противном случае каждый из них может превратиться в кроличью нору для типичного разработчика, который (включая меня) часто не знает, когда оставить достаточно хорошего в покое. :) А также, что единственный надежный способ оценить успех - это итерационная разработка и тестирование API с реальными пользователями; невозможно точно угадать, и приводит к сценарию чрезмерной инженерии в кроличьей норе.

— Боб

5

Я бы добавил, что если вам действительно нужно поддерживать несколько графических библиотек, почти наверняка есть готовая, которая делает все, что вам нужно, так что даже тогда вы действительно не должны делать свою собственную. (Конечно, бывают и исключения, но если вы недостаточно опытны, чтобы спросить «насколько трудной должна быть абстракция», вы, вероятно, не работаете над проектом, который требует от вас этого)

— Фонд Monica's Lawsuit

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

— jpmc26

6

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

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

Выберите цели, которые вы будете поддерживать, и поймите их. Трудно написать приличные обертки для «всего», и вам, вероятно, не нужно (возможно, вам также не нужно писать ни одной обертки, как отмечено в ответе Филиппа ). Почти невозможно написать достойную оболочку, если вы не знаете API, который вы собираетесь обернуть.

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

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

3

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

— Supercat
источник