On Tue, Jul 03, 2018 at 10:05:28AM +0100, Chris Wilson wrote: > Quoting Daniel Vetter (2018-07-03 09:51:03) > > On Tue, Jul 03, 2018 at 10:56:17AM +0800, Zhao Yakui wrote: > > > On VGPU scenario the read/write operation of fence_reg will be trapped > > > by the GVT-g. And then gvt-g follows the HW spec to write the fence_reg. > > > So it is unnecessary to read/write fence reg several times. This will help > > > to reduce the unnecessary trap of fence_reg mmio operation. > > > > > > V1->V2: Fix one typo error of parameter when calling intel_vgpu_active > > > > > > Signed-off-by: Zhao Yakui <yakui.zhao@xxxxxxxxx> > > > > Ok this makes more sense. Except you need to put the 64bit entirely into > > the vpgu block, with a comment explaining why this is safe (since the vpgu > > will take care of updating fences correctly). > > Except, who cares? Are fence registers being rewritten that frequently > that special casing vgpu is worth the hassle. Part of that is that you > need to leave a hint behind in the code that (a) explains why it is safe > after having the "here be dragons" and (b) why we care. > > On a more pragmatic level if fencing doesn't plateau out to steady > state, that is a worrying amount of contention -- the actual fence write > itself would be the least of my worries. I can easily imagine that with the few per-client fences vgpu hands out rewrites are much more common. But yeah some real data would be good. And more reasons to get mesa off of the gtt mmaps. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
