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.d...@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.2If 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
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
