Eric Anholt wrote:
The attached patch removes the mandatory emits of all state which were
happening after each cmdbuf flush.  Instead, we set a flag after a
cmdbuf flush saying "save the state at the next unlock," which means
memcpying the state atoms off.  When we actually see the context get
lost, then we "back up" and restore state -- make a new cmdbuf, dirty
all state, emit it, flush it, then put the old cmdbuf back.  I also
removed the dirty/clean state lists and made a single one.  The
reasoning was that we have to walk the entire list on emit (and twice
when the all-dirty is set) anyway, and I felt that this was cleaner.  It
also fixed some bad cmdbufs that were happening for me (drmCommandWrite:
-22) with the CVS code.

This gets about a 5% speedup for me in ipers (which I wish was more
accurate in its reporting), and doesn't touch glxgears.  I didn't have
any interesting apps besides glxgears handy to benchmark with.  Any
thoughts on this?  If people think it's a good idea, I'll do it for
radeon as well.

I like the approach. As there's nothing special about cmdbuf's - they're just regular memory, there's no reason not to be more dynamic about how we deal with them.


Keith


------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to