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@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
