Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756053AbaGVPmT (ORCPT ); Tue, 22 Jul 2014 11:42:19 -0400 Received: from mail-qa0-f50.google.com ([209.85.216.50]:53549 "EHLO mail-qa0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751391AbaGVPmS convert rfc822-to-8bit (ORCPT ); Tue, 22 Jul 2014 11:42:18 -0400 MIME-Version: 1.0 In-Reply-To: References: <20140709093124.11354.3774.stgit@patser> <20140709122953.11354.46381.stgit@patser> <53CE2421.5040906@amd.com> <20140722114607.GL15237@phenom.ffwll.local> <20140722115737.GN15237@phenom.ffwll.local> <53CE56ED.4040109@vodafone.de> <53CE6FB0.90500@canonical.com> <53CE7410.3090603@amd.com> <53CE74B5.3000201@canonical.com> <53CE77B4.6020801@amd.com> Date: Tue, 22 Jul 2014 11:42:17 -0400 Message-ID: Subject: Re: [PATCH 09/17] drm/radeon: use common fence implementation for fences From: Alex Deucher To: Daniel Vetter Cc: =?UTF-8?Q?Christian_K=C3=B6nig?= , Thomas Hellstrom , nouveau , LKML , dri-devel , "Deucher, Alexander" , Ben Skeggs 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 Tue, Jul 22, 2014 at 11:19 AM, Daniel Vetter wrote: > On Tue, Jul 22, 2014 at 4:39 PM, Christian König > wrote: >> Am 22.07.2014 16:27, schrieb Maarten Lankhorst: >> >>> op 22-07-14 16:24, Christian König schreef: >>>>> >>>>> No, you really shouldn't be doing much in the check anyway, it's meant >>>>> to be a lightweight check. If you're not ready yet because of a lockup >>>>> simply return not signaled yet. >>>> >>>> It's not only the lockup case from radeon I have in mind here. For >>>> userspace queues it might be necessary to call copy_from_user to figure out >>>> if a fence is signaled or not. >>>> >>>> Returning false all the time is probably not a good idea either. >>> >>> Having userspace implement a fence sounds like an awful idea, why would >>> you want to do that? >> >> >> Marketing moves in mysterious ways. Don't ask me, but that the direction it >> currently moves with userspace queues and IOMMU etc... > > Fence-based syncing between userspace queues submitted stuff through > doorbells and anything submitted by the general simply wont work. > Which is why I think the doorbell is a stupid interface since I just > don't see cameras and v4l devices implementing all that complexity to > get a pure userspace side sync solution. > Like it or not this is what a lot of application writers want (look at mantle and metal and similar new APIs or android synpts). Having queues and fences in userspace allows the application to structure things to best fit their own task graphs. The app can decide how to deal with dependencies and synchronization explicitly instead of blocking the queues in the kernel for everyone. Anyway, this is getting off topic. Alex -- 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/