From mboxrd@z Thu Jan  1 00:00:00 1970
From: Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [PATCH 1/2] drm/i915: Dumb down the semaphore logic
Date: Thu, 8 Sep 2011 09:52:36 +0200
Message-ID: <20110908075236.GA2884@phenom.ffwll.local>
References: <1315437162-14312-1-git-send-email-ben@bwidawsk.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org>
Received: from mail-ww0-f43.google.com (mail-ww0-f43.google.com [74.125.82.43])
	by gabe.freedesktop.org (Postfix) with ESMTP id 1E9119E836
	for <intel-gfx@lists.freedesktop.org>;
	Thu,  8 Sep 2011 00:52:18 -0700 (PDT)
Received: by wwe32 with SMTP id 32so439394wwe.12
	for <intel-gfx@lists.freedesktop.org>;
	Thu, 08 Sep 2011 00:52:18 -0700 (PDT)
Content-Disposition: inline
In-Reply-To: <1315437162-14312-1-git-send-email-ben@bwidawsk.net>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/intel-gfx>
List-Post: <mailto:intel-gfx@lists.freedesktop.org>
List-Help: <mailto:intel-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=subscribe>
Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org
Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org
To: Ben Widawsky <ben@bwidawsk.net>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>, intel-gfx@lists.freedesktop.org
List-Id: intel-gfx@lists.freedesktop.org

On Wed, Sep 07, 2011 at 04:12:41PM -0700, Ben Widawsky wrote:
> While I think the previous code is correct, it was hard to follow and
> hard to debug. Since we already have a ring abstraction, might as well
> use it to handle the semaphore updates and compares.
> 
> I don't expect this code to make semaphores better or worse, but you
> never know...

I kinda start to like this ;-)

While you stare at this, two things I'm pondering:
- Would it make sense to also move the !semaphores ring_sync_to case into
  the ringbuffer abstraction?
- Can we have a basic testcase for the magic values (and semaphores in
  general), please? I'm thinking of submitting a batchbuffer with a dummy
  r/w render relocation (hide it e.g. in the val field of
  MI_FLUSH_DW/PIPE_CONTROL without setting the write post-sync-op), and
  then randomly moving around the buffer to another ring. That should
  decently exercise the semaphores code in the kernel and sync hw in the
  gpu without (hopefully) anything else interfering.

-Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48