Op 13-05-13 13:24, Inki Dae schreef: >> and can be solved with userspace locking primitives. No need for the >> kernel to get involved. >> > Yes, that is how we have synchronized buffer between CPU and DMA device > until now without buffer synchronization mechanism. I thought that it's best > to make user not considering anything: user can access a buffer regardless > of any DMA device controlling and the buffer synchronization is performed in > kernel level. Moreover, I think we could optimize graphics and multimedia > hardware performance because hardware can do more works: one thread accesses > a shared buffer and the other controls DMA device with the shared buffer in > parallel. Thus, we could avoid sequential processing and that is my > intention. Aren't you think about that we could improve hardware utilization > with such way or other? of course, there could be better way. > If you don't want to block the hardware the only option is to allocate a temp bo and blit to/from it using the hardware. OpenGL already does that when you want to read back, because otherwise the entire pipeline can get stalled. The overhead of command submission for that shouldn't be high, if it is you should really try to optimize that first before coming up with this crazy scheme.
In that case you still wouldn't give userspace control over the fences. I don't see any way that can end well. What if userspace never signals? What if userspace gets killed by oom killer. Who keeps track of that? ~Maarten -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
