DispatchIndirect, GPU Particles and other stuff!

[al2950]

Hi all

After being inspired by Wicked engine's blog on GPU particles I decided use it as an excuse to delve into compute shaders and look at the possibility of adding a modern GPU based particle system to Ogre over Christmas where I hope to have some free time!

There are however some barriers in Ogre I need to overcome. Firstly there is no DispatchIndirect just Dispatch. Although it is possible to use just dispatch it would be much nicer and faster to use DispatchIndirect. So I have 2 questions surrounding it

• It would not be too hard to add this to the render systems, but not sure how it would be integrated with the compositor and script system
• The GPU particle simulation has a number of steps, should these steps be written individually as individual passes in the compositor. OR should I create a new pass type (ParticleSystem) This would be easier as I could add DispatchIndirect to the render systems and call them directly without worrying about how to add to the compositor script system. It would also be much easier for other people to add to their engines.

I believe the rest should be simple, I will of course have a separate HLMS for the particle system, and I particularly like the way Wicked Engine blog avoids the use of geometry shaders. But this may required some fudging of Ogre command buffers and VAOs, but this is further down the road.

Anyway any comments appreciated as always

[dark_sylinc]

There are however some barriers in Ogre I need to overcome. Firstly there is no DispatchIndirect just Dispatch. Although it is possible to use just dispatch it would be much nicer and faster to use DispatchIndirect. So I have 2 questions surrounding it

• It would not be too hard to add this to the render systems, but not sure how it would be integrated with the compositor and script system

There's three things that make up a compute shader in Ogre:

• HlmsComputJob (aka job). This is similar to a material. You can bind textures and UAVs to it.
  Set uniform parameters, bind const buffers, etc. The shader code lives here. Jobs setup the arguments for dispatch call. These settings are copied to the compute pso.
• HlmsCompute: it manages all the jobs, and parses them if they have changed. Think of it similar to a material manager. It performs the actual call to dispatch, based on job's settings.
• Compute pass. This is from the compositor. It is not strictly necessary. For example mipmaps generation pass can use compute shaders if set with compute_hq setting, without needing a compute pass from the compo.

Compositor passes have been supporting uav buffers for a while now. It should be totally possible to extend the compositor to accept an uav buffer and an offset argument in bytes to act as indirect param. The compute pass would tell the job, and HlmsCompute would carry that over to the pso, executing a dispatch indirect instead.

• The GPU particle simulation has a number of steps, should these steps be written individually as individual passes in the compositor. OR should I create a new pass type (ParticleSystem) This would be easier as I could add DispatchIndirect to the render systems and call them directly without worrying about how to add to the compositor script system. It would also be much easier for other people to add to their engines.

That depends on configurability / complexity. I suggest you take a look at generate_mipmaps, which executes the jobs directly since using multiple compo passes would've been extremely cumbersome. Textures with more mips required more passes, for instance. Which is something that cannot be done via scripts easily.
Note that you should not directly call dispatch indirect from the compositor pass. You should extend HlmsComputeJob to inform it wants to use indirect, and HlmsCompute should honour that.

Cheers

[al2950]

Great, thanks for the details. All makes sense, the generate_mipmaps was a particular useful nuget of info.

One last (maybe) question. The UAV which is used for the indirect buffer and is written to the in compute shaders needs to be used to actually draw objects. At the moment Ogre's render code uses indirect buffers but in very specific way, which is not UAV and is uploaded from CPU potentially each frame with data generated the render queue.

So, I was originally thinking/wanting to generate a renderable which could just be used in render scene pass to render a particle. However thats going to be difficult without doing a lot of work on Ogre's current implementation of IndirectBuffers (atleast form my current understanding). The other way of doing it is interacting with the command buffers directly, although I think even that may need some changes.

This area of Ogre's code, render queue, command buffer & auto instancing stuff, is a little hard to follow so I may need some help if its going to need some big changes. Ill crack on in December and call the render systems directly for now, as it would appear a number of poeple are very interested in have something like this implemented.

Thanks