[Mesa-dev] [RFC]Improves st_finalize_texture cycles consumption

[Brian Paul]

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 at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev