On Tue, Jul 22, 2014 at 6:39 PM, Christian K?nig <christian.koenig at amd.com> wrote: >> Maybe I've mixed things up a bit in my description. There is >> fence_signal which the implementor/exporter of a fence must call when >> the fence is completed. If the exporter has an ->enable_signaling >> callback it can delay that call to fence_signal for as long as it >> wishes as long as enable_signaling isn't called yet. But that's just >> the optimization to not required irqs to be turned on all the time. >> >> The other function is fence_is_signaled, which is used by code that is >> interested in the fence state, together with fence_wait if it wants to >> block and not just wants to know the momentary fence state. All the >> other functions (the stuff that adds callbacks and the various _locked >> and other versions) are just for fancy special cases. > > Well that's rather bad, cause IRQs aren't reliable enough on Radeon HW for > such a thing. Especially on Prime systems and Macs. > > That's why we have this fancy HZ/2 timeout on all fence wait operations to > manually check if the fence is signaled or not. > > To guarantee that a fence is signaled after enable_signaling is called we > would need to fire up a kernel thread which periodically calls > fence->signaled.
We actually have seen similar fun on some i915 platforms. I wonder whether we shouldn't have something in the fence core for this given how common it is. Currently we have the same trick with regular wakups on platforms with unreliable interrupts, but I haven't yet looked at how we'll do this with callbacks once we add the scheduler and fences. It might be though that we've finally fixed these coherency issues between the interrupt and the fence write for real. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
