Offloading stuff to GPU (Gaming)

by uberfoop , Seattle-ish, Thursday, May 25, 2017, 18:47 (2743 days ago) @ dogcow

Do console GPUs have that integrated now?

It's not really a hard barrier where one moment you can't do stuff and the next you can. The question is what you can offload to where and how efficiently, and with how much development effort.

The GPU in the Xbox 360 only nominally supported rendering tasks. That is (roughly speaking and I'm leaving all kinds of stuff out), you'd submit a piece of geometry, GPU would sample textures, GPU would calculate per-pixel results based on user-defined shader program, then output per-pixel results to an image.
But there's nothing stopping you from architecting, within that framework, a task that isn't actually a rendering task, and then having the GPU run it.

So, perhaps your "geometry" is actually a proxy for an array of particle data (position, velocity, particle type, etc). The "textures" that you have the GPU sample are actually just the particle data from the array. Each "pixel" you output is, once again, the particle data, but now updated with new trajectory. The "image" you're creating is just a new array of particle data.
To detect collisions, you can have the GPU also sample the depth/normal buffers of the main scene at the on-screen location of each particle. If the particle's trajectory "intersects the depth buffer", you can calculate a bounce, or do some other thing based on particle type (like a raindrop particle might turn into a water splash particle).

That's exactly what Bungie was doing back in Halo Reach, to be able to process huge numbers of particles for cheap. It's got some limitations, like particles can't interact with any geometry other than what's on-screen and forward-facing (since it's literally just using the on-screen content as the definition for collision geometry), but with things like raindrops and sparks, people usually don't notice the quirks in the system. (Reach still handles some particles CPU-side.)