Re: [PATCH v2 3/5] drm/i915: Add support for CPU mapping to DRM_IOCTL_I915_GEM_MMAP_GTT

[Daniel Vetter <daniel@ffwll.ch>]

On Wed, Jan 27, 2016 at 04:01:26PM +0000, Tvrtko Ursulin wrote:
> 
> On 27/01/16 15:51, Daniel Vetter wrote:
> >On Wed, Jan 27, 2016 at 03:21:48PM +0000, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> >>
> >>This enables mapping via CPU using the proper DRM mmap API for
> >>better debug (Valgrind) and implementation symmetry in the
> >>driver.
> >>
> >>v2:
> >>  * Use normal mutex, skip domain management and pin pages. (Chris Wilson)
> >>  * No need to drop struct mutex over vma_insert_pfn.
> >
> >I think we still neeed that on first fault:
> >
> >- userspac calls set_domain(GTT)
> >- kernel does nothing since there's no binding
> >- userspace starts accessing gtt mmap
> >- kernel faults, but doesn't update domain/flush cpu caches
> >-> BOOM
> 
> Boom what? :) (seriously I don't follow)

I screwed up the example, this one explains why we need the set_domain for
gtt mmaps. For cpu mmaps I think we can get away with it, since we never
optimize away a set_domain(CPU). The problem is just the asymmetry in how
we treat set_domain(GTT) when there's no gtt mmaping.

> And as an aside, you would merge this in general or see value in it?

I think the idea makes sense, seems to still lack justification in form of
some open-source userspace wanting this ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx