From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?windows-1252?Q?Christian_K=F6nig?= Subject: Re: Fence, timeline and android sync points Date: Thu, 14 Aug 2014 16:31:09 +0200 Message-ID: <53ECC82D.3020404@vodafone.de> 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> <53ECAD7B.8040304@canonical.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: Received: from pegasos-out.vodafone.de (pegasos-out.vodafone.de [80.84.1.38]) by gabe.freedesktop.org (Postfix) with ESMTP id 429AE6E31E for ; Thu, 14 Aug 2014 07:31:52 -0700 (PDT) In-Reply-To: <53ECAD7B.8040304@canonical.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Maarten Lankhorst , Jerome Glisse , Daniel Vetter Cc: daniel.vetter@ffwll.ch, dri-devel@lists.freedesktop.org, bskeggs@redhat.com List-Id: dri-devel@lists.freedesktop.org Am 14.08.2014 um 14:37 schrieb Maarten Lankhorst: > Op 14-08-14 om 13:53 schreef Christian K=F6nig: >>> But because of driver differences I can't implement it as a straight wa= it queue. Some drivers may not have a reliable interrupt, so they need a cu= stom wait function. (qxl) >>> Some may need to do extra flushing to get fences signaled (vmwgfx), oth= ers 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 stil= l 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 specia= l handling how for it's wait how can that work reliable? > TTM doesn't rely on the callbacks. It will call .enable_signaling when .i= s_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 bu= t I'll make sure it never supports importing from/exporting to other device= s. This should reduce insanity factor there. So if I understand you right QXL doesn't really implement the whole = fence interface? It just implements enough to make TTM happy and you = forbid DMA-buf support because the rest isn't really working? Sorry, but that just sounds like your fence design just isn't doing the = right thing here. > If I understand QXL correctly, sometimes fences may never signal at all d= ue to virt-hw bugs. Radeon has the same problem, with the hardware scheduler each client = essentially has it's own fence sequence number range. If you kill a = client the remaining fences not necessarily gets signaled by the hardware. > > nouveau (pre nv84) has no interrupt for completed work, but it has a reli= able is_signaled. So .enable_signaling only checks if fence is signaled her= e. > A custom waiting function makes sure things work correctly, and also sign= als all unsignaled fences for that context. I preserved the original wait f= rom before the fence conversion. > Nouveau keeps a global list of unsignaled fences, so they will all signal= eventually. > I may have to limit importing/exporting dma-buf's to other devices, or ad= d delayed work that periodically checks all contexts for completed fences f= or 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 th= at also checks. Which I still don't had time to check completely, but it sounds more and = more like those fallbacks for not fired interrupts should be in the = common fence code and not in each individual driver. Christian. > > ~Maarten