[Intel-gfx] [RFC v3] drm/i915: Android native sync support

[Daniel Vetter]

On Tue, Jan 27, 2015 at 01:43:02PM +0000, Tvrtko Ursulin wrote:
> 
> 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? :)

self-tuning busy loads using the blitter/rendercopy. We have bazillion of
existing copypasta in igt tests for this, would be great if someone
extracts it into a real igt helper library and converts everyone over.

Iirc the one in kms_flip or gem_wait is probably the best starting point.
There's no way afaik to block a batch on an mbox or similar from
userspace.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch