Games and other graphically intensive applications use frameworks like OpenGL and DirectX. Also they require features like pixel shader and DX12.

But why would we need all these frameworks and GPU features when we could just draw everything pixel by pixel?

First, the game would have to be compiling in a way so it is drawn pixel by pixel. This is likely to make the game executable big, but will it be faster and work on any 32-bit color GPU (even old ones)?

I know that the first 3D games were drawn pixel by pixel, but why aren't they doing it now?

  • $\begingroup$ In general doing one operation on a lot of things is more efficient and easier to think about than doing it on every thing individually. $\endgroup$
    – user541686
    Mar 26, 2016 at 3:29
  • 2
    $\begingroup$ Because every game would need to be rewritten for every graphics card. Unless they didn't use the graphics card, but then they'd be slow. $\endgroup$
    – user253751
    Mar 26, 2016 at 4:18
  • $\begingroup$ I think that GPU companies have to create their own DirectX drivers $\endgroup$
    – Suici Doga
    Mar 26, 2016 at 4:35
  • 1
    $\begingroup$ "But why would we need all these frameworks and GPU features when we could just draw everything pixel by pixel?" that's how it was done in good ol' days. Wolfenstein 3D, Doom, Duke Nukem 3D, Quake and most other games of late '90 used pure software rendering (Quake offered OpenGL renderer as an option). $\endgroup$ Mar 26, 2016 at 17:07
  • 1
    $\begingroup$ @MatthewRock You're not being helpful. You can certainly bundle an OS with a game inside a docker container and distribute the container. That way, the user doesn't need to install library dependencies for their distro. $\endgroup$
    – Navin
    Mar 28, 2016 at 3:55

3 Answers 3


Speed is the most common reason why this is not done. In fact you can do what you propose, if you make your own operating system, its just going to be very slow for architectural reasons. So the assumption that its faster is a bit flawed. Even if it would be faster, it would be less efficient in terms of development (like 1% speed increase for 10 times the work).

Copying the data over from the CPU to the graphics card is a relatively slow operation. The less you copy the faster your update speed can be. So ideally you would have most of the data on your GPU and only update small chunks of data. There is a world of difference between copying over 320x200 pixels compared to 1920x1200 or more. See the number of pixels you need to update grows quadratically when the sides grow.

Example: It's cheaper to tell the GPU to move the image 10 pixels right than copy the pixels manually to the video memory in different locations.

Why do you have to go trough an API? Simply because it's not your system. The operating system can not allow you to do whatever you want for safety reasons. Secondly because the operating system needs to abstract hardware away, even the OS is talking to the driver trough some abstracted system, an API if you will.

In fact I would rate the likelihood that your system would be faster, if you just did all the work yourself, close to near zero. It's a bit like comparing C and assembly. Sure you can write assembly, but compilers are pretty smart these days and optimize better and better all the time. It's hard to be better manually, even if you can your productivity will be down the drains.

PS: An API does not make it impossible to do this update just like old games did it. It's just inefficient that's all. Not because of the API mind but because it is inefficient period.

PPS: This is why they are rolling out Vulkan.

  • 6
    $\begingroup$ See the number of pixels you need to update grows exponetially when the sides grow. Quadratically, i think. $\endgroup$
    – Cthulhu
    Mar 25, 2016 at 11:45
  • $\begingroup$ "Copying the data over from the CPU to the graphics card is a relatively slow operation." This is true, but irrelevant. Copying over a few million pixels at 60 fps is easily achievable over even modest PCI-E links (it would only require a few hundred megabytes per second.) $\endgroup$
    – Coxy
    Mar 25, 2016 at 13:06
  • 2
    $\begingroup$ @pjc50 That's not wrong, but also not exactly true. A GPU is specialized to run a single program (usually a shader) in parallel on a large amount of data. So, you need to perform the same operations on lots of data to actually use the computing power of a GPU. If your program doesn't, you better run the program on the CPU. $\endgroup$
    – Nero
    Mar 25, 2016 at 14:22
  • 2
    $\begingroup$ @Daniel $x^2$ is a quadratic function. An exponential function would be $2^x$. And exponential functions grow way faster than quadratic functions. $\endgroup$
    – Nero
    Mar 25, 2016 at 18:14
  • 1
    $\begingroup$ You talk about copying and moving, but what's more important is the actual image generation. You have to determine which object will be visible at which point, how it will be lighted, what will be the effects of smoke, etc, etc. GPUs are highly optimized to perform these operations fast and in parallel. APIs make it easy to express common operations. $\endgroup$
    – IMil
    Mar 26, 2016 at 6:47

work on any 32-bit color GPU (even old ones)?

Bit of history here: this is how games were done on PC up until graphical accelerators started to become available in the mid-90s. It did indeed work on all hardware, because the hardware wasn't doing much.

A graphical accelerator allows the drawing of pixels considerably faster than a CPU can, by using specialized hardware and parallelism. The accelerator contains a number of processor cores. A desktop PC will have between 1-8 cores depending on age. My GTX970Ti graphics card has 1664 (one thousand six hundred and sixty-four!) cores. This obviously beats the PC for raw speed by a long way.

However, accelerators aren't standardized, and often include weird computer architecture tricks in order to achieve their speed. In order to write a game which isn't customized to a specific make and model of the card, an API needs to exist. And that's what DirectX, GL and the shader languages are used for. In fact, writing shaders is the closest thing to writing a program that draws pixels directly - it's just that the card will run a thousand copies of that program for you in parallel, one per pixel.

  • $\begingroup$ My laptop's APU has 256 shader cores @ 686MHZ while my tablet has 192. $\endgroup$
    – Suici Doga
    Mar 25, 2016 at 13:38
  • $\begingroup$ Hey, the Titan X has 5760 cores in it. $\endgroup$
    – Daniel
    Mar 25, 2016 at 18:02
  • $\begingroup$ @Daniel Are there any games that the Titan X goes < 30fps at ultra high .The Titan X is very powerful $\endgroup$
    – Suici Doga
    Mar 26, 2016 at 2:33
  • $\begingroup$ Ummm, One of these, perhaps: maximumpc.com/10-most-graphically-demanding-pc-games $\endgroup$
    – Daniel
    Mar 26, 2016 at 2:46
  • $\begingroup$ @Daniel The developers of those games must have need about 2-4 Titan X cards :) $\endgroup$
    – Suici Doga
    Mar 26, 2016 at 13:30

Just to add to joojaa's answer, things are still being drawn pixel by pixel. You're just generating the pixels using a vertex shader/assembler/rasterizer, then texturing and lighting them using a fragment shader. This was all done in software in the 90's when your video card wasn't much more than a blitter and a frame buffer, but it was slow as hell. Hence the invention of modern GPUs.

The drawing maths that's happening is basically the same as it was back in the Doom days, but now it's running on hundreds/thousands of shader ALUs rather than a handful of CPU cores. The APIs map down to basically the same set of GPU instructions behind the scenes. They're just there to stop you having to write a ton of gnarly GPU assembly across multiple vendor platforms.


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.