From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerome Glisse Subject: Re: Question on UAPI for fences Date: Fri, 12 Sep 2014 10:50:49 -0400 Message-ID: <20140912145048.GA4139@gmail.com> References: <5412F3CA.9060306@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) by gabe.freedesktop.org (Postfix) with ESMTP id C853D6E72B for ; Fri, 12 Sep 2014 07:51:15 -0700 (PDT) Received: by mail-qg0-f48.google.com with SMTP id q108so839385qgd.7 for ; Fri, 12 Sep 2014 07:51:15 -0700 (PDT) Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Daniel Vetter Cc: Maarten Lankhorst , Zach Pfeffer , "dri-devel@lists.freedesktop.org" , "linaro-mm-sig@lists.linaro.org" , John Harrison , Christian =?iso-8859-1?Q?K=F6nig?= , gpudriverdevsupport@amd.com List-Id: dri-devel@lists.freedesktop.org On Fri, Sep 12, 2014 at 04:43:44PM +0200, Daniel Vetter wrote: > On Fri, Sep 12, 2014 at 4:09 PM, Daniel Vetter wrote: > > On Fri, Sep 12, 2014 at 03:23:22PM +0200, Christian K=F6nig wrote: > >> Hello everyone, > >> > >> to allow concurrent buffer access by different engines beyond the mult= iple > >> readers/single writer model that we currently use in radeon and other > >> drivers we need some kind of synchonization object exposed to userspac= e. > >> > >> My initial patch set for this used (or rather abused) zero sized GEM b= uffers > >> as fence handles. This is obviously isn't the best way of doing this (= to > >> much overhead, rather ugly etc...), Jerome commented on this according= ly. > >> > >> So what should a driver expose instead? Android sync points? Something= else? > > > > I think actually exposing the struct fence objects as a fd, using andro= id > > syncpts (or at least something compatible to it) is the way to go. Prob= lem > > is that it's super-hard to get the android guys out of hiding for this = :( > > > > Adding a bunch of people in the hopes that something sticks. > = > More people. Just to re-iterate, exposing such thing while still using command stream ioctl that use implicit synchronization is a waste and you can only get the lowest common denominator which is implicit synchronization. So i do not see the point of such api if you are not also adding a new cs ioctl with explicit contract that it does not do any kind of synchronization (it could be almost the exact same code modulo the do not wait for previous cmd to complete). Also one thing that the Android sync point does not have, AFAICT, is a way to schedule synchronization as part of a cs ioctl so cpu never have to be involve for cmd stream that deal only one gpu (assuming the driver and hw can do such trick). Cheers, J=E9r=F4me > -Daniel > -- = > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch