[Mesa-dev] [PATCH 1/4] r600g, radeonsi: force VRAM placement for DRI2 buffers

[Axel Davy]

I don't know of any way to know if the buffer should be in GTT.

There could also be the case where the buffer is first not shared with 
another device,
and then is shared with another device. So at first we shouldn't have 
forced the buffer to stay in VRAM.

Just to confirm, I have tested your patch as is with my Wayland Prime 
patches, and as expected it doesn't work well anymore.

Axel Davy

On 03/02/2014, Marek Olšák wrote :
> Well, it's kinda obvious what would happen. The buffer would be
> relocated to VRAM.
>
> Do you have any suggestion how to find out if the buffer should be in
> GTT instead?
>
> Marek
>
> On Mon, Feb 3, 2014 at 12:13 AM, Axel Davy <axel.davy at ens.fr> wrote:
>>> From: Marek Olšák <marek.olsak at amd.com>
>>>
>>> ---
>>> src/gallium/drivers/radeon/r600_texture.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/src/gallium/drivers/radeon/r600_texture.c
>>> b/src/gallium/drivers/radeon/r600_texture.c
>>> index f80a6a2..434a651 100644
>>> --- a/src/gallium/drivers/radeon/r600_texture.c
>>> +++ b/src/gallium/drivers/radeon/r600_texture.c
>>> @@ -668,7 +668,7 @@ r600_texture_create_object(struct pipe_screen *screen,
>>> 	} else {
>>> 		resource->buf = buf;
>>> 		resource->cs_buf = rscreen->ws->buffer_get_cs_handle(buf);
>>> -		resource->domains = RADEON_DOMAIN_GTT | RADEON_DOMAIN_VRAM;
>>> +		resource->domains = RADEON_DOMAIN_VRAM;
>>> 	}
>>>
>>> 	if (rtex->cmask.size) {
>>> --
>>> 1.8.3.2
>> If I understand correctly, this code is always executed after importing a
>> buffer with an handle, a Gem name or a prime fd.
>>
>> Given the imported buffer can be shared with another card (in the prime fd
>> case), I imagine there are some cases where the buffer must stay in GTT.
>>
>> What would happen in this case with your patch?
>>
>>
>> Axel Davy