Daniel Vetter <daniel at ffwll.ch> writes: > On Wed, May 8, 2013 at 6:39 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote: >> 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. Using clear_relocs to release the stuff referenced your batch when it's only going to be used for throttling seems pretty reasonable (that way those referenced buffers can get reused for for-rendering allocations). I'm sort of neutral on whether using this interface to avoid freeing the batch at all is a good idea. It looks like it will cut down on a bit of overhead at batch wrap time (freeing and reallocing the reloc storage). But your old batch can't get freed by memory pressure. It's not a big deal right now, but that's assuming you don't find that you actually need more than one batch in flight to keep the GPU busy. For the most part, I'm not a fan. Is the kernel ever going to grow appropriate stop-sending-me-so-many-batches throttling? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20130508/107ff503/attachment.pgp>
