On Tue, Jul 15, 2014 at 7:53 PM, Bridgman, John John.Bridgman@amd.com wrote: [snip away the discussion about hsa device discover, I'm hijacking this thread just for the event/fence stuff here.]
... There's an event mechanism still to come - mostly for communicating fences and shader interrupts back to userspace, but also used for "device change" notifications, so no polling of sysfs.
That could would be interesting. On i915 my plan is to internally use the recently added struct fence from Maarten. For the external interface for userspace that wants explicit control over fences I'm leaning towards polishing the android syncpt stuff (currently in staging). But in any case I _really_ want to avoid that we end up with multiple different and incompatible explicit fencing interfaces on linux.
Adding relevant people. -Daniel
On Wed, Jul 16, 2014 at 10:21:14AM +0200, Daniel Vetter wrote:
On Tue, Jul 15, 2014 at 7:53 PM, Bridgman, John John.Bridgman@amd.com wrote: [snip away the discussion about hsa device discover, I'm hijacking this thread just for the event/fence stuff here.]
... There's an event mechanism still to come - mostly for communicating fences and shader interrupts back to userspace, but also used for "device change" notifications, so no polling of sysfs.
That could would be interesting. On i915 my plan is to internally use the recently added struct fence from Maarten. For the external interface for userspace that wants explicit control over fences I'm leaning towards polishing the android syncpt stuff (currently in staging). But in any case I _really_ want to avoid that we end up with multiple different and incompatible explicit fencing interfaces on linux.
I agree, and I'll say it stronger than that, we WILL NOT have different and incompatible fencing interfaces in the kernel. That way lies madness.
John, take a look at what is now in linux-next, it should provide what you need here, right?
thanks,
greg k-h
linaro-mm-sig@lists.linaro.org