Re: [PATCH 00/15] [v2] Broadwell HW semaphore

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

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

-- 
Damien
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux