On Wed, Mar 12, 2014 at 6:11 PM, Rodrigo Vivi <rodrigo.v...@gmail.com> wrote: >> We have it, it's called dirtyfb. But we need to keep the current userspace >> stuff mostly working first, hence all this trouble. We can fix the gtt >> trouble with a delayed work (one vblank or so) which >> a) does a psr_exit >> b) shots down gtt mappings of the offending frontbuffer >> >> Then we can intercept the next write in gem_fault. >> >> Of course that will be horrible if we don't track correctly which buffers >> are actually relevant for psr. >> -Daniel > > I'm not sure I fully got your idea/plan here. > > Should I try a psr_exit with delayed back at dirtyfb? and create a new > test case? > Or this it self isn't enough? > > Btw, i'm using daily a hsw ult with psr enable and a kde environment > using the same psr_exit strategy here for baytrail with psr enabled > for more than 2 weeks without any issue so far.
Current userspace doesn't use dirtyfb, so we can't solely rely on that. Iirc you currently have a psr_exit in set_domain. My idea above was that we also need to have it in i915_gem_fault and further we need to shot down ptes in psr_exit for the frontbuffer. For an igt the following should trick this bug: 1) set_domain(GTT, GTT) on the frontbuffer 2) rendering something -> check that the kernel has correctly done a psr_exit with the sink crc stuff This is the testcase we already have. Now comes the interesting part Chris pointed out: 3) have a long delay to make sure we are again in psr mode. 4) Write new stuff to the frontbuffer, _without_ doing a set_domain(GTT, GTT). Userspace is allowed to do this. -> check again sink crcs Note that this issue doesn't exist with cpu memory mapped frontbuffer rendering, since userspace is required to regularly call the sw_finish ioctl, i.e. after both steps 2) and 4). But even for cpu mmaps userspace is allowed to optimize the set_domain(CPU, CPU) call away before step 3). Of course if any other rendering happens in between step 2) and 3) userspace must again do a set_domain call. So this case here is highly contrived ;-) I hope this explains this issue better. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
