[Intel-gfx] [PATCH 00/15] [v2] Broadwell HW semaphore

[Daniel Vetter]

On Tue, Dec 17, 2013 at 04:29:56PM +0000, Damien Lespiau wrote:
> On Tue, Dec 17, 2013 at 10:17:38AM +0100, Daniel Vetter wrote:
> > On Mon, Dec 16, 2013 at 08:50:36PM -0800, Ben Widawsky wrote:
> > > Reposting this as a new series since two of the patches dropped off
> > > since last time.
> > > 
> > > Functionally it's the same as before. Like before, the patch "drm/i915:
> > > unleash semaphores on gen8" should probably not be merged as it's not
> > > 100% clear where the hang is currently coming from. Everything else
> > > should be pretty benign for other platforms.
> > 
> > I've pulled in the first two patches already. For review Damien is signed
> > up (althought he goes on vacation soon) and for greater learning
> > experience he's also agreed to throw in a testcase on top.
> > 
> > We already have a nice stresstest for semaphores (gem_ring_sync_loop), but
> > no real functional test which checks that the batches are indeed correctly
> > ordered. For gpu vs. cpu races we already have a fairly complete set in
> > gem_concurrent_blt, but that has many additional complications we don't
> > really care about for ring2ring syncing.
> > 
> > For each pair of rings R1, R2 where we have copy support (i.e. blt,
> > rendercpy and mediafill) do:
> 
> mediafill and rendercopy both use the render ring, so only one of them
> is useful here, right?

Oh dear, somehow I've thought that was launched on the vcs like a compute
job. So yeah, we can only test between blt and render then. I guess I
should read the patches more carefully ;-)

> Might need to investigate similar blit batches for other rings, if
> possible at all.

Yeah, otoh we should be able to test the general logic with this. And if
there's a type somewhere in the vcs/vecs tables, well mea culpa.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch