5 ms·

I'm not well versed in this area at all -- but something I find fascinating is what I have heard of the early days of GPU compute. Before CUDA and the like, yo

I'm not well versed in this area at all -- but something I find fascinating is what I have heard of the early days of GPU compute. Before CUDA and the like, you would apparently take your data you wanted to compute on, structure it as an image/texture and use the graphics API to ham fist your way to the result you wanted. No idea if that's true, but pretty neat if it is.

gh123man 6y ago
This is actually still true in a lot of cases where proper compute shaders are not available - notably webGL. See: https://threejs.org/examples/webgl_gpgpu_birds.html https://threejs.org/examples/webgl_gpgpu_birds.html and: https://github.com/yomboprime/GPGPU-threejs-demos https://github.com/yomboprime/GPGPU-threejs-demos Though WebGPU is coming which I believe will mitigate this.
Qasaur 6y ago
As the other comment mentioned, this is still true if you want to support legacy graphics APIs. A non-negligible amount (~20%) of Android phones cannot execute compute pipelines as they only support OpenGL ES 3.0 - compute shaders were introduced in GLES 3.1. While it is an headache if you want to support compute on legacy devices, I do think that writing regular vertex/fragment shaders for general purpose GPU computation is an underrated pleasure as you really need to break out the coding golf toolkit to squeeze out maximum performance.
- gh123man 6y ago
  To add to this - it's not just legacy/Android devices. Since Apple dropped support for OpenGL in favor of metal, cross platform OpenGL compute shaders are now impossible since iOS will never get OpenGL ES 3.1. This has caused headaches for me as I wrote a cross platform game and am now pinned to GLES 3.0 forever.
raphlinus 6y ago
That works well for certain kinds of computations, basically where each thread can compute a "pixel" independently. Modern GPU compute has threadgroup local storage, subgroups, atomic operations, etc. These unlock huge categories of workloads that would not fit nicely in the rasterization pipeline.
PudgePacket 6y ago
Definitely true :)
greggman3 6y ago
I wouldn't call it ham fist It's really no different than mapping an array except the array is is 2D instead of 1D. You supply data in one or more 2D arrays (textures). You then execute a function (fragment shader) which outputs the values for the result referencing the data in the input arrays (textures). The result is written to another 2D array which just happens to be called a texture instead of "2D array"

gh123man 6y ago

This is actually still true in a lot of cases where proper compute shaders are not available - notably webGL. See: https://threejs.org/examples/webgl_gpgpu_birds.html https://threejs.org/examples/webgl_gpgpu_birds.html and: https://github.com/yomboprime/GPGPU-threejs-demos https://github.com/yomboprime/GPGPU-threejs-demos Though WebGPU is coming which I believe will mitigate this.

Qasaur 6y ago

As the other comment mentioned, this is still true if you want to support legacy graphics APIs. A non-negligible amount (~20%) of Android phones cannot execute compute pipelines as they only support OpenGL ES 3.0 - compute shaders were introduced in GLES 3.1. While it is an headache if you want to support compute on legacy devices, I do think that writing regular vertex/fragment shaders for general purpose GPU computation is an underrated pleasure as you really need to break out the coding golf toolkit to squeeze out maximum performance.

gh123man 6y ago
To add to this - it's not just legacy/Android devices. Since Apple dropped support for OpenGL in favor of metal, cross platform OpenGL compute shaders are now impossible since iOS will never get OpenGL ES 3.1. This has caused headaches for me as I wrote a cross platform game and am now pinned to GLES 3.0 forever.

raphlinus 6y ago

That works well for certain kinds of computations, basically where each thread can compute a "pixel" independently. Modern GPU compute has threadgroup local storage, subgroups, atomic operations, etc. These unlock huge categories of workloads that would not fit nicely in the rasterization pipeline.

PudgePacket 6y ago

Definitely true :)

greggman3 6y ago

I wouldn't call it ham fist It's really no different than mapping an array except the array is is 2D instead of 1D. You supply data in one or more 2D arrays (textures). You then execute a function (fragment shader) which outputs the values for the result referencing the data in the input arrays (textures). The result is written to another 2D array which just happens to be called a texture instead of "2D array"