On 01/23/2015 03:53 PM, Daniel Vetter wrote:
On Fri, Jan 23, 2015 at 02:02:44PM +0000, Tvrtko Ursulin wrote:
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@xxxxxxxxxxxxxxxx>
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.
Yeah that's kind the big behaviour difference (at least as I see it)
between explicit sync and implicit sync:
- with implicit sync the kernel attachs sync points/requests to buffers
and userspace just asks about idle/business of buffers. Synchronization
between different users is all handled behind userspace's back in the
kernel.
- explicit sync attaches sync points to individual bits of work and makes
them explicit objects userspace can get at and pass around. Userspace
uses these separate things to inquire about when something is
done/idle/busy and has its own mapping between explicit sync objects and
the different pieces of memory affected by each. Synchronization between
different clients is handled explicitly by passing sync objects around
each time some rendering is done.
The bigger driver for explicit sync (besides "nvidia likes it sooooo much
that everyone uses it a lot") seems to be a) shitty gpu drivers without
proper bo managers (*cough*android*cough*) and svm, where there's simply
no buffer objects any more to attach sync information to.
So attaching explicit sync objects to buffers doesn't make that much
sense by default. Except when we want to mix explicit and implicit
userspace, then we need to grab sync objects out of dma-bufs and attach
random sync objects to them at the border. Iirc Maarten had dma-buf
patches for exactly this.
Could you please translate this into something understandable by
newcomers? :)
In the context of Jesse's work I took over - there my impressions was
you were mostly happy just needed converting from dedicated ioctl to
execbuf?
Then how does future scheduling come into picture in your views above?
Submitting something with an input fence meaning "execute this work when
this fence has been done" - when mixing and matching fences from
different sources etc. How do you envisage that to work in implicit world?
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
