forked from baldurk/renderdoc
-
Notifications
You must be signed in to change notification settings - Fork 0
Optimisation
Baldur Karlsson edited this page Jan 14, 2015
·
1 revision
This page is about potential future optimisations for RenderDoc. If you want to use RenderDoc to optimise something else, then look elsewhere!
This is mostly a braindump but I might expand on these later
Ideas for improving the core replay loop
- Checking for read/write clashes is a lot of overhead - where binding something for input sets NULL instead because the resource is bound for output, or vice-versa unbinding a resource for read because we're binding it as write. Relatively speaking this is very rare, compared to us checking every bind individually for this. Probably the best way to do this is to cache the results of the checks somehow after the first replay. smallish change
- Really to be most optimal, the first serialise should actually write out an optimised command stream with resource pointers instead of IDs. That way on subsequent runs we don't have to re-serialise, translate IDs, check for validity and everything else, but instead just play back a very fast command stream on the live resources. huge change