<p>One early example of this (no doubt there are many others) was a 2004 Gamasutra article <a href="https://www.gamedeveloper.com/programming/building-a-million-particle-system" rel="nofollow noreferrer">&quot;Building a Million-Particle System&quot;</a>. It represented particle data, such as positions and velocities, encoded as color values in textures, and used fragment shaders to update them.</p>
<blockquote>
<p>In graphics hardware terms the input data stream can be represented by a texture, the output data stream by a render target. Output data is often re-used as input in a further processing step. In that case the data streams are textures as well as render targets. The processing kernel is represented by a pixel shader (also called fragment program). By drawing a full-screen rectangle, the graphics hardware is instructed to call the pixel shader once for each output data record, reading from the input stream in the pixel shader.</p>
</blockquote>
<p>This article even performed depth sorting of particles using multi-pass merge sort, and has some historically interesting discussion of the difficulties of turning the pixel data back into vertex data at the time (as there was no support for sampling textures in vertex shaders).</p>

CC BY-SA 4.0
2022-10-24T22:19:11.467Z
Nice to have such an old reference, at the time the article was written I was learning how to tie my shoes!
Felipe Gutierrez
CC BY-SA 4.0
2022-10-25T13:25:40.937Z
Awesome answer! That really is certainly an old reference, so it surely has been used for quite a long time.
Entangled Superposition
CC BY-SA 4.0
2022-10-24T17:44:43.183Z
2022-10-24T17:44:43.183Z
Nathan Reed
<p>This still happens in constraint platforms like OpenGL ES or the like were there are no compute shaders available and you end up hacking pixel shaders to do general purpose calculations, see any WebGL GPU physics demo and you most probably see ping ponging between fragment shader FBOs to be able to do computations. Or simply go to shadertoy.com and look at any physics/simulation demo. At the end of the day a compute shader ends up being very similar with the difference of it being more general purpose and therefore more tweakable and sometimes more performant for certain tasks.
Would be very nice if some OG could point at a very primitive example or the first time that someone thought that programable GPU programs/shaders were suitable for doing math on non graphics related stuff and did it though.</p>

CC BY-SA 4.0
2022-10-23T12:34:11.893Z
the floating point power was realized almost immediately I don't have any links but books like the first edition of the "orange" book has some good examples like early attempts at ambient occlusion.
pmw1234
CC BY-SA 4.0
2022-10-23T20:14:20.407Z
would be nice to look at that, when I have some time I might try to find that edition.
Felipe Gutierrez
CC BY-SA 4.0
2022-10-25T13:25:00.483Z
Thanks for this answer! In my head, it seemed like such an obvious way to do GPGPU without specific libraries like CUDA that I know someone had to be doing it somewhere.
Entangled Superposition
CC BY-SA 4.0
2022-10-25T16:22:26.700Z
I think this happened the other way around.  Computers used to have an optional floating point processor, which was later integrated into the CPU which made it cheaper and more ubiquitous.  The idea that gamers would buy a dedicated floating point processor just made the economy of scale work.
Greg Miller
CC BY-SA 4.0
2022-10-23T07:49:12.587Z
2022-10-23T07:49:12.587Z
Felipe Gutierrez
<p>Today we have tools such as Nvidia's CUDA and OpenCL to perform general purpose computing on the GPU (GPGPU). Seeing that traditional shaders are specifically used for generating graphics by filling a frame buffer with pixel values, are there any examples of graphics shaders being used for non-graphics computing prior to the modern GPGPU capability?</p>
<p>Shaders can take input parameter values sent from the CPU, and the GPU can be told to render to a texture buffer instead of the screen. With this in mind, I feel like someone could send in values for computation, compute them using the vertex and/or pixel shaders, and encode the results in the output pixel values which can be read by the CPU from the target buffer.</p>

CC BY-SA 4.0
2022-10-27T06:47:10.940Z
There' a [similar question](https://community.khronos.org/t/compute-shaders-before-opengl-4/107541) on the khronos forum too.
leone ruggiero
<shader><gpgpu>
Has general purpose GPU computing been used before compute shaders were available?
Entangled Superposition
# Has general purpose GPU computing been used before compute shaders were available?

(Asked by: username_0 on 2022-10-20)

Today we have tools such as Nvidia's CUDA and OpenCL to perform general purpose computing on the GPU (GPGPU). Seeing that traditional shaders are specifically used for generating graphics by filling a frame buffer with pixel values, are there any examples of graphics shaders being used for non-graphics computing prior to the modern GPGPU capability?

Shaders can take input parameter values sent from the CPU, and the GPU can be told to render to a texture buffer instead of the screen. With this in mind, I feel like someone could send in values for computation, compute them using the vertex and/or pixel shaders, and encode the results in the output pixel values which can be read by the CPU from the target buffer.

**Tags:** shader, gpgpu

> **Comments:**
> **username_1**: There' a [similar question](https://community.khronos.org/t/compute-shaders-before-opengl-4/107541) on the khronos forum too.  

---

## 2 answers

### Answer by username_2 on 2022-10-24. Score: 1 | Accepted answer

One early example of this (no doubt there are many others) was a 2004 Gamasutra article ["Building a Million-Particle System"](https://www.gamedeveloper.com/programming/building-a-million-particle-system). It represented particle data, such as positions and velocities, encoded as color values in textures, and used fragment shaders to update them.

> In graphics hardware terms the input data stream can be represented by a texture, the output data stream by a render target. Output data is often re-used as input in a further processing step. In that case the data streams are textures as well as render targets. The processing kernel is represented by a pixel shader (also called fragment program). By drawing a full-screen rectangle, the graphics hardware is instructed to call the pixel shader once for each output data record, reading from the input stream in the pixel shader.

This article even performed depth sorting of particles using multi-pass merge sort, and has some historically interesting discussion of the difficulties of turning the pixel data back into vertex data at the time (as there was no support for sampling textures in vertex shaders).

> **Comments:**
> **username_3**: Nice to have such an old reference, at the time the article was written I was learning how to tie my shoes!  
> **username_0**: Awesome answer! That really is certainly an old reference, so it surely has been used for quite a long time.  

---

### Answer by username_3 on 2022-10-23. Score: 2

This still happens in constraint platforms like OpenGL ES or the like were there are no compute shaders available and you end up hacking pixel shaders to do general purpose calculations, see any WebGL GPU physics demo and you most probably see ping ponging between fragment shader FBOs to be able to do computations. Or simply go to shadertoy.com and look at any physics/simulation demo. At the end of the day a compute shader ends up being very similar with the difference of it being more general purpose and therefore more tweakable and sometimes more performant for certain tasks.
Would be very nice if some OG could point at a very primitive example or the first time that someone thought that programable GPU programs/shaders were suitable for doing math on non graphics related stuff and did it though.

> **Comments:**
> **username_4**: the floating point power was realized almost immediately I don't have any links but books like the first edition of the "orange" book has some good examples like early attempts at ambient occlusion.  
> **username_3**: would be nice to look at that, when I have some time I might try to find that edition.  
> **username_0**: Thanks for this answer! In my head, it seemed like such an obvious way to do GPGPU without specific libraries like CUDA that I know someone had to be doing it somewhere.  
> **username_5**: I think this happened the other way around.  Computers used to have an optional floating point processor, which was later integrated into the CPU which made it cheaper and more ubiquitous.  The idea that gamers would buy a dedicated floating point processor just made the economy of scale work.  

---

