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@xxxxxxxxx> > >> > >>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@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
