Am 05.02.2014 08:37, schrieb Michel Dänzer:
On Mit, 2014-02-05 at 00:01 +0100, Marek Olšák wrote:
From: Marek Olšák <marek.ol...@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).
But isn't that exactly what we want here?
Christian.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
