From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tvrtko Ursulin Subject: Re: [PATCH] drm/i915: Android sync points for i915 Date: Fri, 01 Aug 2014 10:04:55 +0100 Message-ID: <53DB5837.6030803@linux.intel.com> References: <1406833088-25801-1-git-send-email-jbarnes@virtuousgeek.org> <1406833088-25801-2-git-send-email-jbarnes@virtuousgeek.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by gabe.freedesktop.org (Postfix) with ESMTP id 51B4D6E732 for ; Fri, 1 Aug 2014 02:05:00 -0700 (PDT) In-Reply-To: <1406833088-25801-2-git-send-email-jbarnes@virtuousgeek.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Jesse Barnes , intel-gfx@lists.freedesktop.org Cc: Maarten Lankhorst List-Id: intel-gfx@lists.freedesktop.org Hi Jesse, On 07/31/2014 07:58 PM, Jesse Barnes wrote: > 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 > > Signed-off-by: Jesse Barnes [snip] > + > +/* > + * i915 fences on sync timelines > + * > + * We implement sync points in terms of i915 seqnos. They're exposed > + * through the new DRM_I915_GEM_FENCE ioctl, and can be mixed and matched > + * with other Android timelines and aggregated into sync_fences, etc. > + * > + * TODO: > + * rebase on top of Chris's seqno/request stuff and use requests > + * allow non-RCS fences (need ring/context association) > + */ > + > +struct i915_sync_timeline { > + struct sync_timeline obj; > + struct intel_engine_cs *ring; > + struct drm_i915_private *dev_priv; > +}; > + > +struct i915_sync_pt { > + struct sync_pt pt; > + u32 seqno; > +}; In case one day more than seqno needs to be exported to userspace, perhaps it would be handy to version the driver data somehow to allow for some forward/backward compatibility? Unless kernel/libdrm are supposed to be updated in lock-step already. Regards, Tvrtko