-
-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revisit Render/DrawFunction Design #5117
Comments
What I'm going to write doesn't contradict what you have written. Hopefully it just clarifies my perspective on it. :) Instancing, batching, bindless, and GPU-driven rendering address overall rendering performance. I'd express it as they don't improve the performance of the render graph node code that create passes and encode the draw commands, rather they just reduce the amount of work for the render graph nodes to do, one way or another. Because it is not always possible to use those approaches for various reasons, I think we should both look into those approaches (which I intend to do) and try to optimise the current situation of one draw per mesh. |
|
With the efforts in batching and parallelization, this is no longer the biggest bottleneck when rendering. Closing out as no longer planned. |
What problem does this solve or what need does it fill?
After a round of optimizations for rendering and ECS in general, the render phase is now the largest CPU-side bottleneck when rendering more complex scenes. Speeding up the render phase is central to having a performant rendering pipeline.
What solution would you like?
DrawFunctions incur the following costs as unavoidable overhead.
Box<dyn Draw>
.These costs are mitigated via CPU caching and SystemState/QueryState level checks, but ideally, these costs should be moved out of the hot loop and into a preparation stage of some kind. What form this takes may not be too clear given the constraints the phase is operating under.
What alternative(s) have you considered?
All of these are orthogonal approaches for chunking/splitting/speeding up the phase:
Query::get
.The text was updated successfully, but these errors were encountered: