[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