[PATCH 2/6] drm/radeon: track memory statistics about VRAM and GTT usage and buffer moves (original) (raw)

Marek Olšák maraeo at gmail.com
Wed Feb 26 16:39:50 PST 2014


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 at vodafone.de> wrote:

Am 26.02.2014 18:56, schrieb Marek Olšák:

On Mon, Feb 24, 2014 at 5:20 PM, Christian König <deathsimple at vodafone.de> wrote:

Am 24.02.2014 16:20, schrieb Marek Olšák:

From: Marek Olšák <marek.olsak at amd.com>

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 at amd.com> --- drivers/gpu/drm/radeon/radeon.h | 5 +++++ drivers/gpu/drm/radeon/radeondevice.c | 1 + drivers/gpu/drm/radeon/radeonkms.c | 15 ++++++++++++++ drivers/gpu/drm/radeon/radeonobject.c | 38 +++++++++++++++++++++++++++++++++- drivers/gpu/drm/radeon/radeonobject.h | 2 +- drivers/gpu/drm/radeon/radeonttm.c | 10 ++++++++- include/uapi/drm/radeondrm.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 radeondevice { /* virtual memory */ struct radeonvmmanager vmmanager; struct mutex gpuclockmutex; + /* memory stats */ + struct mutex memorystatsmutex; + uint64t vramusage; + uint64t gttusage; + uint64t numbytesmoved;

As far as I can see you could make those tree values atomic64t instead and avoid the mutex. I'm afraid I cannot use atomic64t. It doesn't work on x86 32-bit. This seems to be a no-op: u64 size = (u64)bo->numpages << PAGESHIFT;_ _atomic64add(size, &rdev->numbytesmoved); 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



More information about the dri-devel mailing list