[Intel-gfx] [PATCH 1/2] intel: Recount fences after rewinding relocations

[Chris Wilson]

On Wed, May 08, 2013 at 06:11:19PM +0200, Daniel Vetter wrote:
> On Wed, May 08, 2013 at 04:33:09PM +0100, Chris Wilson wrote:
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59771
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> 
> I guess we've walked past a "please stop and return" sign here a bit.
> Originally this was just add for opportunistic state emission in mesa (and
> still documents that check_aperture will return fobar). But then uxa
> started to abuse it to reset batches completely in
> 
> commit 441ef916ae6569c88b3d6abaf7fea4d69be49d76
> Author: Chris Wilson <chris at chris-wilson.co.uk>
> Date:   Thu Jan 10 19:14:21 2013 +0000
> 
>     intel: Throttle harder
> 
> which required some band-aids in libdrm to have some semblances of working
> 
> commit fdda97007b1dbf95beb16a0e3510fd36c89e8c33
> Author: Chris Wilson <chris at chris-wilson.co.uk>
> Date:   Fri Jan 11 00:55:12 2013 +0000
> 
>     intel: Remove the fence count contributions when clearing relocs
> 
> Apparently not yet good enough. Personally I vote for reverting the libdrm
> patch and doing a normal wait_rendering + unref/bo realloc for the uxa
> throttling.

The second patch should in theory be the fix for the root cause in the
miscounting here. I left this here as it makes the count obviously
correct irrespective of that patch (though it still grossly overcounts
fences as there should be many relocations from the batch to the same
tiled bo). The libdrm rewind interface is broken as designed and should
be shot unless you actually want to fix it up.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre