On Wed, Jan 29, 2014 at 02:22:49PM -0800, Volkin, Bradley D wrote: > On Wed, Jan 29, 2014 at 02:11:17PM -0800, Daniel Vetter wrote: > > On Wed, Jan 29, 2014 at 01:55:01PM -0800, bradley.d.volkin@xxxxxxxxx wrote: > > > From: Brad Volkin <bradley.d.volkin@xxxxxxxxx> > > > 3) Coherency. I've found a coherency issue on VLV when reading the batch buffer > > > from the CPU during execbuffer2. Userspace writes the batch via pwrite fast > > > path before calling execbuffer2. The parser reads stale data. This works fine > > > on IVB and HSW, so I believe it's an LLC vs. non-LLC issue. I'm just unclear > > > on what the correct flushing or synchronization is for this scenario. This > > > only matters if we get PPGTT working on VLV and enable the parser there. > > > > Hm, adopting the shmem_read clflushing didn't help for this? That would be > > fairly shocking, since it means our shmem read paths are broken. Which are > > used e.g. by the libva readback code for the encoded bitstream. > > Sorry, not clear enough. I actually haven't retested that part with the clflushing > added since the opinion seemed to be that leaving the parser disabled for VLV was ok. > Just left the note for now so it doesn't get lost. Would be nice to give it spin though, since afaik this issue might persist on vlv+1. And I guess we can't keep on sticking our heads into sand about ppgtt not really working on soc platforms ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
