On Wed, 13 Apr 2011 08:57:01 -0700, Eric Anholt <[email protected]> wrote: > On Tue, 12 Apr 2011 21:31:49 +0100, Chris Wilson <[email protected]> > wrote: > > ... or if we will need to perform a cache-flush on the object anyway. > > Unless, of course, we need to use a fence register to perform tiling > > operations during the transfer. > > Here's the case I see: I've GTT-map-written a BO (so it hit backing > pages), then that object becomes the framebuffer (PTEs changed to > uncached), then we try to GTT-map-write it some more. The fake GTT map > skips that.
Hmm, we missed a i915_gem_release_mmap in set_cache_level(). But otherwise if we attempt to read an I915_CACHE_NONE object we do so through the GTT. So: set_cache_level(bo, CACHE_LLC); ptr = mmap_gtt(bo); *ptr --> pages are left in the CPU domain and read via the normal page. set_cache_level(bo, CACHE_NONE); --> i915_gem_release_mmap(bo); *ptr --> the pagefault handler is called again and now we return a UC page > Also, looks like unrelated change to madvise? No, it is related since the vma is populated outside of being bound by the GTT now and so needs to be cleared along with truncate. Deserves a comment for being non-obvious. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
