From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 00/15] [v2] Broadwell HW semaphore Date: Tue, 17 Dec 2013 19:21:34 +0100 Message-ID: <20131217182134.GQ9804@phenom.ffwll.local> References: <1387255851-24824-1-git-send-email-benjamin.widawsky@intel.com> <20131217091738.GN9804@phenom.ffwll.local> <20131217162955.GE30739@strange.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-ee0-f48.google.com (mail-ee0-f48.google.com [74.125.83.48]) by gabe.freedesktop.org (Postfix) with ESMTP id 801BDFCF57 for ; Tue, 17 Dec 2013 10:20:44 -0800 (PST) Received: by mail-ee0-f48.google.com with SMTP id e49so3056527eek.7 for ; Tue, 17 Dec 2013 10:20:42 -0800 (PST) Content-Disposition: inline In-Reply-To: <20131217162955.GE30739@strange.amr.corp.intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org To: Damien Lespiau Cc: Intel GFX , Ben Widawsky List-Id: intel-gfx@lists.freedesktop.org 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