From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maarten Lankhorst Subject: Re: Fence, timeline and android sync points Date: Thu, 14 Aug 2014 14:37:15 +0200 Message-ID: <53ECAD7B.8040304@canonical.com> References: <20140812221340.GB5746@gmail.com> <20140813082822.GO10500@phenom.ffwll.local> <20140813133602.GA2666@gmail.com> <20140813155420.GG10500@phenom.ffwll.local> <20140813170719.GD2666@gmail.com> <53EC7E1F.7070902@canonical.com> <53ECA34B.6030501@vodafone.de> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Return-path: Received: from youngberry.canonical.com (youngberry.canonical.com [91.189.89.112]) by gabe.freedesktop.org (Postfix) with ESMTP id 270AF6E6A5 for ; Thu, 14 Aug 2014 05:37:20 -0700 (PDT) In-Reply-To: <53ECA34B.6030501@vodafone.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: =?windows-1252?Q?Christian_K=F6nig?= , Jerome Glisse , Daniel Vetter Cc: daniel.vetter@ffwll.ch, dri-devel@lists.freedesktop.org, bskeggs@redhat.com List-Id: dri-devel@lists.freedesktop.org Op 14-08-14 om 13:53 schreef Christian K=F6nig: >> But because of driver differences I can't implement it as a straight wai= t queue. Some drivers may not have a reliable interrupt, so they need a cus= tom wait function. (qxl) >> Some may need to do extra flushing to get fences signaled (vmwgfx), othe= rs need some locking to protect against gpu lockup races (radeon, i915??). = And nouveau >> doesn't use wait queues, but rolls its own (nouveau). > But when all those drivers need a special wait function how can you still= justify the common callback when a fence is signaled? > > If I understood it right the use case for this was waiting for any fence = of a list of fences from multiple drivers, but if each driver needs special= handling how for it's wait how can that work reliable? TTM doesn't rely on the callbacks. It will call .enable_signaling when .is_= signaled is NULL, to make sure that fence_is_signaled returns true sooner. QXL is completely awful, I've seen some patches to add dma-buf support but = I'll make sure it never supports importing from/exporting to other devices.= This should reduce insanity factor there. If I understand QXL correctly, sometimes fences may never signal at all due= to virt-hw bugs. nouveau (pre nv84) has no interrupt for completed work, but it has a reliab= le is_signaled. So .enable_signaling only checks if fence is signaled here. A custom waiting function makes sure things work correctly, and also signal= s all unsignaled fences for that context. I preserved the original wait fro= m before the fence conversion. Nouveau keeps a global list of unsignaled fences, so they will all signal e= ventually. I may have to limit importing/exporting dma-buf's to other devices, or add = delayed work that periodically checks all contexts for completed fences for= this to work cross-device. nv84+ has a sane interrupt, so I use it. :-) Radeon with fence conversion has the delayed work for handling lockups that= also checks. ~Maarten