[Mesa-dev] [PATCH] state trackers and state changes propagation

Brian Paul brian.e.paul at gmail.com
Sat May 21 08:34:36 PDT 2011

On Fri, May 20, 2011 at 3:03 PM, Pierre-Eric Pelloux-Prayer
<pelloux at gmail.com> wrote:
> Hi,
> I've built several patches trying to reduce the propagation of state changes.
> They are proof-of-concept, and I'd like to know what you think about
> them, mainly :
> - do you think it's worth it ? it adds complexity to state trackers,
> but it avoids some possibly expensive driver function calls.
> - if yes, what would you be the best design approach for this ?

In principle these are good ideas, but the patches are way too rough
to be committed as-is.

In patch 0001:
How reliable is the "total" checksum value?  If two different constant
buffer hash to the same value, that would be a problem.
BTW, static vars should not be used like that.  They're not
multi-context safe.  Add a per-context field instead.

In patch 0002:
This is look kind of clumsy.  A better approach might be to keep a
pipe_rasterizer object in the st_context and update it incrementally.
Where there's comments like /*_NEW_POLYGON *, those could be made into
conditionals to skip state groups that haven't changed.  Same thing
for other CSO objects.

In patch 0003:
Use 'boolean', 'TRUE' and 'FALSE'.  Follow the current coding style w/
respect to braces, etc.  Don't declare variables after code. Reindent
code when you move it into a conditional.

In patch 0004:
We don't want to make the private CSO data structures public.  That
could lead to a mess in the future.
One thing we could do in the CSO module is keep track of the previous
state object and compare it to the new one being given to us.  If it's
the same, we're done and can skip the hash table lookup.  We'd have to
be careful and make measurements to see if that's a win.


More information about the mesa-dev mailing list