Games in the GPU Shaders (2021)
arugl.medium.com
arugl.medium.com
There are things you can do with shaders that might be useful for games. For example large simulations. But in generally, getting a game to work the way they work on ShaderToy is a fun puzzle but extremely inefficient and slow.
They are actually very limited, because a GPU does not work, like many cpus in parallel (how I initially assumed).
So you will be limited and restricted in everything you do, making every step painful.
The trick is to find the parts that can be offloaded to the GPU - and come calculated back at the right time.
Games are usually performance critical - and communicating between the GPU and CPU can induce lots of lags as the coordination is tricky and not really under your control.
This is how I understood GPUs. What's a better way to understand them?
What is optimised for parallelism, is not optimised for single thread performance, which is what one expects out of a CPU ..
Simulations commonly target GPU, and a game is just an interactive simulation, so in some respect it's straightforward to write games for GPU. From a utilization perspective, you'll need minimally tens of thousands of dynamic game entities, which is one among many reasons why it's uncommon.
Even if consider shaders, just new way to run C programs, they have totally different ground - another RAM organization, another variable types than CPU (or even GPU), another variables visibility (and special methods to deal with it), some very special limitations (on code size, on exec time), and non-guaranteed RAM integrity (yes, for VRAM is normal to lost data).
What I see, IF you could fit there, you will got at least one additional high-end CPU core speed for free, even on integrated graphics (for example, nearly all game examples successfully run on intel 630 GPU, and as I understand, CPU there used only to transfer data in-out and to JIT compile).