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. > > One thing aside: When resending the complete series (even if it's just a > subset) it's better to start a new thread. We tend to use in-reply-to only > when resending individual patches, while the review discussion is still > ongoing. That way the discussion stays together. But when there's been a > bit a longer break it's imo better to start a new thread. Ok, I thought it was more of a blanket thing. Noted. -Brad > > Cheers, 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
