linux-kernel - Re: [PATCH 09/17] drm/radeon: use common fence implementation for fences

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CADnq5_Moy78A5JfDM0LME6_-48PW72DJpYYvEthQ5b=_amU8KQ@mail.gmail.com>
Date:	Tue, 22 Jul 2014 11:42:17 -0400
From:	Alex Deucher <alexdeucher@...il.com>
To:	Daniel Vetter <daniel@...ll.ch>
Cc:	Christian König <christian.koenig@....com>,
	Thomas Hellstrom <thellstrom@...are.com>,
	nouveau <nouveau@...ts.freedesktop.org>,
	LKML <linux-kernel@...r.kernel.org>,
	dri-devel <dri-devel@...ts.freedesktop.org>,
	"Deucher, Alexander" <alexander.deucher@....com>,
	Ben Skeggs <bskeggs@...hat.com>
Subject: Re: [PATCH 09/17] drm/radeon: use common fence implementation for fences

On Tue, Jul 22, 2014 at 11:19 AM, Daniel Vetter <daniel@...ll.ch> wrote:
> On Tue, Jul 22, 2014 at 4:39 PM, Christian König
> <christian.koenig@....com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/