Re: Improve state emitting for ipers

[Roland S. <rsc...@hi...>]

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 like it ;-). I thought the locking really to be inefficient (but never 
did anything against it...).

> 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 was not always that inefficient in r200EmitState, only since the 
fixed emit order was introduced (and still no one understands why the 
fixed order is needed). Didn't seem to make a performance difference 
though (profiling showed it really didn't use much cpu time).

> 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 certainly think it's a good idea.
However, I still think it should be possible to lock across multiple 
buffers, to make it possible to emit larger numbers of vertices at once 
(for instance for things like glDrawElements), which, as far as I 
understand, just cannot work if you're restricted to one buffer.

Roland