On 01/27/2015 12:18 PM, Chris Wilson wrote:
On Tue, Jan 27, 2015 at 12:13:14PM +0000, Tvrtko Ursulin wrote:
On 01/27/2015 11:40 AM, Chris Wilson wrote:
[snip]
Explain how fence_release interacts with enable_signalling. Presumably
either the core fence routines cleanup the outstanding signalling, or we
are expected to. Doing so will remove the requirement for the extra
ref/unref (including the worker).
I think normally we would be expected to use fence_get/put on the
signaling side of things but that is not possible here since struct
fence is embedded in the request.
So as it is, sync_fence_release will tear everything down with our
callback still on the irq_queue which is what taking a request
reference sorts out.
So you are saying that we have a callback for when the fence is
discarded by userspace and we ignore that opportunity for disabling
interrupt generation, and remove the extra request references?
I can change it to work like that sure, don't see anything obvious
preventing this rework. Can use the fence lock to avoid wait queue
removal race and that should be pretty much it.
On a related not, do you have any ideas for submitting a batch which can
either keep the GPU busy for a configurable time, or until signaled by
something else (possibly another batch). Gen agnostic ideally? :)
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
