> Is the industry working to create a more generalized version of GPUs in the future? Sort of like...PPUs? Parallel processing units? That's what GPUs already

> Is the industry working to create a more generalized version of GPUs in the future? Sort of like...PPUs? Parallel processing units? That's what GPUs already are. GPU compute frameworks like CUDA, ROCm, Sycl, etc make it easy to actually use GPUs for compute, which is what I think all the Big Science people are doing, including the applications I mentioned. If I recall correctly, the Ethereum GPU miner depends on CUDA being installed for NVIDIA graphics cards. There are many, many cosmological simulations that are run almost entirely on the GPU, also CUDA-accelerated. > why is everyone still beholden to the paradigm of shaders? I don't think this has happened since CUDA. Sure, people used to do weird but interesting hacky things like write compute shaders as fragment shaders, which wrote into 2D/3D textures to be subsequently read by the CPU. However, we now actually have GPGPU programming, so it's a bit unconventional to use compute shaders for any serious compute work, unless you do need graphics API integration (DX, OpenGL, Vulkan, etc) for use-cases such as particle and cloth simulations in games. At any rate, shaders are convenient for graphics, because without loss of generality, the overwhelming majority of video games do the same things in the same order. They receive a scene, consisting of: - some geometry - some parameters attached to said geometry (materials, colours, textures, etc) - the lights in said scene - a camera with some parameters (raster resolution, or the 'sensor resolution' of the camera; a viewing frustum, which determines the field of view, the near/far planes, etc) - a list of post-process effects (anti-aliasing, bloom, motion blur, and now upscaling like DLSS) and they tell the GPU to perform the following: - transform and cull/clip the geometry to the camera viewing frustum - rasterise the geometry to fragments, while supplying coordinates of the interpolated primitive, including vertex coordinates, normals, etc, usually supplied as out parameters from a vertex shader - interpolate any parameters, sample any textures in the fragment shader, and colour a pixel - apply post-processing effects, also run as shaders The shader paradigm is very useful, because it allows developers to work per-pixel, in an almost functional-programming manner. If you consider the shader as a gigantic lambda function that is executed per-pixel, having a fixed set of outputs for a fixed set of inputs, then it becomes easy to extend, and do things like forward and deferred rendering, where shaders write to G-buffers, which are then used for inputs for more shaders, and so on. So the GPU is a gigantic map-reduce hardware accelerator, even when using shaders. The only reason dedicated ray-tracing hardware was added to modern GPUs is because ray-tracing completely turns the above pipeline on its head. It involves firing rays out of the camera into the scene, and testing for interesections, which is in essence, solving a giant simultaneous equation. This has a lot of branches and high-precision floating-point maths, which (consumer) GPUs were famously bad at until fairly recently; ergo, the best production ray tracers for feature films (RenderMan, Mitsuba, MoonRay, etc) are still primarily CPU ray-tracers.