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 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. 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
