22
\$\begingroup\$

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?

\$\endgroup\$
  • 30
    \$\begingroup\$ CUDA and OpenCL are not graphics APIs. \$\endgroup\$ – Soapy Oct 22 '15 at 7:55
  • 4
    \$\begingroup\$ To "independently contact the graphics driver" you always need some API! \$\endgroup\$ – Josef Oct 22 '15 at 12:55
  • 21
    \$\begingroup\$ No you don't need an API for graphics, you can access the driver directly, it doesn't even stop there, you can write your own driver to speak to the hardware directly if you'd ever want that. But your next question is much more important: "Should I use a graphics API?", yes, yes you should. \$\endgroup\$ – Kevin Oct 22 '15 at 14:27
  • 5
    \$\begingroup\$ You people realise that an API is also made at one point? The driver is exposed to external calls which an API implements and wraps in nice easy to use API calls. \$\endgroup\$ – Kevin Oct 22 '15 at 18:52
  • 3
    \$\begingroup\$ There isn't a graphics card (or OS, at this point) that doesn't support OpenGL. It literally runs on everything, so if the only reason you don't want to use it is for "compatibility", it's a completely baseless concern. \$\endgroup\$ – Sandalfoot Oct 22 '15 at 19:02

11 Answers 11

39
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ Kudos, good addition to the discussion. You learn something new every day. \$\endgroup\$ – Engineer Oct 22 '15 at 19:04
  • 1
    \$\begingroup\$ What restricts your choice of writing a kernel module to do the hardware access? Also, if you are targeting a single card (the one in your machine), compatibility issues fall away; though it is still far from a trivial thing to do; but within the realm of feasible, given reverse engineered drivers; especially if you only have a limited scope of what you want to do with the card. \$\endgroup\$ – Joel Bosveld Oct 22 '15 at 23:06
  • 1
    \$\begingroup\$ Driver signing on many OSes makes it difficult to distribute your module. You could certainly build up all kinds of OS drivers and hacks locally, but you're not going to be able to distribute your game very widely, which I assumed is a desired aspect as the OP asked about making an actual game, not a pointless tech demo. :p \$\endgroup\$ – Sean Middleditch Oct 23 '15 at 1:35
27
\$\begingroup\$

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.

\$\endgroup\$
  • 11
    \$\begingroup\$ To pile on for the OP's benefit: software rendering also has significantly poorer performance. While this may not matter in terms of frame rate for simpler games, I doubt many customers will appreciate the reduction in battery life they suffer because software rendering is keeping their CPU much more active than it would otherwise need to be. \$\endgroup\$ – Chris Hayes Oct 22 '15 at 8:43
  • 1
    \$\begingroup\$ Good point, @ChrisHayes... edited to add. One sometimes assumes such things are obvious. \$\endgroup\$ – Engineer Oct 22 '15 at 8:45
  • 1
    \$\begingroup\$ It seems like your first paragraph is saying that technically it's not necessary to use an API. Sure, it saves a tremendous amount of programmer time, perhaps more than one person has to offer, but it's not necessary. As I would expect, unless there is some kind of cryptographic verification going on between the graphics card driver and higher-level software libraries. \$\endgroup\$ – David Z Oct 22 '15 at 16:43
  • 5
    \$\begingroup\$ @DavidZ Have you a written a driver? Do you know what it's like interfacing with complex hardware when you don't even have the specs, when even the engineers employed by the card's manufacturer took man-months to develop the driver? Now multiply that by however many architectures you have to support. If I say, "It's impossible to climb Everest without equipment," of course there is a chance you can, but it really is so miniscule a chance... why would anyone argue the point? \$\endgroup\$ – Engineer Oct 22 '15 at 18:38
  • 1
    \$\begingroup\$ Ask the OP why they want to argue the point ;-) but especially after the edit, it's quite clear that is what they want. \$\endgroup\$ – David Z Oct 23 '15 at 0:44
8
\$\begingroup\$

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.

\$\endgroup\$
6
\$\begingroup\$

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.

\$\endgroup\$
4
\$\begingroup\$

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!

\$\endgroup\$
4
\$\begingroup\$

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.

\$\endgroup\$
1
\$\begingroup\$

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.

\$\endgroup\$
1
\$\begingroup\$

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).

\$\endgroup\$
1
\$\begingroup\$

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.

\$\endgroup\$
0
\$\begingroup\$

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.

\$\endgroup\$
0
\$\begingroup\$

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.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.