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

[Tvrtko Ursulin]

On 01/23/2015 11:27 AM, Chris Wilson wrote:
> On Fri, Jan 23, 2015 at 11:13:14AM +0000, Tvrtko Ursulin wrote:
>> From: Jesse Barnes <jbarnes at virtuousgeek.org>
>>
>> Add Android native sync support with fences exported as file descriptors via
>> the execbuf ioctl (rsvd2 field is used).
>>
>> This is a continuation of Jesse Barnes's previous work, squashed to arrive at
>> the final destination, cleaned up, with some fixes and preliminary light
>> testing.
>>
>> GEM requests are extended with fence structures which are associated with
>> Android sync fences exported to user space via file descriptors. Fences which
>> are waited upon, and while exported to userspace, are referenced and added to
>> the irq_queue so they are signalled when requests are completed. There is no
>> overhead apart from the where fences are not requested.
>>
>> Based on patches by Jesse Barnes:
>>     drm/i915: Android sync points for i915 v3
>>     drm/i915: add fences to the request struct
>>     drm/i915: sync fence fixes/updates
>>
>> To do:
>>     * Extend driver data with context id / ring id (TBD).
>>
>> v2:
>>     * Code review comments. (Chris Wilson)
>>     * ring->add_request() was a wrong thing to call - rebase on top of John
>>       Harrison's (drm/i915: Early alloc request) to ensure correct request is
>>       present before creating a fence.
>>     * Take a request reference from signalling path as well to ensure request
>>       sticks around while fence is on the request completion wait queue.
>
> Ok, in this arrangement, attaching a fence to the execbuf is rather meh
> as it is just a special cased version of attaching a fence to a bo.

Better meh than "no"! :D

My understanding is this is what people want, with the future input 
fence extension (scheduler).

Anyway.. v2 is broken since it unreferences requests without holding the 
mutex, more so from irq context so I need to rework that a bit.

Regards,

Tvrtko