[Mesa-dev] [PATCH 1/2] r600g, radeonsi: query the buffer domain from the kernel for DRI2 buffers
Michel Dänzer
michel at daenzer.net
Wed Feb 5 08:37:32 CET 2014
On Mit, 2014-02-05 at 00:01 +0100, Marek Olšák wrote:
> From: Marek Olšák <marek.olsak at amd.com>
>
> Better then guessing it.
>
> Yeah we have had this query for a long time...
[...]
> diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
> index 2ac060b..7c59f26 100644
> --- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
> +++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
> @@ -201,6 +201,28 @@ static boolean radeon_bo_is_busy(struct pb_buffer *_buf,
> }
> }
>
> +static enum radeon_bo_domain radeon_bo_get_current_domain(struct pb_buffer *_buf)
> +{
> + struct radeon_bo *bo = get_radeon_bo(_buf);
> + struct drm_radeon_gem_busy args;
> +
> + memset(&args, 0, sizeof(args));
> + args.handle = bo->handle;
> +
> + drmCommandWriteRead(bo->rws->fd, DRM_RADEON_GEM_BUSY,
> + &args, sizeof(args));
> +
> + /* Zero domains the driver doesn't understand. */
> + args.domain &= ~(RADEON_GEM_DOMAIN_VRAM | RADEON_GEM_DOMAIN_GTT);
> +
> + /* If no domain is set, we must set something... */
> + if (!args.domain)
> + args.domain = RADEON_GEM_DOMAIN_VRAM | RADEON_GEM_DOMAIN_GTT;
> +
> + /* GEM domains and winsys domains are defined the same. */
> + return args.domain;
> +}
The problem with this is that DRM_RADEON_GEM_BUSY doesn't say where the
BO is supposed to be, but where it happens to be right now. E.g. it
could return GTT for a BO that's supposed to be in VRAM but was evicted
(or couldn't get into VRAM in the first place).
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
More information about the mesa-dev
mailing list