<p>Speed is the most common reason why this is <strong>not</strong> 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).</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>PPS: This is why they are rolling out Vulkan.</p>

CC BY-SA 3.0
2016-03-25T11:45:34.313Z
`See the number of pixels you need to update grows exponetially when the sides grow.` Quadratically, i think.
Cthulhu
CC BY-SA 3.0
2016-03-25T13:06:31.973Z
"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.)
Coxy
CC BY-SA 3.0
2016-03-25T13:42:15.433Z
So APIs make things faster by letting the GPU do the work?
Suici Doga
CC BY-SA 3.0
2016-03-25T13:44:59.973Z
Yes - the GPU is capable of doing hundreds of times as many calculations as the CPU.
pjc50
CC BY-SA 3.0
2016-03-25T14:19:36.793Z
@pjc50 its not so much that the cpu is faster per core it just has extrenely many cores. Since pixels pushing is a embarassingly parallel business it works.
joojaa
CC BY-SA 3.0
2016-03-25T14:21:10.750Z
@Coxy yes but on top of that copying you need to prepare that image. So it limits what i can prepare. Nothing stops you from doing this, with opengl. Prepare image upload prepare upload.
joojaa
CC BY-SA 3.0
2016-03-25T14:22:53.633Z
@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.
Nero
CC BY-SA 3.0
2016-03-25T18:00:36.997Z
@Cthulhu, quadratic can equal exponential (think about it, exponential = `y=x^2` and quadratic = `y=x^2+2x+1`, they looks the same, but they're in different places on the graph)
Daniel
CC BY-SA 3.0
2016-03-25T18:14:13.497Z
@Daniel $x^2$ is a quadratic function. An exponential function would be $2^x$. And exponential functions grow way faster than quadratic functions.
Nero
CC BY-SA 3.0
2016-03-25T18:14:43.663Z
Gah, my bad - this is what I get for not waking up fully before typing.
Daniel
CC BY-SA 3.0
2016-03-25T20:18:55.960Z
many words, don't go to the point. @pjc50 answer is most to the point and understandable
akostadinov
CC BY-SA 3.0
2016-03-26T06:47:47.153Z
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.
IMil
CC BY-SA 3.0
2016-03-26T07:32:34.387Z
@IMil yesIi commented about this. It is more meant to be a lies to children type of answer than a this is the exact reason. 3D is by no reason the only reason we use graphics accelerators.
joojaa
CC BY-SA 3.0
2016-03-26T07:48:40.713Z
The operating system could a API which allows everything to be drawn by pixels
Suici Doga
CC BY-SA 3.0
2016-03-26T07:58:57.253Z
@SuiciDoga there is an api for that both directX and opengl can do this as can direct2D, GDI and numerous others. Just because the api can do more complex things does not mean it cant do simple things too. Just you do not write directly to the buffer on screen somebody else does that for you.
joojaa
CC BY-SA 3.0
2016-03-26T08:11:28.833Z
@joojaa what do you mean by 'lies to the children'? There are two options. 1) you calculate every pixel by hand, 2) you say: here are the coordinates, here is the texture, here are the light sources, go ahead and draw them. Option 2 is easier, and it allows graphic chip designers and driver developers to make even old games faster.
IMil
CC BY-SA 3.0
2016-03-26T08:27:29.920Z
@IMil Lies to children is a simplified reality, i know full and well that the answer is not this simple. Its not granted that the CPU is slower than the GPU. It can be faster IF the image you make is not parallelizable. Its just that in general pixels are independent of each other, if this is not the case then it does not hold true. So it is not certain and definitive that this is fastest in a general sense. But since it is there you rarely see other kinds of things. Too many dimensions to consider.
joojaa
CC BY-SA 3.0
2016-03-25T06:40:42.843Z
2016-03-25T15:48:11.280Z
2016-03-25T15:48:11.280Z
joojaa
<p>Just to add to <a href="https://computergraphics.stackexchange.com/a/2232/">joojaa's answer</a>, things <em>are</em> 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. </p>

<p>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.</p>

CC BY-SA 3.0
2016-03-25T08:14:09.057Z
2016-03-25T09:32:34.763Z
2017-04-13T13:00:43.660Z
russ
<p><em>work on any 32-bit color GPU (even old ones)?</em></p>

<p>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.</p>

<p>A graphical accelerator allows the drawing of pixels considerably <em>faster</em> 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.</p>

<p>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 <em>is</em> 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.</p>

CC BY-SA 3.0
2016-03-25T13:38:36.217Z
My laptop's APU has 256 shader cores @ 686MHZ while my tablet has 192.
Suici Doga
CC BY-SA 3.0
2016-03-25T18:02:04.110Z
Hey, the Titan X has 5760 cores in it.
Daniel
CC BY-SA 3.0
2016-03-26T02:33:38.857Z
@Daniel Are there any games that the Titan X goes <  30fps at ultra high .The Titan X is very powerful
Suici Doga
CC BY-SA 3.0
2016-03-26T02:46:36.110Z
Ummm, One of these, perhaps: http://www.maximumpc.com/10-most-graphically-demanding-pc-games/
Daniel
CC BY-SA 3.0
2016-03-26T13:30:40.113Z
@Daniel The developers of those games must have need about 2-4 Titan X cards :)
Suici Doga
CC BY-SA 3.0
2016-03-26T14:48:27.263Z
Yep.  I'm going to start developing in UE4, and that engine is a beast.  For max settings in a big world you basically need 4 Titan X's to get 60fps @ 1080p.
Daniel
CC BY-SA 3.0
2016-03-28T02:44:14.047Z
I am a beginner with developing games and creating some Unity games using my laptop's APU.I haven't experienced much lag because my laptop has a dedicated class APU which almost as good as a dedicated video card.My APU is a AMD A8-4500M.I do not think that this laptop can use UE4 without a external GPU card (using USB3).
Suici Doga
CC BY-SA 3.0
2016-03-28T02:46:51.953Z
And to get 4K they must need about 8 Titan X GPUs
Suici Doga
CC BY-SA 3.0
2016-03-25T13:04:06.423Z
2016-03-25T13:04:06.423Z
pjc50
<p>Games and other graphically intensive applications use frameworks like OpenGL and DirectX. Also they require features like pixel shader and DX12.</p>

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

