On Fri, May 20, 2011 at 3:03 PM, Pierre-Eric Pelloux-Prayer <pell...@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. -Brian _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
