From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [RFC v2 5/8] drm/fence: add in-fences support Date: Tue, 26 Apr 2016 20:40:45 +0300 Message-ID: <20160426174045.GC4329@intel.com> References: <1461623608-29538-1-git-send-email-gustavo@padovan.org> <1461623608-29538-6-git-send-email-gustavo@padovan.org> <20160426101050.GN4329@intel.com> <20160426141422.GG7857@joana> <20160426143635.GW8291@phenom.ffwll.local> <20160426162621.GU4329@intel.com> <20160426172049.GB2558@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Content-Disposition: inline In-Reply-To: <20160426172049.GB2558@phenom.ffwll.local> Sender: linux-kernel-owner@vger.kernel.org To: Gustavo Padovan , Gustavo Padovan , Daniel Stone , Riley Andrews , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Arve =?iso-8859-1?B?SGr4bm5lduVn?= , John Harrison List-Id: dri-devel@lists.freedesktop.org On Tue, Apr 26, 2016 at 07:20:49PM +0200, Daniel Vetter wrote: > On Tue, Apr 26, 2016 at 07:26:21PM +0300, Ville Syrj=E4l=E4 wrote: > > On Tue, Apr 26, 2016 at 04:36:36PM +0200, Daniel Vetter wrote: > > > On Tue, Apr 26, 2016 at 11:14:22AM -0300, Gustavo Padovan wrote: > > > > 2016-04-26 Ville Syrj=E4l=E4 : > > > >=20 > > > > > On Mon, Apr 25, 2016 at 07:33:25PM -0300, Gustavo Padovan wro= te: > > > > > > From: Gustavo Padovan > > > > > >=20 > > > > > > There is now a new property called FENCE_FD attached to eve= ry plane > > > > > > state that receives the sync_file fd from userspace via the= atomic commit > > > > > > IOCTL. > > > > >=20 > > > > > I still don't like this property abuse. Also with atomic, all= passed > > > > > fences must be waited upon before anything is done, so attach= ing them > > > > > to planes seems like it might just give people the wrong idea= =2E > > > >=20 > > > > I'm actually fine with this as property, but another solutions = is use > > > > an array of {plane, fence_fd} and extend drm_atomic_ioctl args = just like > > > > we have done for out fences. However the FENCE_FD property is e= asier to > > > > handle in userspace than the array. Any other idea? > > >=20 > > > Imo FENCE_FD is perfectly fine. But what's the concern around giv= ing > > > people the wrong idea with attaching fences to planes? For nonblo= cking > > > commits we need to store them somewhere for the worker, drm_plane= _state > > > seems like an as good place as any other. > >=20 > > It gives the impression that each plane might flip as soon as its f= ence > > signals. >=20 > That wouldn't be atomic. Not sure how someone could come up with that > idea. What else would it mean? It's attached to a specific plane, so why woul= d it affect other planes? > I mean we could move FENCE_FD to the crtc (fence fds can be merged), > but that's just a needless difference to what hwc expects. I think > aligning with the only real-world users in this case here makes sense= =2E Well it doesn't belong on the crtc either. I would just stick in the ioctl as a separate thing, then it's clear it's related to the whole operation rather than any kms object. >=20 > Plus docs in case someone has funny ideas. Weren't you just quoting rusty's API manifesto recently? ;) Maybe it was someone else. --=20 Ville Syrj=E4l=E4 Intel OTC