Re: patches for occlusion query fix on sandybridge

[Zhenyu Wang <zhenyuw@linux.intel.com>]

[-- 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