I don't really care for these patches. They obfuscate the code and
hide the real issue which Keith touched on. We need to have some sort
of additional dirty tracking logic to determine when there's no real
changes to the pipe_resource for a texture.
One of the things on my to-do list is to re-examine how we track
changed state to handle state changes more efficiently.
-Brian
On 01/08/2012 04:04 PM, Keith Whitwell wrote:
I don't have the code handy (and haven't looked at it in a while), but wonder
if finer-grained tracking of dirtiness would help? Or more generally trying to
preserve more computed results across state changes?
Keith
----- Original Message -----
Hi,
I did some profiling with perf under nexuiz and found that
st_finalize_texture
function was one of the most cycle consumming. (~1,50% whereas
darkplaces took ~30%)
I rewrite some part of this function to make it a bit faster ; with
these 2 patches,
st_finalize_texture consumption went down to ~1%, so a 40-50% boost.
This does however not translate to more fps to Nexuiz : if there is
any improvement,
it is not noticeable (too much noise in measurements). On the other
hand, the function
has become less readable. I had to manually unroll loops and use
intermediate values
(gcc does not do it automaticaly, using default parameters).
Of course I think that we should make less call to this function to
see a true gain,
but this would require more work.
Regards,
Vincent
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
