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

[Alex Deucher <alexdeucher@gmail.com>]

On Tue, Jul 22, 2014 at 11:19 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, Jul 22, 2014 at 4:39 PM, Christian König
> <christian.koenig@amd.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