On Wed, Jul 01, 2015 at 02:17:28PM +0100, Chris Wilson wrote: > 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... set_wedged in your patch doesn't have the wakeup to kick waiters. And maybe we want to be somewhat more synchronous with with init fail than gpu hangs, for userspace to make better decisions. Also we still have that issue that sometimes an -EIO escapes into modeset code. And yes this is mean to provide the async init for the request firmware. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
