Мне действительно нужно использовать графический API?

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

Могу ли я сделать свой собственный графический API или библиотеку для своей игры? Даже если это сложно, теоретически возможно ли для моего 3D-приложения независимо связаться с графическим драйвером и визуализировать все на GPU?

Я думаю, что во многих ответах упущен важный момент: вы можете писать приложения, которые имеют прямой доступ к оборудованию, но не в современных операционных системах . Это не просто проблема времени, но проблема «у вас нет выбора».

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

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

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

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

Единственная реалистичная альтернатива состоит в том, что вы не используете 3D-ускорение, а вместо этого идете на программный рендеринг, который, при условии, что он написан на чем-то действительно портативном, например, C, сможет работать практически на любой системе / устройстве. Это хорошо для небольших игр ... что-то вроде SDL подходит для этой цели ... есть и другие. Но для этого не хватает встроенных возможностей 3D, поэтому вам придется создавать их самостоятельно ... что не является тривиальной задачей.

Также помните, что рендеринг процессора неэффективен и страдает от низкой производительности по сравнению с графическими процессорами.

Такие API, как OpenGL или DirectX, частично реализованы операционной системой и частично реализованы самим графическим драйвером.

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

Загрузите свой компьютер в MS-DOS. Затем, используя свою копию энциклопедии PC Game Programmers , вы можете записать ее непосредственно в VESA карты. регистры и в видеопамять. У меня все еще есть код, который я написал 20 лет назад, чтобы сделать это и визуализировать элементарные 3D в программном обеспечении.

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

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

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

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

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

Итак, теоретически вы можете, но это невозможно, и вы не получите никакого преимущества. Ограничения API сегодня становятся меньше с каждым днем, у вас есть CUDA и OpenCL и шейдеры. Таким образом, полный контроль больше не проблема.

Более полное объяснение:

Ответить на это скучно да . Реальный вопрос почему ?

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

С графическими процессорами вы получаете «лучшую» производительность, но теряете много свободы. Разработчики графики стремятся вернуть эту свободу. Следовательно, все больше и больше настроек каждый день. Вы можете делать практически все, используя CUDA / OpenCL и даже шейдеры, не касаясь драйверов.

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

Если вы переходите на более низкий уровень, вы просто используете интерфейс более низкого уровня, но вы все еще используете интерфейс, только тот, который не работает с таким количеством разных карт, как у более высокого уровня.

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

Что касается карт NVIDIA, вы должны взглянуть на проект nouveau с открытым исходным кодом . У них есть коллекция отличных ресурсов здесь .

Для видеокарт других марок вы можете найти похожие проекты и документацию.

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

Избавление от DirectX или OpenGl не приведет к удалению зависимостей, оно представит их больше. Другие ответы уже содержат несколько хороших моментов, почему может даже не быть возможности напрямую общаться с графическим оборудованием (по крайней мере, это неосуществимо), но мой первый ответ был бы: Если бы вы действительно написали библиотеку, которая абстрагирует все распространенные 3D графическое оборудование в единый API, вы бы эффективно переписали DirectX / OpenGl. Если бы вы использовали свой код для написания игры, вы бы добавили новую библиотеку в качестве новой зависимости, точно так же, как у вас теперь есть DirectX / OpenGl в качестве зависимости.

Используя DirectX или OpenGl, ваши зависимости в основном говорят: «Этот код зависит от библиотеки, чтобы предоставить код, объясняющий, как выполнять определенные команды на разных видеокартах». Если бы вы обходились без такой библиотеки, вы бы вводили зависимость «Этот код зависит от графического оборудования, которое ведет себя точно так же, как и оборудование, существовавшее при создании игры».

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

Прежде всего, CUDA и OpenCL не являются графическим интерфейсом API. Они вычисляют API.

Проблема написания вашего собственного графического API в том, что он очень сложный. Вы можете напрямую взаимодействовать с оборудованием, но нет гарантии, что, если оно работает в системе с X CPU, X GPU, X Ram и X, то оно будет работать в системе с Y CPU, Y GPU и т. Д. Хорошим моментом является то, что DirectX работает с драйверами режима ядра. Это внедрено в ядро. Кроме того, графические интерфейсы не созданы для поддержки графических процессоров. Графические процессоры (и их драйверы) созданы для их поддержки. Таким образом, вы в значительной степени не сможете создать графический API, если вы не создадите свою собственную ОС и не используете предоставляемые x86 VGA-прерывания. Но вы все равно не сможете правильно взаимодействовать с графическим процессором, и вы застрянете в низком разрешении.

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

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

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