[Mesa-dev] [PATCH 3/4] winsys/radeon: Keep bo statistics

Marek Olšák maraeo at gmail.com
Wed Jan 8 11:33:54 PST 2014


On Wed, Jan 8, 2014 at 7:54 PM, Lauri Kasanen <cand at gmx.com> wrote:
> On Wed, 8 Jan 2014 19:03:53 +0100
> Marek Olšák <maraeo at gmail.com> wrote:
>
>> On Wed, Jan 8, 2014 at 6:21 PM, Lauri Kasanen <cand at gmx.com> wrote:
>> > On Wed, 8 Jan 2014 15:54:04 +0100
>> > Marek Olšák <maraeo at gmail.com> wrote:
>> >> It's not accurate at all, it's actually pretty random. The stats
>> >> should not be called "num_reads" and "num_writes", they should be
>> >> called "num_state_changes", and the number of resource state changes
>> >> has nothing to do with how the resources affect GPU performance. You
>> >> might get a pretty high score for unimportant resources with your
>> >> approach. It's as useful as assigning a random number to each
>> >> resource.
>> >
>> > Yes, more accurate names would be "times_bound_for_reads" and
>> > "times_bound_for_writes", but those are too long names for my taste ;)
>>
>> Yeah, and those 2 are completely useless, because the number of times
>> a resource is bound is irrelevant and won't help us in any way. Like I
>> said, you could just assign a random number to "times_bound_for_*" in
>> radeon_drm_cs_flush and it would perform the same or better, because
>> random statistics are better than bad statistics.
>
> Can you elaborate? How often does an app bind a texture without
> bothering to read from it? The engines I've worked with take care to
> unbind textures they are not using.
>
> The read pattern is half, but the fact that it's being read is the
> other half of the equation.

I think you misunderstood what I had said. Please read my emails again.

BTW if you just need to know if a resource has been used for read or
write, you can check (radeon_cs_context::relocs[i]->read_domains != 0)
and (radeon_cs_context::relocs[i]->write_domain != 0). These are the
stats that the kernel gets, but the kernel doesn't use them for
anything useful.

Marek


More information about the mesa-dev mailing list