drm/radeon: giving userspace control over hardware engine sync
j.glisse at gmail.com
Thu Aug 14 11:35:42 PDT 2014
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
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.
> 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.
In fact i believe getting rid of fence associated to buffer object is what
would make sense.
Others comment as a per patch reply.
> 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,
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
More information about the dri-devel