On Tue, Jul 22, 2014 at 11:19 AM, Daniel Vetter <daniel@xxxxxxxx> wrote: > On Tue, Jul 22, 2014 at 4:39 PM, Christian König > <christian.koenig@xxxxxxx> wrote: >> Am 22.07.2014 16:27, schrieb Maarten Lankhorst: >> >>> op 22-07-14 16:24, Christian König schreef: >>>>> >>>>> No, you really shouldn't be doing much in the check anyway, it's meant >>>>> to be a lightweight check. If you're not ready yet because of a lockup >>>>> simply return not signaled yet. >>>> >>>> It's not only the lockup case from radeon I have in mind here. For >>>> userspace queues it might be necessary to call copy_from_user to figure out >>>> if a fence is signaled or not. >>>> >>>> Returning false all the time is probably not a good idea either. >>> >>> Having userspace implement a fence sounds like an awful idea, why would >>> you want to do that? >> >> >> Marketing moves in mysterious ways. Don't ask me, but that the direction it >> currently moves with userspace queues and IOMMU etc... > > Fence-based syncing between userspace queues submitted stuff through > doorbells and anything submitted by the general simply wont work. > Which is why I think the doorbell is a stupid interface since I just > don't see cameras and v4l devices implementing all that complexity to > get a pure userspace side sync solution. > Like it or not this is what a lot of application writers want (look at mantle and metal and similar new APIs or android synpts). Having queues and fences in userspace allows the application to structure things to best fit their own task graphs. The app can decide how to deal with dependencies and synchronization explicitly instead of blocking the queues in the kernel for everyone. Anyway, this is getting off topic. Alex _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
