Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757718AbaGWJw7 (ORCPT ); Wed, 23 Jul 2014 05:52:59 -0400 Received: from mail-ig0-f181.google.com ([209.85.213.181]:64680 "EHLO mail-ig0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757486AbaGWJw6 convert rfc822-to-8bit (ORCPT ); Wed, 23 Jul 2014 05:52:58 -0400 MIME-Version: 1.0 X-Originating-IP: [84.73.67.144] In-Reply-To: <53CF84C7.2020507@vodafone.de> References: <20140709093124.11354.3774.stgit@patser> <53CE8A57.2000803@vodafone.de> <53CF58FB.8070609@canonical.com> <53CF5B9F.1050800@amd.com> <53CF5EFE.6070307@canonical.com> <53CF63C2.7070407@vodafone.de> <53CF6622.6060803@amd.com> <53CF699D.9070902@canonical.com> <53CF6B18.5070107@vodafone.de> <53CF7035.2060808@amd.com> <53CF7191.2090008@canonical.com> <53CF765E.7020802@vodafone.de> <53CF8010.9060809@amd.com> <53CF822E.7050601@amd.com> <53CF84C7.2020507@vodafone.de> Date: Wed, 23 Jul 2014 11:52:57 +0200 Message-ID: Subject: Re: [Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences From: Daniel Vetter To: =?UTF-8?Q?Christian_K=C3=B6nig?= Cc: =?UTF-8?Q?Christian_K=C3=B6nig?= , Maarten Lankhorst , Thomas Hellstrom , nouveau , LKML , dri-devel , Ben Skeggs , "Deucher, Alexander" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 23, 2014 at 11:47 AM, Christian König wrote: > Am 23.07.2014 11:44, schrieb Daniel Vetter: >> On Wed, Jul 23, 2014 at 11:39 AM, Daniel Vetter >> wrote: >>> >>> The scheduler needs to keep track of a lot of fences, so I think we'll >>> have to register callbacks, not a simple wait function. We must keep >>> track of all the non-i915 fences for all oustanding batches. Also, the >>> scheduler doesn't eliminate the hw queue, only keep it much slower so >>> that we can sneak in higher priority things. >>> >>> Really, scheduler or not is orthogonal. >> >> Also see my other comment about interactions between wait_fence and >> the i915 reset logic. We can't actually use it from within the >> scheduler code since that would deadlock. > > > Yeah, I see. You would need some way to abort the waiting on other devices > fences in case of a lockup. > > What about an userspace thread to offload waiting and command submission to? That's what your android guys currently do. They hate it. And google explicitly created their syncpts stuff to move all that into the kernel. That one does explicit fencing, but the end result is still that you have fences as deps between different drivers. The other problem is that dri/prime is running under an implicitly sync'ed model, so there's no clear point/responsibility for who would actually do the waiting. You'll end up with synchronous behaviour since the render sooner or later needs to perfectly align with client/compositor ipc. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/