On Fri, Mar 11, 2016 at 02:56:42PM +0530, akash.goel@xxxxxxxxx wrote: > From: Akash Goel <akash.goel@xxxxxxxxx> > > Currently for the case where there is enough space at the end of Ring > buffer for accommodating only the base request, the wrapround is done > immediately and as a result the base request gets added at the start > of Ring buffer. But there may not be enough free space at the beginning > to accommodate the base request, as before the wraparound, the wait was > effectively done for the reserved_size free space from the start of > Ring buffer. In such a case there is a potential of Ring buffer overflow, > the instructions at the head of Ring (ACTHD) can get overwritten. > > Since the base request can fit in the remaining space, there is no need > to wraparound immediately. The wraparound will anyway happen later when > the reserved part starts getting used. > > Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > Signed-off-by: Akash Goel <akash.goel@xxxxxxxxx> >From an earlier review: > The benefit (other than that bug fix which could affect ilk in extreme > circumstances, though I guess the timing is a little too short for > igt/gem_ringfill to hit it - we can fill the ring with ease, but we would > have to overwrite after wrap whilst the ACTHD was still in the zone in > order for it to actualy fallover. Hmm, if we added a BUG for tail overflow > that might have a chance of detecting the issue) should be that we > squeeze in perhaps even another whole request before the ring is > exhausted and so reserved-space is less wasteful on gen that do not need > the full reservation. > > Reviewed-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > In theory this could be impacting upon Ironlakes in the real-world, so a > candidate for stable@ -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
