Game Development Stack Exchange is a question and answer site for professional and independent game developers. It only takes a minute to sign up.
Sign up to join this community
Is it necessary to use graphics APIs to get hardware acceleration in a 3D game? To what degree is it possible to free of dependencies to graphics-card APIs like OpenGL, DirectX, CUDA, OpenCL or whatever else?
Can I make my own graphics API or library for my game? Even if it's hard, is it theoretically possible for my 3D application to independently contact the graphics driver and render everything on the GPU?
I think a lot of the answers miss an important point: you can write apps that access hardware directly, but not on modern operating systems. It's not just a time problem, but a "you don't have a choice" problem.
Windows, Linux, OSX, etc. all ban direct hardware access to arbitrary applications. This is important for security reasons: you don't want any random app to be able to read arbitrary GPU memory for the same reason you don't want any random app to be able to read system memory. Things like the framebuffer for your bank account or whatnot live in GPU memory. You want that stuff isolated and protected and access controlled by your OS.
Only drivers can talk directly to most hardware, and the only way to talk to the driver is via the OS' exposed HAL and each driver's proprietary and incompatible interface. That driver interface will not only be different for each vendor but will even differ between versions of the driver itself, making it near impossible to talk directly to the interface in a consumer application. These layers are often covered by access controls that further restrict the ability for an application to access them.
So no, your game cannot just use the hardware directly, unless of course you're only targeting insecure operating systems like DOS, and your only feasible option for a game on modern consumer operating systems is to target a public API like DirectX, OpenGL or Vulkan.
Practically its necessary, yes. It's necessary because unless you want to spend years writing what is essentially driver code for the multitude of different hardware configurations out there, you need to use an API that unifies against existing drivers written by GPU vendors for all popular operating systems and hardware.
The only realistic alternative is that you don't use 3D acceleration, and instead go for software rendering which, provided it's written in something truly portable like C, will be able to run on just about any system/device. That's fine for smaller games... something like SDL is suited to this purpose... there are others out there as well. But this lacks inherent 3D capabilities so you'd have to build them yourself... which is not a trivial task.
Also remember that CPU rendering is inefficient and suffers poor performance compared to GPUs.
APIs like OpenGL or DirectX are partialy implemented by the operating system and partially implemented by the graphic driver itself.
That means when you would want to create your own low-level API which makes use of the capabilities of modern GPUs, you essentially need to write an own graphic driver. Making sure that your driver works with all common graphic cards would be quite a challenge, especially because the vendors are often not very open with their specifications.
Boot your PC into MS-DOS. Then, using your copy of the PC Game Programmers Encyclopedia, you can write directly into the card's VESA registers and into video memory. I still have the code I wrote 20 years ago to do this and render rudimentary 3D in software.
Alternatively, you can just use DirectX; it's a really thin abstraction layer, and also lets you write directly into video buffers and then swap them to the screen.
There's also the extreme approach of building your own video hardware.
The other answers answer your main question quite nicely: technically, it's possible, but in practice, if your goal is to broaden your customer base, you're actually doing the opposite. While wasting a huge amount of work on supporting the thousands of different hardware and OS configurations you need to support.
However, that doesn't mean you have to be 100% dependent on one particular API. You can always code up your own abstraction layer, and then swap the more specific implementations (e.g. a DirectX implementation, an OpenGL implementation, ...) in and out.
Even then, it probably isn't worth it. Just pick something that works well enough for your purposes, and be done with it. You're an indie game maker - you need to keep yourself focused on the things that make the game, not on the minutae. Just make the game!
In summary: Theoretically you can, but it's unfeasible, and you won't get any advantage. The limitations APIs have today become less every day, you have CUDA and OpenCL and shaders. So having full control is no more a problem.
Fuller explanation:
Answering this is a boring yes. The real question is why?
I hardly imagine why would you want to do this other than for learning purposes. You have to know that at some point, developers had the freedom to do anything with their CPU rendering implementations, everyone had there own API, they were in control of everything in the "pipeline". With the introduction of fixed pipeline and GPUs, everybody switched..
With GPUs you get "better" performance, but lose a lot of the freedom. Graphics developers are pushing to get that freedom back. Hence, more customization pipeline everyday. You can do almost anything using CUDA/OpenCL and even shaders, without touching the drivers.
You want to talk to hardware. You need to use a way to talk to the hardware. That way is the interface to the hardware. That's what OpenGL, DirectX, CUDA, OpenCL and whatever else are.
If you get on a lower level you are just using a lower level interface, but you are still using an interface, only one that doesn't work with as many different cards as the higher level one.
To get 3D Hardware Acceleration without using a traditional API, you essentially need to write your own code to duplicate the functionality of the graphics driver. So the best way to learn how to do this is to look at the code of the graphics driver.
For NVIDIA cards, you should look at the open source nouveau project. They have a collection of great resources here.
For other brands of graphics cards, you can find similar projects and documentation.
Note that as has been mentioned in other answers, most modern operating systems will prevent user-space programs from directly accessing hardware, so you will need to write your code and install it as an operating system driver. Alternatively, you can use the FreeDOS operating system, which has no such restrictions, and should let you (in theory) directly access the hardware, and allow you to write a regular program that renders 3D hardware accelerated graphics. Note that, even leveraging code from an existing open source graphics driver, this would be a tremendous amount of non-trivial work (and as far as I'm aware, has never been done, and due to various reasons, might actually not be technically possible).
Getting rid of DirectX or OpenGl would not remove dependencies, it would introduce more of them. The other answers already contain several good points why it may not even be possible to talk to the graphics hardware directly (at least it's not feasible), but my first answer would be: If you did in fact write a library that abstracts all common 3d graphics hardwares into a single API you would effectively have rewritten DirectX / OpenGl. If you were to use your code to write a game you would have added your new library as a new dependency, just like you now have DirectX / OpenGl as a dependency.
By using DirectX or OpenGl your dependencies are basically saying "This code depends on a library to provide the code that explains how to run certain commands on different graphics cards". If you went without such a library you would introduce the dependency of "This code depends on graphics hardware that behaves in exactly the same way as hardware that existed when I built the game."
Abstractions like OpenGl or DirectX allow the hardware manufacturers to provide code of their own (drivers) that lead to a common code base, so games are more likely to run on hardware that didn't even exist when the game was written.
First of all, CUDA and OpenCL are not graphics apis. They are compute apis.
The problem with writing your own graphics api is that it is very complex. You could interface with the hardware directly, but there is no guarantee that if it works on a system with X CPU, X GPU, X amount of ram and X operating system it will work on a system with Y CPU, Y GPU, etc. One good point is that DirectX works with kernel-mode drivers. It is rooted into the kernel. Also, graphics apis aren't built to support GPUs. GPUs (and their drivers) are built to support them. So you pretty much can't build a graphics api unless you build your own OS and use x86 provided VGA interrupts. But you still wouldn't be able to properly interface with the GPU and you would be stuck at low resolution.
I understand that you want to build everything yourself and not use an engine or anything like that. But making your own graphics api would just create inconvenience for the user.
You can write your own driver and API, there is nothing to stop you but your ability and knowledge levels. If nothing else it would be a good learning experience, the real problem is that without having lots of previous graphic experience then even if you are a great programmer you will probably be at a loss at to what you need to do...or even to get started.
Yet the interface you make yourself will be easier to use and more stable for you than something updated behind your back constantly. So it is a little surprising to me that more people don't go this route, but the reality is few people have the technical acumen and no one wants to pay someone for years on end to learn how to do all this, then possibly have them leave the company and leave them in the lurch. The good thing to them about standardization is it makes employees much more expendable and reduces risks.
