From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesse Barnes Subject: Re: [PATCH] drm/i915: Android sync points for i915 v2 Date: Tue, 5 Aug 2014 08:03:35 -0700 Message-ID: <20140805080335.20154a8a@jbarnes-desktop> References: <53DB3275.6010102@canonical.com> <1407194292-16218-1-git-send-email-jbarnes@virtuousgeek.org> <53E09154.8010005@canonical.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by gabe.freedesktop.org (Postfix) with ESMTP id D41C389ACC for ; Tue, 5 Aug 2014 08:03:18 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id fa1so1582062pad.27 for ; Tue, 05 Aug 2014 08:03:18 -0700 (PDT) In-Reply-To: <53E09154.8010005@canonical.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Maarten Lankhorst Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Tue, 05 Aug 2014 10:09:56 +0200 Maarten Lankhorst wrote: > op 05-08-14 01:18, Jesse Barnes schreef: > > Expose an ioctl to create Android fences based on the Android sync point > > infrastructure (which in turn is based on DMA-buf fences). Just a > > sketch at this point, no testing has been done. > > > > There are a couple of goals here: > > 1) allow applications and libraries to create fences without an > > associated buffer > > 2) re-use a common API so userspace doesn't have to impedance mismatch > > between different driver implementations too much > > 3) allow applications and libraries to use explicit synchronization if > > they choose by exposing fences directly > > > > v2: use struct fence directly using Maarten's new interface > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > > index d604f4f..6eb119e 100644 > > --- a/drivers/gpu/drm/i915/i915_drv.h > > +++ b/drivers/gpu/drm/i915/i915_drv.h > > @@ -1388,6 +1388,8 @@ struct i915_frontbuffer_tracking { > > unsigned flip_bits; > > }; > > > > +struct i915_sync_timeline; > > + > > struct drm_i915_private { > > struct drm_device *dev; > > struct kmem_cache *slab; > > @@ -1422,6 +1424,8 @@ struct drm_i915_private { > > struct drm_i915_gem_object *semaphore_obj; > > uint32_t last_seqno, next_seqno; > > > > + struct i915_sync_timeline *sync_tl[I915_NUM_RINGS]; > > + > > drm_dma_handle_t *status_page_dmah; > > struct resource mch_res; > > > Leftover remnant? Oops, yeah. I still need to add a way to request a fence on a specific ring, and that ties into our context API, so that's still open. But I definitely don't want a sync timeline here with this approach. > I think you should rebase on top of Chris' seqno/request stuff like you said in TODO, it would reduce the patch to just the ioctl. ;-) I need to check if it landed yet, but yes it will make things even simpler. -- Jesse Barnes, Intel Open Source Technology Center