From: Ian Romanick ian.d.romanick@intel.com
The drm_intel_context structure is, wisely, opaque. However, libdrm users may want to know the hardware context ID associated with the structure.
Signed-off-by: Ian Romanick ian.d.romanick@intel.com Cc: Ben Widawsky ben@bwidawsk.net --- intel/intel_bufmgr.h | 1 + intel/intel_bufmgr_gem.c | 6 ++++++ 2 files changed, 7 insertions(+)
diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h index 15f818e..7b28a70 100644 --- a/intel/intel_bufmgr.h +++ b/intel/intel_bufmgr.h @@ -194,6 +194,7 @@ drm_intel_context *drm_intel_gem_context_create(drm_intel_bufmgr *bufmgr); void drm_intel_gem_context_destroy(drm_intel_context *ctx); int drm_intel_gem_bo_context_exec(drm_intel_bo *bo, drm_intel_context *ctx, int used, unsigned int flags); +unsigned int drm_intel_gem_context_get_hw_context_id(const drm_intel_context *);
int drm_intel_bo_gem_export_to_prime(drm_intel_bo *bo, int *prime_fd); drm_intel_bo *drm_intel_bo_gem_create_from_prime(drm_intel_bufmgr *bufmgr, diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c index 029ca5d..5b64a7f 100644 --- a/intel/intel_bufmgr_gem.c +++ b/intel/intel_bufmgr_gem.c @@ -3020,6 +3020,12 @@ drm_intel_gem_context_destroy(drm_intel_context *ctx) free(ctx); }
+unsigned int +drm_intel_gem_context_get_hw_context_id(const drm_intel_context *ctx) +{ + return ctx->ctx_id; +} + int drm_intel_reg_read(drm_intel_bufmgr *bufmgr, uint32_t offset,
From: Ian Romanick ian.d.romanick@intel.com
Previously GCC was squaking about:
intel_bufmgr_gem.c: In function 'drm_intel_gem_bo_map_unsynchronized': intel_bufmgr_gem.c:1325:20: warning: unused variable 'bo_gem' [-Wunused-variable]
Wrapping with VG(); replaced that warning with:
intel_bufmgr_gem.c: In function 'drm_intel_gem_bo_map_unsynchronized': intel_bufmgr_gem.c:1326:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
Which, looking at the definition of the VG macro, seems a bit weird. It's caused by the dangling ";" left from the empty macro.
Signed-off-by: Ian Romanick ian.d.romanick@intel.com Cc: Chia-I Wu olvaffe@gmail.com --- intel/intel_bufmgr_gem.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c index 5b64a7f..dbadc52 100644 --- a/intel/intel_bufmgr_gem.c +++ b/intel/intel_bufmgr_gem.c @@ -1322,7 +1322,9 @@ int drm_intel_gem_bo_map_gtt(drm_intel_bo *bo) int drm_intel_gem_bo_map_unsynchronized(drm_intel_bo *bo) { drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo->bufmgr; +#ifdef HAVE_VALGRIND drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo; +#endif int ret;
/* If the CPU cache isn't coherent with the GTT, then use a
Ian Romanick idr@freedesktop.org writes:
From: Ian Romanick ian.d.romanick@intel.com
The drm_intel_context structure is, wisely, opaque. However, libdrm users may want to know the hardware context ID associated with the structure.
We've had a bunch of our other structures be partially transparent. The context id to be passed to the kernel could easily be public just like the gem handle in a BO is public. I would lean slightly toward that.
But I don't feel strongly either way, so these two are:
Reviewed-by: Eric Anholt eric@anholt.net
On Mon, Nov 11, 2013 at 11:58:59AM -0800, Eric Anholt wrote:
Ian Romanick idr@freedesktop.org writes:
From: Ian Romanick ian.d.romanick@intel.com
The drm_intel_context structure is, wisely, opaque. However, libdrm users may want to know the hardware context ID associated with the structure.
We've had a bunch of our other structures be partially transparent. The context id to be passed to the kernel could easily be public just like the gem handle in a BO is public. I would lean slightly toward that.
But I don't feel strongly either way, so these two are:
Reviewed-by: Eric Anholt eric@anholt.net
I think my preference would be to add a "context" argument to a libdrm get_hangstats function, but if you feel this way is better, it is fine with me.
My only [slight, unjustified] concern is that once you make the id transparent, we can't play any games. Since the DDX doesn't use libdrm however, I think it is fairly moot.
Acked-by: Ben Widawsky ben@bwidawsk.net
dri-devel@lists.freedesktop.org