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@xxxxxxxxx> > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > Cc: Dave Gordon <david.s.gordon@xxxxxxxxx> > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
