[Mesa-dev] [PATCH 1/2] r600g, radeonsi: query the buffer domain from the kernel for DRI2 buffers

[Christian König]

Am 05.02.2014 10:57, schrieb Michel Dänzer:
> On Mit, 2014-02-05 at 10:13 +0100, Christian König wrote:
>> Am 05.02.2014 08:37, schrieb Michel Dänzer:
>>> On Mit, 2014-02-05 at 00:01 +0100, Marek Olšák wrote:
>>>> 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).
>> But isn't that exactly what we want here?
> Not really. E.g. consider an app's DRI2 front buffer (i.e. normally the
> backing pixmap of an X11 window): If the BO happens to be in GTT when
> DRM_RADEON_GEM_BUSY is called from the compositor, the compositor will
> force the BO to GTT every time it uses the BO for rendering. But the
> app's DRI2 buffer swap (or any other accelerated rendering to the window
> in the X server) will force the BO to VRAM. BO ping pong.

Oh, yeah that makes sense. Instead of defining where the buffer should 
be on command submission we should rather define how badly we want to 
move it around. No good idea either how to handle this without a kernel 
interface rework.

Christian.