¿Realmente necesito usar una API de gráficos?

¿Es necesario usar API de gráficos para obtener aceleración de hardware en un juego 3D? ¿En qué medida es posible liberarse de las dependencias de las API de tarjetas gráficas como OpenGL, DirectX , CUDA, OpenCL o cualquier otra cosa?

¿Puedo hacer mi propia API de gráficos o biblioteca para mi juego? Incluso si es difícil, ¿es teóricamente posible que mi aplicación 3D se ponga en contacto independientemente con el controlador de gráficos y renderice todo en la GPU?

Creo que muchas de las respuestas pierden un punto importante: puede escribir aplicaciones que accedan directamente al hardware, pero no en los sistemas operativos modernos . No es solo un problema de tiempo, sino un problema de "no tienes otra opción".

Windows, Linux, OSX, etc., prohíben el acceso directo de hardware a aplicaciones arbitrarias. Esto es importante por razones de seguridad: no desea que ninguna aplicación aleatoria pueda leer la memoria arbitraria de la GPU por la misma razón que no desea que ninguna aplicación aleatoria pueda leer la memoria del sistema. Cosas como el framebuffer para su cuenta bancaria o lo que no vive en la memoria de la GPU. Desea que esas cosas estén aisladas y protegidas y su acceso controlado por su sistema operativo

Solo los controladores pueden hablar directamente con la mayoría del hardware, y la única forma de hablar con el controlador es a través del HAL expuesto del sistema operativo y la interfaz exclusiva e incompatible de cada controlador. Esa interfaz de controlador no solo será diferente para cada proveedor, sino que incluso diferirá entre las versiones del controlador, lo que hace que sea casi imposible hablar directamente con la interfaz en una aplicación de consumidor. Estas capas a menudo están cubiertas por controles de acceso que restringen aún más la capacidad de una aplicación para acceder a ellas.

Entonces, no, su juego no puede usar el hardware directamente, a menos que, por supuesto, solo se dirija a sistemas operativos inseguros como DOS, y su única opción factible para un juego en sistemas operativos de consumo modernos es apuntar a una API pública como DirectX, OpenGL o Vulkan

Prácticamente es necesario, sí. Es necesario porque a menos que desee pasar años escribiendo lo que es esencialmente el código del controlador para la multitud de configuraciones de hardware diferentes que existen, debe usar una API que se unifique con los controladores existentes escritos por los proveedores de GPU para todos los sistemas operativos y hardware populares.

La única alternativa realista es que no use la aceleración 3D y, en su lugar, elija el software que, si está escrito en algo realmente portátil como C, podrá ejecutarse en casi cualquier sistema / dispositivo. Eso está bien para juegos más pequeños ... algo como SDL es adecuado para este propósito ... también hay otros por ahí. Pero esto carece de capacidades 3D inherentes, por lo que tendría que construirlas usted mismo ... lo cual no es una tarea trivial.

También recuerde que el procesamiento de la CPU es ineficiente y sufre un bajo rendimiento en comparación con las GPU.

Las API como OpenGL o DirectX son implementadas parcialmente por el sistema operativo y parcialmente implementadas por el controlador gráfico mismo.

Eso significa que cuando desee crear su propia API de bajo nivel que haga uso de las capacidades de las GPU modernas, esencialmente necesita escribir un controlador gráfico propio. Asegurarse de que su controlador funcione con todas las tarjetas gráficas comunes sería todo un desafío, especialmente porque los proveedores a menudo no son muy abiertos con sus especificaciones.

Arranca tu PC en MS-DOS. Luego, utilizando su copia de la Enciclopedia de programadores de juegos de PC , puede escribir directamente en los registros VESA de la tarjeta y en la memoria de video. Todavía tengo el código que escribí hace 20 años para hacer esto y renderizar 3D rudimentario en software.

Alternativamente, puede usar DirectX; es una capa de abstracción realmente delgada, y también te permite escribir directamente en búferes de video y luego cambiarlos a la pantalla.

También existe el enfoque extremo de construir su propio hardware de video .

Las otras respuestas responden bastante bien a su pregunta principal: técnicamente, es posible, pero en la práctica, si su objetivo es ampliar su base de clientes, en realidad está haciendo lo contrario. Si bien desperdicia una gran cantidad de trabajo en el soporte de miles de configuraciones diferentes de hardware y sistema operativo que necesita admitir.

Sin embargo, eso no significa que deba ser 100% dependiente de una API en particular. Siempre puede codificar su propia capa de abstracción y luego intercambiar las implementaciones más específicas (por ejemplo, una implementación de DirectX, una implementación de OpenGL, ...) dentro y fuera.

Incluso entonces, probablemente no valga la pena. Simplemente elija algo que funcione lo suficientemente bien para sus propósitos, y termine con eso. Eres un creador de juegos independiente: debes mantenerte enfocado en las cosas que hacen que el juego, no en las minutas. ¡Solo haz el juego!

En resumen: teóricamente puedes, pero es inviable y no obtendrás ninguna ventaja. Las limitaciones de las API se han reducido hoy día, tienes CUDA y OpenCL y sombreadores. Por lo tanto, tener control total ya no es un problema.

Explicación más completa:

Responder esto es un aburrido sí . La verdadera pregunta es ¿por qué ?

