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