On Friday, October 11, 2013 11:39:53 AM Eric Anholt wrote: > As a general rule, we don't land code whose purpose is performance > improvement if it doesn't actually improve performance. If more work is > needed to make it actually improve performance, then we wait until then. > > As I understand it, the thing that you think will make this eventually > actually improve performance is state flagging that indicates which > individual surfaces need updating. Since that should improve > performance even in the non-resource-streamer case, it can be pursued > independently.
One optimization idea that I had in mind a few months ago was to find a way to reduce emission of surface state objects. Currently, we rebuild surface states every time we generate binding tables. The idea is to basically relocate the surface state indirect state objects on a separate buffer object from the command batch. Using the resource streamer, we can then publish the deltas when indices referring to them needs to be changed. So whenever a surface needs to be used, instead of rebuilding the whole binding table structure the driver can essentially say on a per-slot basis "hey a surface got activated but it it was previously bound to index 10, lets rebind it to index 12". This potentially reduces the CPU overhead of generating and uploading binding tables. I did a previous experiment and found out that it reduced generation of surfaces states to as much as 99% with this approach. What do you think? Abdiel _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
