Gpu Driven Rendering By Default

[DrewRidley]

Performant Rendering

the default gpu pipeline used in bevy should be one that takes in to consideration concepts from guides like this https://vkguide.dev/docs/gpudriven/gpu_driven_engines/. In this way, bevy can render objects with extreme performance, and will never bottleneck on the cpu. In general, GPU Driven Rendering has some tradeoffs that would need to be made, but would increase performance, sustainability, and would enhance any future efforts to include ray-tracing and other novel tech.

[twitchyliquid64]

Im pretty sure Bevy already uses the GPU @DrewDaPilot ?

[bjorn3]

According to the article the idea is to compute what to draw on the GPU instead of CPU and then use an indirect draw call to actually draw what was computed. Webgpu probably doesn't have support for this.

[twitchyliquid64]

The article link is broken. Got it working with some copypasta. Heres a direct link.

The idea is to compute what to draw on the GPU instead of CPU

Bevy does this

then use an indirect draw call to actually draw what was computed

Could you be more specific? If you mean scan out, this is already quite efficient on most systems - compositors rarely copy around rasters like the old days.

[twitchyliquid64]

Ohhh, based on the article i think the OP is talking about supporting the approach where compute shaders generate most/all of the graphics, in lieu of shipping big buffers back and forth from the CPU.

[cart]

Yeah theres plenty of room for offloading more work to the gpu in Bevy. The big issue (in the short term) is that those techniques don't work well or at all on some platforms/apis (ex: webgl and older hardware). So in the short term while we sort out the core render apis I'd prefer to use more universally compatible techniques. This helps the codebase stay lean and easy to refactor. Engines like Bevy should be able to run everywhere by default and that will take precedence over squeezing every ounce of performance from each individual platform.

In the medium term when the renderer has stabilized, we can start specializing to squeeze the most out of each platform. We're already using modern apis, so this should be a "high level addition", not a major rewrite of everything.

Fortunately theres nothing stopping people from forging on ahead now. Its just not something I'm ready to invest in or maintain (yet)

[DrewRidley]

That's a fair argument to be made, however, even WebGL can support GPU driven rendering through the use of vertex and fragment shaders. As for IOS/Android, compute shaders are usually a thing if the OpenGL ES version is 3.1 or above, but a gpu driven pipeline can exist without compute shaders. I think it's at least worth looking into and investigating the feasibility.

[bjorn3]

While compute shaders can be emulated using vertex and fragment shaders, GPU driven rendering needs the draw indirect command to actually draw the generated drawlist. This is command is only supported by OpenGL with the extension ARB_draw_indirect, which requires OpenGL 3.1 or in the core with OpenGL 4.0. For WebGL neither version 1, nor version 2 provide it as part of the core or even as extension. This means that it is simply impossible to use GPU driven rendering with WebGL.

[DrewRidley]

Fair enough, so maybe WebGL support would be finicky or impossible in the short term, but I think in the long-term WebGL will probably support such features when it updates to OpenGL ES 3.2. But I digress, I think it's still worth considering the extra performance on compatible platforms. I think it's fair to say that it's worth implementing since every platform supports indirect draw calls (except for WebGL).

[bjorn3]

but I think in the long-term WebGL will probably support such features when it updates to OpenGL ES 3.2

If we don't get WebGPU before then.