<p>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)?</p>

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

CC BY-SA 3.0
2016-03-26T03:29:37.357Z
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.
user541686
CC BY-SA 3.0
2016-03-26T04:18:47.940Z
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.
Criticize SE actions means ban
CC BY-SA 3.0
2016-03-26T04:35:21.333Z
I think that GPU companies have to create their own DirectX drivers
Suici Doga
CC BY-SA 3.0
2016-03-26T17:07:22.950Z
"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).
el.pescado - нет войне
CC BY-SA 3.0
2016-03-28T03:55:44.500Z
@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.
Navin
<3d><gpu><performance><pixel-shader><pixels>
Why do we have graphics frameworks like OpenGL and DirectX, when games could just draw pixels directly?
Suici Doga
# Why do we have graphics frameworks like OpenGL and DirectX, when games could just draw pixels directly?

(Asked by: username_0 on 2016-03-25)

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?

**Tags:** 3d, gpu, performance, pixel-shader, pixels

> **Comments:**
> **username_1**: 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.  
> **username_2**: 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.  
> **username_0**: I think that GPU companies have to create their own DirectX drivers  
> **username_3**: "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).  
> **username_4**: @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.  

---

## 3 answers

### Answer by username_5 on 2016-03-25. Score: 23 | Accepted answer

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.

> **Comments:**
> **username_6**: `See the number of pixels you need to update grows exponetially when the sides grow.` Quadratically, i think.  
> **username_7**: "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.)  
> **username_0**: So APIs make things faster by letting the GPU do the work?  
> **username_8**: Yes - the GPU is capable of doing hundreds of times as many calculations as the CPU.  
> **username_5**: @username_8 its not so much that the cpu is faster per core it just has extrenely many cores. Since pixels pushing is a embarassingly parallel business it works.  
> **username_5**: @username_7 yes but on top of that copying you need to prepare that image. So it limits what i can prepare. Nothing stops you from doing this, with opengl. Prepare image upload prepare upload.  
> **username_9**: @username_8 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.  
> **username_10**: @username_6, quadratic can equal exponential (think about it, exponential = `y=x^2` and quadratic = `y=x^2+2x+1`, they looks the same, but they're in different places on the graph)  
> **username_9**: @username_10 $x^2$ is a quadratic function. An exponential function would be $2^x$. And exponential functions grow way faster than quadratic functions.  
> **username_10**: Gah, my bad - this is what I get for not waking up fully before typing.  
> **username_11**: many words, don't go to the point. @username_8 answer is most to the point and understandable  
> **username_12**: 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.  
> **username_5**: @username_12 yesIi commented about this. It is more meant to be a lies to children type of answer than a this is the exact reason. 3D is by no reason the only reason we use graphics accelerators.  
> **username_0**: The operating system could a API which allows everything to be drawn by pixels  
> **username_5**: @username_0 there is an api for that both directX and opengl can do this as can direct2D, GDI and numerous others. Just because the api can do more complex things does not mean it cant do simple things too. Just you do not write directly to the buffer on screen somebody else does that for you.  
> **username_12**: @username_5 what do you mean by 'lies to the children'? There are two options. 1) you calculate every pixel by hand, 2) you say: here are the coordinates, here is the texture, here are the light sources, go ahead and draw them. Option 2 is easier, and it allows graphic chip designers and driver developers to make even old games faster.  
> **username_5**: @username_12 Lies to children is a simplified reality, i know full and well that the answer is not this simple. Its not granted that the CPU is slower than the GPU. It can be faster IF the image you make is not parallelizable. Its just that in general pixels are independent of each other, if this is not the case then it does not hold true. So it is not certain and definitive that this is fastest in a general sense. But since it is there you rarely see other kinds of things. Too many dimensions to consider.  

---

### Answer by username_13 on 2016-03-25. Score: 14

Just to add to [username_5's answer](https://computergraphics.stackexchange.com/a/2232/), 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.


---

### Answer by username_8 on 2016-03-25. Score: 14

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

> **Comments:**
> **username_0**: My laptop's APU has 256 shader cores @ 686MHZ while my tablet has 192.  
> **username_10**: Hey, the Titan X has 5760 cores in it.  
> **username_0**: @username_10 Are there any games that the Titan X goes <  30fps at ultra high .The Titan X is very powerful  
> **username_10**: Ummm, One of these, perhaps: http://www.maximumpc.com/10-most-graphically-demanding-pc-games/  
> **username_0**: @username_10 The developers of those games must have need about 2-4 Titan X cards :)  
> **username_10**: Yep.  I'm going to start developing in UE4, and that engine is a beast.  For max settings in a big world you basically need 4 Titan X's to get 60fps @ 1080p.  
> **username_0**: I am a beginner with developing games and creating some Unity games using my laptop's APU.I haven't experienced much lag because my laptop has a dedicated class APU which almost as good as a dedicated video card.My APU is a AMD A8-4500M.I do not think that this laptop can use UE4 without a external GPU card (using USB3).  
> **username_0**: And to get 4K they must need about 8 Titan X GPUs  

---

