Re: drm/radeon: giving userspace control over hardware engine sync

["Christian König" <deathsimple@vodafone.de>]

Am 14.08.2014 um 20:35 schrieb Jerome Glisse:
> On Thu, Aug 14, 2014 at 06:12:01PM +0200, Christian König wrote:
>> Hello everyone,
>>
>> this set of patch adds the ability for userspace to better control when
>> synchronization between the different hardware engines on radeon happens.
>> Previously every access to a buffer object was serialized and concurrent
>> execution could only happen if command submissions didn't shared any
>> buffer handle.
> I must say i do not like the whole direction of abusing buffer object to be
> expose as fence to userspace. Allowing 0 sized bo was the first step in this
> bad direction.

I'm not very keen about it either, but I wanted to wait what's the final 
result of the fence discussion and how we want to expose them to 
userspace before switching to something else.

> I do understand it's lot easier to implement such things in isolation from
> other and that trying to design and get a common kernel subsystem accepted
> is way more painful and unpredictible.

Correct, comparing the history of GEM named handles and DMA-buf the idea 
should be relative clear what we should use. Well after all everything 
is just a file, isn't it?


>> Patch #1 in this series adds the ability to not only sync before the IB
>> execution, but also after it before the fence value is written. This is
>> a workaround because TTM currently can't handle multiple fences attached
>> to a single buffer object.
> We do not want multiple fences to be associated with a buffer object ever.

Well maybe we shouldn't use the wording associating the fence to the 
buffer, but rather protecting the buffer object by multiple fences. 
Otherwise it wouldn't be possible to allow concurrent access from 
different hardware engines to the same buffer object. What we should 
avoid clearly is exposing any of this to userspace.

> In fact i believe getting rid of fence associated to buffer object is what
> would make sense.

Yeah, agree. We should have a separated fence object that userspace can 
query. In the end it should probably be similar to a DMA-buf fd or a 
futex. Not sure how a sane interface would look like.

Christian.

>
> Others comment as a per patch reply.
>
> Cheers,
> Jérôme
>
>> Patch #2 allows concurrent execution of command submission if there is
>> only read only access to the same buffer.
>>
>> Patch #3 adds a DONT_SYNC flag to each buffer object send to the kernel
>> which allows userspace to explicitly note that concurrent access to a
>> buffer is ok. The usage of this flag is restricted in that way that each
>> operation the client doesn't knows about (eviction, access by other clients
>> etc...) is still implicitly synced to.
>>
>> Patch #4 adds a DONT_FENCE flag that tells the kernel to sync all operations
>> to a buffer handle, but don't fence that handle with the current command
>> submission. This is necessarily because we currently abuses zero sized buffer
>> objects as fence handles.
>>
>> Please review and comment,
>> Christian.
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel