drm/radeon: giving userspace control over hardware engine sync

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

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.

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.

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.