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
signature.asc
Description: Digital signature
_______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