Apenas imagino por qué querrías hacer esto si no fuera para aprender. Debe saber que, en algún momento, los desarrolladores tenían la libertad de hacer cualquier cosa con sus implementaciones de procesamiento de CPU, todos tenían su propia API, tenían el control de todo en la "tubería". Con la introducción de la tubería fija y las GPU, todos cambiaron.

Con las GPU obtienes un "mejor" rendimiento, pero pierdes mucha libertad. Los desarrolladores de gráficos están presionando para recuperar esa libertad. Por lo tanto, más canalización de personalización cada día. Puede hacer casi cualquier cosa usando CUDA / OpenCL e incluso sombreadores, sin tocar los controladores.

Quieres hablar con el hardware. Debe usar una forma de hablar con el hardware. De esa manera es la interfaz para el hardware. Eso es lo que son OpenGL, DirectX, CUDA, OpenCL y cualquier otra cosa.

Si llegas a un nivel inferior, solo estás usando una interfaz de nivel inferior, pero aún estás usando una interfaz, solo una que no funciona con tantas tarjetas diferentes como la de nivel superior.

Para obtener aceleración de hardware 3D sin usar una API tradicional, esencialmente necesita escribir su propio código para duplicar la funcionalidad del controlador de gráficos. Entonces, la mejor manera de aprender cómo hacerlo es mirar el código del controlador de gráficos.

Para las tarjetas NVIDIA, debe consultar el proyecto nouveau de código abierto . Tienen una colección de excelentes recursos aquí .

Para otras marcas de tarjetas gráficas, puede encontrar proyectos y documentación similares.

Tenga en cuenta que, como se ha mencionado en otras respuestas, la mayoría de los sistemas operativos modernos evitarán que los programas de espacio de usuario accedan directamente al hardware, por lo que deberá escribir su código e instalarlo como un controlador del sistema operativo. Alternativamente, puede usar el sistema operativo FreeDOS, que no tiene tales restricciones, y debería permitirle (en teoría) acceder directamente al hardware y permitirle escribir un programa regular que renderice gráficos acelerados por hardware 3D. Tenga en cuenta que, incluso aprovechando el código de un controlador de gráficos de código abierto existente, esto sería una gran cantidad de trabajo no trivial (y que yo sepa, nunca se ha hecho, y debido a varias razones, en realidad podría no ser técnicamente posible).

Deshacerse de DirectX u OpenGl no eliminaría las dependencias, introduciría más de ellas. Las otras respuestas ya contienen varios puntos buenos por los cuales puede que ni siquiera sea posible hablar directamente con el hardware de gráficos (al menos no es factible), pero mi primera respuesta sería: Si de hecho escribiera una biblioteca que resuma todos los 3d comunes hardware de gráficos en una única API que efectivamente habría reescrito DirectX / OpenGl. Si tuviera que usar su código para escribir un juego, habría agregado su nueva biblioteca como una nueva dependencia, al igual que ahora tiene DirectX / OpenGl como dependencia.

Al usar DirectX u OpenGl, sus dependencias básicamente están diciendo "Este código depende de una biblioteca para proporcionar el código que explica cómo ejecutar ciertos comandos en diferentes tarjetas gráficas". Si no tuviera dicha biblioteca, introduciría la dependencia de "Este código depende del hardware de gráficos que se comporta exactamente de la misma manera que el hardware que existía cuando construí el juego".

Las abstracciones como OpenGl o DirectX permiten a los fabricantes de hardware proporcionar su propio código (controladores) que conducen a una base de código común, por lo que es más probable que los juegos se ejecuten en hardware que ni siquiera existía cuando se escribió el juego.

En primer lugar, CUDA y OpenCL no son apis de gráficos. Son apis de cálculo.

El problema con escribir su propia API de gráficos es que es muy complejo. Puede interactuar con el hardware directamente, pero no hay garantía de que si funciona en un sistema con CPU X, GPU X, cantidad de RAM y sistema operativo X funcione en un sistema con CPU Y, GPU Y, etc. Un buen punto es que DirectX funciona con controladores en modo kernel. Está arraigado en el núcleo. Además, las API gráficas no están diseñadas para admitir GPU. Las GPU (y sus controladores) están diseñadas para admitirlas. Por lo tanto, prácticamente no puede construir una API gráfica a menos que construya su propio sistema operativo y use interrupciones VGA proporcionadas x86. Pero aún así no podría interactuar adecuadamente con la GPU y se quedaría atascado en baja resolución.

Entiendo que desea construir todo usted mismo y no usar un motor ni nada de eso. Pero hacer su propia API de gráficos solo crearía inconvenientes para el usuario.

Puede escribir su propio controlador y API, no hay nada que lo detenga, excepto su capacidad y sus niveles de conocimiento. Si nada más sería una buena experiencia de aprendizaje, el verdadero problema es que sin tener mucha experiencia gráfica previa, incluso si usted es un gran programador, probablemente no se dé cuenta de lo que necesita hacer ... o incluso Para empezar.

Sin embargo, la interfaz que hagas será más fácil de usar y más estable para ti que algo actualizado constantemente a tus espaldas. Por lo tanto, es un poco sorprendente para mí que más personas no sigan este camino, pero la realidad es que pocas personas tienen la perspicacia técnica y nadie quiere pagarle a alguien durante años para aprender cómo hacer todo esto, y luego posiblemente ellos dejan la compañía y los dejan en la estacada. Lo bueno para ellos acerca de la estandarización es que hace que los empleados sean mucho más prescindibles y reduce los riesgos.