[Intel-gfx] [PATCH] drm/i915: Asynchronously initialise the GPU state
Chris Wilson
chris at chris-wilson.co.uk
Wed Jul 1 06:17:28 PDT 2015
On Wed, Jul 01, 2015 at 03:07:18PM +0200, Daniel Vetter wrote:
> On Wed, Jul 01, 2015 at 10:27:21AM +0100, Chris Wilson wrote:
> > Dave Gordon made the good suggestion that once the ringbuffers were
> > setup, the actual queuing of commands to program the initial GPU state
> > could be deferred. Since that initial state contains instructions for
> > setting up the first power context, we want to execute that as earlier
> > as possible, preferrably in the background to userspace. Then when
> > userspace does wake up, the first time it opens the device we just need
> > to flush the work to be sure that our commands are queued before any of
> > userspace's. (Hooking into the device open should mean we have to check
> > less often than say hooking into execbuffer.)
> >
> > Suggested-by: Dave Gordon <david.s.gordon at intel.com>
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > Cc: Dave Gordon <david.s.gordon at intel.com>
>
> Just before this gets a bit out of hand with various patches floating
> around ... I really meant it when I said that we should have a proper
> design discussion about this in Jesse's meeting first.
What more is there to design? Asynchronously loading the submission port
is orthogonal to the task of queuing requests for it, and need not block
request construction (be it kernel or userspace). Dave just identified
some work that we didn't need to do during module load. I don't think he
would propose using it for loading guc firmware, that would just be
silly...
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
More information about the Intel-gfx
mailing list