* patches for occlusion query fix on sandybridge
@ 2010-12-14 4:55 Zhenyu Wang
2010-12-14 4:56 ` [PATCH] drm/i915: Add cached bo create interface Zhenyu Wang
` (4 more replies)
0 siblings, 5 replies; 11+ messages in thread
From: Zhenyu Wang @ 2010-12-14 4:55 UTC (permalink / raw)
To: intel-gfx
It appears Sandybridge PIPE_CONTROL write out buffer need
to be set as cached, currently LLC cached, in order to read
back correct counter. Otherwise I can always be possible to
get corrupted 64-bit PS_DEPTH_COUNT from PIPE_CONTROL write.
So below patches try to add new flag during bo create with
cacheable type, to be sure that GTT entry's cache bits would
be setup for that.
This fixes occlusion query piglit test and mesa demos on my
sandybridge. Note that below patches don't include necessary
component version check changes.
thanks.
^ permalink raw reply [flat|nested] 11+ messages in thread* [PATCH] drm/i915: Add cached bo create interface 2010-12-14 4:55 patches for occlusion query fix on sandybridge Zhenyu Wang @ 2010-12-14 4:56 ` Zhenyu Wang 2010-12-14 4:56 ` [PATCH] intel: new interface for cached bo create Zhenyu Wang ` (3 subsequent siblings) 4 siblings, 0 replies; 11+ messages in thread From: Zhenyu Wang @ 2010-12-14 4:56 UTC (permalink / raw) To: intel-gfx Some BO is required to have cached attribute in GTT, e.g PIPE_CONTROL store DW buffer used for occlusion query function. This one adds new flags for that within bo create ioctl. Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> --- drivers/gpu/drm/i915/i915_dma.c | 3 +++ drivers/gpu/drm/i915/i915_gem.c | 4 ++++ include/drm/i915_drm.h | 5 ++++- 3 files changed, 11 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index e9fb895..df5a248 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -778,6 +778,9 @@ static int i915_getparam(struct drm_device *dev, void *data, case I915_PARAM_HAS_COHERENT_RINGS: value = 1; break; + case I915_PARAM_HAS_CREATE_CACHED: + value = 1; + break; default: DRM_DEBUG_DRIVER("Unknown parameter %d\n", param->param); diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 27fa2a1..8bc5d05 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -216,6 +216,10 @@ i915_gem_create_ioctl(struct drm_device *dev, void *data, return ret; } + /* Setup required CPU cached bit for bo, e.g query obj */ + if (args->flags == DRM_I915_GEM_CREATE_CACHED) + obj->agp_type = AGP_USER_CACHED_MEMORY; + /* drop reference from allocate - handle holds it now */ drm_gem_object_unreference(&obj->base); trace_i915_gem_object_create(obj); diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h index a2776e2..b34db99 100644 --- a/include/drm/i915_drm.h +++ b/include/drm/i915_drm.h @@ -289,6 +289,7 @@ typedef struct drm_i915_irq_wait { #define I915_PARAM_HAS_BLT 11 #define I915_PARAM_HAS_RELAXED_FENCING 12 #define I915_PARAM_HAS_COHERENT_RINGS 13 +#define I915_PARAM_HAS_CREATE_CACHED 14 typedef struct drm_i915_getparam { int param; @@ -370,6 +371,8 @@ struct drm_i915_gem_init { __u64 gtt_end; }; +#define DRM_I915_GEM_CREATE_CACHED 1 + struct drm_i915_gem_create { /** * Requested size for the object. @@ -383,7 +386,7 @@ struct drm_i915_gem_create { * Object handles are nonzero. */ __u32 handle; - __u32 pad; + __u32 flags; }; struct drm_i915_gem_pread { -- 1.7.1 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH] intel: new interface for cached bo create 2010-12-14 4:55 patches for occlusion query fix on sandybridge Zhenyu Wang 2010-12-14 4:56 ` [PATCH] drm/i915: Add cached bo create interface Zhenyu Wang @ 2010-12-14 4:56 ` Zhenyu Wang 2010-12-14 9:35 ` Chris Wilson 2010-12-14 4:56 ` [PATCH] i965: alloc cached bo for query object on Sandybridge Zhenyu Wang ` (2 subsequent siblings) 4 siblings, 1 reply; 11+ messages in thread From: Zhenyu Wang @ 2010-12-14 4:56 UTC (permalink / raw) To: intel-gfx This is required for special bo like PIPE_CONTROL store DW buffer used in occlusion query. Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> --- include/drm/i915_drm.h | 5 ++++- intel/intel_bufmgr.h | 3 +++ intel/intel_bufmgr_gem.c | 38 +++++++++++++++++++++++++++++++++++++- 3 files changed, 44 insertions(+), 2 deletions(-) diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h index 19da2c0..a0b97cf 100644 --- a/include/drm/i915_drm.h +++ b/include/drm/i915_drm.h @@ -279,6 +279,7 @@ typedef struct drm_i915_irq_wait { #define I915_PARAM_HAS_BSD 10 #define I915_PARAM_HAS_BLT 11 #define I915_PARAM_HAS_RELAXED_FENCING 12 +#define I915_PARAM_HAS_CREATE_CACHED 14 typedef struct drm_i915_getparam { int param; @@ -360,6 +361,8 @@ struct drm_i915_gem_init { __u64 gtt_end; }; +#define DRM_I915_GEM_CREATE_CACHED 1 + struct drm_i915_gem_create { /** * Requested size for the object. @@ -373,7 +376,7 @@ struct drm_i915_gem_create { * Object handles are nonzero. */ __u32 handle; - __u32 pad; + __u32 flags; }; struct drm_i915_gem_pread { diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h index e1b4c45..17a2d3b 100644 --- a/intel/intel_bufmgr.h +++ b/intel/intel_bufmgr.h @@ -84,6 +84,7 @@ struct _drm_intel_bo { }; #define BO_ALLOC_FOR_RENDER (1<<0) +#define BO_ALLOC_FORCE_CACHED (1<<1) drm_intel_bo *drm_intel_bo_alloc(drm_intel_bufmgr *bufmgr, const char *name, unsigned long size, unsigned int alignment); @@ -97,6 +98,8 @@ drm_intel_bo *drm_intel_bo_alloc_tiled(drm_intel_bufmgr *bufmgr, uint32_t *tiling_mode, unsigned long *pitch, unsigned long flags); +drm_intel_bo *drm_intel_gem_bo_alloc_cached(drm_intel_bufmgr *bufmgr, const char *name, + unsigned long size, unsigned int alignment); void drm_intel_bo_reference(drm_intel_bo *bo); void drm_intel_bo_unreference(drm_intel_bo *bo); int drm_intel_bo_map(drm_intel_bo *bo, int write_enable); diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c index c5bb588..019630f 100644 --- a/intel/intel_bufmgr_gem.c +++ b/intel/intel_bufmgr_gem.c @@ -103,6 +103,7 @@ typedef struct _drm_intel_bufmgr_gem { unsigned int has_blt : 1; unsigned int has_relaxed_fencing : 1; unsigned int bo_reuse : 1; + unsigned int has_create_cached : 1; char fenced_relocs; } drm_intel_bufmgr_gem; @@ -584,7 +585,7 @@ drm_intel_gem_bo_alloc_internal(drm_intel_bufmgr *bufmgr, unsigned long stride) { drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bufmgr; - drm_intel_bo_gem *bo_gem; + drm_intel_bo_gem *bo_gem = NULL; unsigned int page_size = getpagesize(); int ret; struct drm_intel_gem_bo_bucket *bucket; @@ -592,6 +593,15 @@ drm_intel_gem_bo_alloc_internal(drm_intel_bufmgr *bufmgr, unsigned long bo_size; int for_render = 0; + if (flags & BO_ALLOC_FORCE_CACHED) { + DBG("bo_alloc_internal: alloc bo %s cached\n", name); + alloc_from_cache = 0; + bo_size = size; + if (bo_size < page_size) + bo_size = page_size; + goto kernel_alloc; + } + if (flags & BO_ALLOC_FOR_RENDER) for_render = 1; @@ -658,6 +668,7 @@ retry: } pthread_mutex_unlock(&bufmgr_gem->lock); +kernel_alloc: if (!alloc_from_cache) { struct drm_i915_gem_create create; @@ -668,6 +679,8 @@ retry: bo_gem->bo.size = bo_size; memset(&create, 0, sizeof(create)); create.size = bo_size; + if (flags & BO_ALLOC_FORCE_CACHED) + create.flags = DRM_I915_GEM_CREATE_CACHED; ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GEM_CREATE, @@ -729,6 +742,25 @@ drm_intel_gem_bo_alloc(drm_intel_bufmgr *bufmgr, I915_TILING_NONE, 0); } +drm_intel_bo * +drm_intel_gem_bo_alloc_cached(drm_intel_bufmgr *bufmgr, + const char *name, + unsigned long size, + unsigned int alignment) +{ + drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bufmgr; + + if (bufmgr_gem->has_create_cached) + return drm_intel_gem_bo_alloc_internal(bufmgr, name, size, + BO_ALLOC_FORCE_CACHED, + I915_TILING_NONE, 0); + else { + DBG("bo_alloc_cached: kernel not support cached alloc!\n"); + return drm_intel_gem_bo_alloc_internal(bufmgr, name, size, 0, + I915_TILING_NONE, 0); + } +} + static drm_intel_bo * drm_intel_gem_bo_alloc_tiled(drm_intel_bufmgr *bufmgr, const char *name, int x, int y, int cpp, uint32_t *tiling_mode, @@ -2146,6 +2178,10 @@ drm_intel_bufmgr_gem_init(int fd, int batch_size) ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GETPARAM, &gp); bufmgr_gem->has_relaxed_fencing = ret == 0; + gp.param = I915_PARAM_HAS_CREATE_CACHED; + ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GETPARAM, &gp); + bufmgr_gem->has_create_cached = ret == 0; + if (bufmgr_gem->gen < 4) { gp.param = I915_PARAM_NUM_FENCES_AVAIL; gp.value = &bufmgr_gem->available_fences; -- 1.7.1 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH] intel: new interface for cached bo create 2010-12-14 4:56 ` [PATCH] intel: new interface for cached bo create Zhenyu Wang @ 2010-12-14 9:35 ` Chris Wilson 0 siblings, 0 replies; 11+ messages in thread From: Chris Wilson @ 2010-12-14 9:35 UTC (permalink / raw) To: Zhenyu Wang, intel-gfx On Tue, 14 Dec 2010 12:56:01 +0800, Zhenyu Wang <zhenyuw@linux.intel.com> wrote: > This is required for special bo like PIPE_CONTROL store DW buffer > used in occlusion query. You also need to mark the buffer as non-reusable so that it is not cached on release. -Chris -- Chris Wilson, Intel Open Source Technology Centre ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH] i965: alloc cached bo for query object on Sandybridge 2010-12-14 4:55 patches for occlusion query fix on sandybridge Zhenyu Wang 2010-12-14 4:56 ` [PATCH] drm/i915: Add cached bo create interface Zhenyu Wang 2010-12-14 4:56 ` [PATCH] intel: new interface for cached bo create Zhenyu Wang @ 2010-12-14 4:56 ` Zhenyu Wang 2010-12-14 17:58 ` patches for occlusion query fix on sandybridge Eric Anholt 2010-12-14 18:13 ` Daniel Vetter 4 siblings, 0 replies; 11+ messages in thread From: Zhenyu Wang @ 2010-12-14 4:56 UTC (permalink / raw) To: intel-gfx Use new interface for cached bo create for query object on Sandybridge, which is required for PIPE_CONTROL store buffer to be CPU cacheable. --- src/mesa/drivers/dri/i965/brw_queryobj.c | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c b/src/mesa/drivers/dri/i965/brw_queryobj.c index f28f286..8c639de 100644 --- a/src/mesa/drivers/dri/i965/brw_queryobj.c +++ b/src/mesa/drivers/dri/i965/brw_queryobj.c @@ -231,7 +231,11 @@ brw_prepare_query_begin(struct brw_context *brw) drm_intel_bo_unreference(brw->query.bo); brw->query.bo = NULL; - brw->query.bo = drm_intel_bo_alloc(intel->bufmgr, "query", 4096, 1); + /* Sandybridge requires PIPE_CONTROL write DW to be LLC cached. */ + if (intel->gen >= 6) + brw->query.bo = drm_intel_gem_bo_alloc_cached(intel->bufmgr, "query", 4096, 1); + else + brw->query.bo = drm_intel_bo_alloc(intel->bufmgr, "query", 4096, 1); brw->query.index = 0; } -- 1.7.1 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: patches for occlusion query fix on sandybridge 2010-12-14 4:55 patches for occlusion query fix on sandybridge Zhenyu Wang ` (2 preceding siblings ...) 2010-12-14 4:56 ` [PATCH] i965: alloc cached bo for query object on Sandybridge Zhenyu Wang @ 2010-12-14 17:58 ` Eric Anholt 2010-12-14 20:59 ` david may 2010-12-14 18:13 ` Daniel Vetter 4 siblings, 1 reply; 11+ messages in thread From: Eric Anholt @ 2010-12-14 17:58 UTC (permalink / raw) To: Zhenyu Wang, intel-gfx [-- Attachment #1.1: Type: text/plain, Size: 801 bytes --] On Tue, 14 Dec 2010 12:55:59 +0800, Zhenyu Wang <zhenyuw@linux.intel.com> wrote: > It appears Sandybridge PIPE_CONTROL write out buffer need > to be set as cached, currently LLC cached, in order to read > back correct counter. Otherwise I can always be possible to > get corrupted 64-bit PS_DEPTH_COUNT from PIPE_CONTROL write. > > So below patches try to add new flag during bo create with > cacheable type, to be sure that GTT entry's cache bits would > be setup for that. > > This fixes occlusion query piglit test and mesa demos on my > sandybridge. Note that below patches don't include necessary > component version check changes. Why don't we just keep all of our BOs LLC cached? This was supposed to be a big win of the new chipset, as it means we don't need to clflush. [-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: patches for occlusion query fix on sandybridge 2010-12-14 17:58 ` patches for occlusion query fix on sandybridge Eric Anholt @ 2010-12-14 20:59 ` david may 2010-12-14 21:47 ` Chris Wilson 0 siblings, 1 reply; 11+ messages in thread From: david may @ 2010-12-14 20:59 UTC (permalink / raw) To: Zhenyu Wang, intel-gfx Hello Eric, Tuesday, December 14, 2010, 5:58:58 PM, you wrote: > On Tue, 14 Dec 2010 12:55:59 +0800, Zhenyu Wang <zhenyuw@linux.intel.com> wrote: >> It appears Sandybridge PIPE_CONTROL write out buffer need >> to be set as cached, currently LLC cached, in order to read >> back correct counter. Otherwise I can always be possible to >> get corrupted 64-bit PS_DEPTH_COUNT from PIPE_CONTROL write. >> >> So below patches try to add new flag during bo create with >> cacheable type, to be sure that GTT entry's cache bits would >> be setup for that. >> >> This fixes occlusion query piglit test and mesa demos on my >> sandybridge. Note that below patches don't include necessary >> component version check changes. > Why don't we just keep all of our BOs LLC cached? This was supposed to > be a big win of the new chipset, as it means we don't need to clflush. Ohh,the implication here is that people are/have been writing the code,But Not bothering Actually benching/Profiling it to see if it actually is faster and better throughput than before, that seems wrong, especially given sandy bridge is supposed to be better, i Do Hope you are/will be testing/benching/Profiling to see if it/all SB Code is actually "a big win" one way or the other before passing for release. -- Best regards, david mailto:david.may10@ntlworld.com ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: patches for occlusion query fix on sandybridge 2010-12-14 20:59 ` david may @ 2010-12-14 21:47 ` Chris Wilson 2010-12-15 1:18 ` Zhenyu Wang 0 siblings, 1 reply; 11+ messages in thread From: Chris Wilson @ 2010-12-14 21:47 UTC (permalink / raw) To: david may, Zhenyu Wang, intel-gfx On Tue, 14 Dec 2010 20:59:09 +0000, david may <david.may10@ntlworld.com> wrote: > Hello Eric, > > Tuesday, December 14, 2010, 5:58:58 PM, you wrote: > > > Why don't we just keep all of our BOs LLC cached? This was supposed to > > be a big win of the new chipset, as it means we don't need to clflush. > > Ohh,the implication here is that people are/have been writing the > code,But Not bothering Actually benching/Profiling it to see if it actually is faster and > better throughput than before, that seems wrong, especially given sandy bridge is > supposed to be better, i Do Hope you are/will be testing/benching/Profiling > to see if it/all SB Code is actually "a big win" one way or the other before passing for > release. No, the default on SNB was changed back to uncached in order to fix some coherency issues in the short term. Correctness first. commit 8d0f56708292ca5c256ee3b7187d124afee81d93 Author: Zhenyu Wang <zhenyuw@linux.intel.com> Date: Tue Nov 2 17:30:47 2010 +0800 agp/intel: restore cache behavior on sandybridge This restores cache behavior for default AGP_USER_MEMORY as uncached, and leave default AGP_USER_CACHED_MEMORY as LLC only. I've seen different cache behavior on one sandybridge desktop CPU vs. another mobile CPU. Until we figure out how to detect the real cache config, restore back to the original behavior now. -Chris -- Chris Wilson, Intel Open Source Technology Centre ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: patches for occlusion query fix on sandybridge 2010-12-14 21:47 ` Chris Wilson @ 2010-12-15 1:18 ` Zhenyu Wang 0 siblings, 0 replies; 11+ messages in thread From: Zhenyu Wang @ 2010-12-15 1:18 UTC (permalink / raw) To: Chris Wilson; +Cc: intel-gfx [-- Attachment #1.1: Type: text/plain, Size: 1268 bytes --] On 2010.12.14 21:47:45 +0000, Chris Wilson wrote: > On Tue, 14 Dec 2010 20:59:09 +0000, david may <david.may10@ntlworld.com> wrote: > > Hello Eric, > > > > Tuesday, December 14, 2010, 5:58:58 PM, you wrote: > > > > > Why don't we just keep all of our BOs LLC cached? This was supposed to > > > be a big win of the new chipset, as it means we don't need to clflush. > > > > Ohh,the implication here is that people are/have been writing the > > code,But Not bothering Actually benching/Profiling it to see if it actually is faster and > > better throughput than before, that seems wrong, especially given sandy bridge is > > supposed to be better, i Do Hope you are/will be testing/benching/Profiling > > to see if it/all SB Code is actually "a big win" one way or the other before passing for > > release. > > No, the default on SNB was changed back to uncached in order to fix some > coherency issues in the short term. Correctness first. > yeah, it's short term, coherent issue would be fixed by GFDT bit. I was done that partly before, but seems fallback to old behavior is the easiest way to fix current correction issue. -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 [-- Attachment #1.2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: patches for occlusion query fix on sandybridge 2010-12-14 4:55 patches for occlusion query fix on sandybridge Zhenyu Wang ` (3 preceding siblings ...) 2010-12-14 17:58 ` patches for occlusion query fix on sandybridge Eric Anholt @ 2010-12-14 18:13 ` Daniel Vetter 2010-12-15 1:29 ` Zhenyu Wang 4 siblings, 1 reply; 11+ messages in thread From: Daniel Vetter @ 2010-12-14 18:13 UTC (permalink / raw) To: Zhenyu Wang; +Cc: intel-gfx On Tue, Dec 14, 2010 at 12:55:59PM +0800, Zhenyu Wang wrote: > It appears Sandybridge PIPE_CONTROL write out buffer need > to be set as cached, currently LLC cached, in order to read > back correct counter. Otherwise I can always be possible to > get corrupted 64-bit PS_DEPTH_COUNT from PIPE_CONTROL write. > > So below patches try to add new flag during bo create with > cacheable type, to be sure that GTT entry's cache bits would > be setup for that. > > This fixes occlusion query piglit test and mesa demos on my > sandybridge. Note that below patches don't include necessary > component version check changes. General comment on the introduction of a new flag for bo creation: If I'm not mistaken, all the query objects are relocated as read_domain = I915_GEM_DOMAIN_INSTRUCTION, write_domain = I915_GEM_DOMAIN_INSTRUCTION, i.e. we already have an api for userspace to tell us that a PIPE_CONTROL command will write to this buffer. Why can't we use that one and remap the bo with the correct caching flags on execbuf time (on gen6)? I simply fear that introducing a hacky ad-hoc abi complicates matters when we introduce real llc/mlc caching for general stuff. Especially since there's seems to be an existing thing already available. I'm still fighting the fallout from the incoherent multiple rings introduction and I just don't want to repeat such a goof-up. Yours, Daniel -- Daniel Vetter Mail: daniel@ffwll.ch Mobile: +41 (0)79 365 57 48 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: patches for occlusion query fix on sandybridge 2010-12-14 18:13 ` Daniel Vetter @ 2010-12-15 1:29 ` Zhenyu Wang 0 siblings, 0 replies; 11+ messages in thread From: Zhenyu Wang @ 2010-12-15 1:29 UTC (permalink / raw) To: Daniel Vetter; +Cc: intel-gfx [-- Attachment #1.1: Type: text/plain, Size: 1749 bytes --] On 2010.12.14 19:13:22 +0100, Daniel Vetter wrote: > On Tue, Dec 14, 2010 at 12:55:59PM +0800, Zhenyu Wang wrote: > > It appears Sandybridge PIPE_CONTROL write out buffer need > > to be set as cached, currently LLC cached, in order to read > > back correct counter. Otherwise I can always be possible to > > get corrupted 64-bit PS_DEPTH_COUNT from PIPE_CONTROL write. > > > > So below patches try to add new flag during bo create with > > cacheable type, to be sure that GTT entry's cache bits would > > be setup for that. > > > > This fixes occlusion query piglit test and mesa demos on my > > sandybridge. Note that below patches don't include necessary > > component version check changes. > > General comment on the introduction of a new flag for bo creation: > > If I'm not mistaken, all the query objects are relocated as read_domain = > I915_GEM_DOMAIN_INSTRUCTION, write_domain = I915_GEM_DOMAIN_INSTRUCTION, > i.e. we already have an api for userspace to tell us that a PIPE_CONTROL > command will write to this buffer. Why can't we use that one and remap > the bo with the correct caching flags on execbuf time (on gen6)? True, that's the other way I thought about. > > I simply fear that introducing a hacky ad-hoc abi complicates matters when > we introduce real llc/mlc caching for general stuff. Especially since > there's seems to be an existing thing already available. I'm still > fighting the fallout from the incoherent multiple rings introduction and I > just don't want to repeat such a goof-up. > yeah, it's quick hack. I would take the way to fix caching instead. thanks. -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 [-- Attachment #1.2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2010-12-15 1:29 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-12-14 4:55 patches for occlusion query fix on sandybridge Zhenyu Wang 2010-12-14 4:56 ` [PATCH] drm/i915: Add cached bo create interface Zhenyu Wang 2010-12-14 4:56 ` [PATCH] intel: new interface for cached bo create Zhenyu Wang 2010-12-14 9:35 ` Chris Wilson 2010-12-14 4:56 ` [PATCH] i965: alloc cached bo for query object on Sandybridge Zhenyu Wang 2010-12-14 17:58 ` patches for occlusion query fix on sandybridge Eric Anholt 2010-12-14 20:59 ` david may 2010-12-14 21:47 ` Chris Wilson 2010-12-15 1:18 ` Zhenyu Wang 2010-12-14 18:13 ` Daniel Vetter 2010-12-15 1:29 ` Zhenyu Wang
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox