Dammit. I renamed the RADEON_INFO definitions for the new queries to
0xd, e, f in the kernel tree, but I forgot to update the Mesa code,
which used 0xc, d, e. Sorry.
Marek
On Wed, Feb 26, 2014 at 7:26 PM, Christian König
<deathsimple@xxxxxxxxxxx> wrote:
> Am 26.02.2014 18:56, schrieb Marek Olšák:
>
>> On Mon, Feb 24, 2014 at 5:20 PM, Christian König
>> <deathsimple@xxxxxxxxxxx> wrote:
>>>
>>> Am 24.02.2014 16:20, schrieb Marek Olšák:
>>>
>>>> From: Marek Olšák <marek.olsak@xxxxxxx>
>>>>
>>>> The statistics are:
>>>> - VRAM usage in bytes
>>>> - GTT usage in bytes
>>>> - number of bytes moved by TTM
>>>>
>>>> The last one is actually a counter, so you need to sample it before and
>>>> after
>>>> command submission and take the difference.
>>>>
>>>> This is useful for finding performance bottlenecks. Userspace queries
>>>> are
>>>> also added.
>>>>
>>>> Signed-off-by: Marek Olšák <marek.olsak@xxxxxxx>
>>>> ---
>>>> drivers/gpu/drm/radeon/radeon.h | 5 +++++
>>>> drivers/gpu/drm/radeon/radeon_device.c | 1 +
>>>> drivers/gpu/drm/radeon/radeon_kms.c | 15 ++++++++++++++
>>>> drivers/gpu/drm/radeon/radeon_object.c | 38
>>>> +++++++++++++++++++++++++++++++++-
>>>> drivers/gpu/drm/radeon/radeon_object.h | 2 +-
>>>> drivers/gpu/drm/radeon/radeon_ttm.c | 10 ++++++++-
>>>> include/uapi/drm/radeon_drm.h | 3 +++
>>>> 7 files changed, 71 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/radeon/radeon.h
>>>> b/drivers/gpu/drm/radeon/radeon.h
>>>> index 3f10782..d37a57a 100644
>>>> --- a/drivers/gpu/drm/radeon/radeon.h
>>>> +++ b/drivers/gpu/drm/radeon/radeon.h
>>>> @@ -2307,6 +2307,11 @@ struct radeon_device {
>>>> /* virtual memory */
>>>> struct radeon_vm_manager vm_manager;
>>>> struct mutex gpu_clock_mutex;
>>>> + /* memory stats */
>>>> + struct mutex memory_stats_mutex;
>>>> + uint64_t vram_usage;
>>>> + uint64_t gtt_usage;
>>>> + uint64_t num_bytes_moved;
>>>
>>>
>>> As far as I can see you could make those tree values atomic64_t instead
>>> and
>>> avoid the mutex.
>>
>> I'm afraid I cannot use atomic64_t. It doesn't work on x86 32-bit.
>> This seems to be a no-op:
>>
>> u64 size = (u64)bo->num_pages << PAGE_SHIFT;
>> atomic64_add(size, &rdev->num_bytes_moved);
>
>
> Are you sure about this? Haven't tested x86 32-bit in a long time, but we
> use atomic64 all around the place and they usually work perfectly.
>
> Christian.
>
>> Marek
>
>
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
