[Intel-gfx] [PATCH v3 0/5] Command parser batch buffer copy

[Daniel Vetter]

On Mon, Nov 03, 2014 at 02:44:55PM -0800, Volkin, Bradley D wrote:
> On Mon, Nov 03, 2014 at 11:19:40AM -0800, Volkin, Bradley D wrote:
> > From: Brad Volkin <bradley.d.volkin at intel.com>
> > 
> > This is v3 of the series I sent here:
> > http://lists.freedesktop.org/archives/intel-gfx/2014-July/048705.html
> > 
> > Most of the previous commentary still applies. We've fixed the secure
> > dispatch regression though, so the series now puts the parser into
> > enabling mode in patch 2.
> > 
> > There are currently some regressions. I've sent i-g-t patches for a couple that
> > are test issues. The remaining issues are:
> > 
> > drv_hangman error-state-capture-*
> >     The test has checks that the logged 'gtt_offset' matches the expected
> >     offset of the userspace-supplied batch buffer. Similarly for the address
> >     in an MI_BATCH_BUFFER_START command found in the logged ringbuffer contents.
> >     These obviously won't match if the buffer submitted to hardware is from the
> >     batch pool instead of the one from userspace.

Sounds like we need a patch to check for the cmd parser getparam and
remove these checks if that is active.

> > 
> > gem_reloc_vs_gpu *-thrash-inactive
> > gem_persistent_relocs *-thrash-inactive
> >     These fail with this type of error:
> > 
> >         Test assertion failure function do_test, file gem_reloc_vs_gpu.c:221:
> >         Failed assertion: test == 0xdeadbeef
> >         mismatch in buffer 0: 0x00000000 instead of 0xdeadbeef
> >         child 6 failed with exit status 99
> >         Subtest forked-thrash-inactive: FAIL (3.824s)
> > 
> >     One crashed, apparently in i915_gem_object_move_to_inactive() called via
> >     i915_gem_reset(). I assume there's an issue with my active tracking or
> >     madv usage for batch pool objects. Any input would be helpful.
> 
> Follow up: the current patches aren't setting any read domains for the shadow
> batch object. Simply setting
> 
> shadow_batch_obj->base.pending_read_domains = batch_obj->base.pending_read_domains;
> 
> after parsing has these passing consistently in local testing. So unless anyone
> sees further problems, I'll send a new version of the one patch with that change
> squashed in.

Yeah, PRTS results looked like you've broken the shrinker logic. Not
setting read domains will result in no conflict and so unbind the shadow
batches way too early. Makes sense.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch