[Intel-gfx] [RFC v2] drm/i915: Android native sync support
Daniel Vetter
daniel at ffwll.ch
Sat Jan 24 01:47:31 PST 2015
On Fri, Jan 23, 2015 at 5:49 PM, Tvrtko Ursulin
<tvrtko.ursulin at linux.intel.com> wrote:
> Could you please translate this into something understandable by newcomers?
> :)
I don't know which parts are confusing without questions so please ask
them ... the questions below about scheduler interactions seem fairly
advanced ;-)
> 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?
Yeah that's all we need to get started.
> Then how does future scheduling come into picture in your views above?
Scheduler just takes a pile of fences from the execbuf code and
doesn't care that much whether they come from implicit or explicit
syncing modes. Which means we'll always combine all the fences (both
implicit and explicit) when figuring out depencies.
> 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?
execbuf always needs to obey the implicit fences since if it doesn't
our shrinker will start to unmap objects which are still in use. Not
good.
So if you want to do an execbuf with _only_ explicit syncing then you
need to lie about the write domains in your relocations: The kernel
allows parallel reads nowadays, so if you never set a write domain
there will be no implicit syncing (except with the shrinker, and as
explained that is mandatory anyway). Only write domains create
implicit sync depencies between batches, so if there's none you can
control all the depencies between batches with explicit fences.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
More information about the Intel-gfx
mailing list