On Thu, Jun 18, 2015 at 05:35:29PM +0200, Daniel Vetter wrote: > On Thu, Jun 18, 2015 at 04:27:52PM +0100, Chris Wilson wrote: > > On Thu, Jun 18, 2015 at 04:49:49PM +0200, Daniel Vetter wrote: > > > Guc is different since we really must have it ready for execbuf, and for > > > that usecase a completion at drm_open time sounds like the right thing. > > > > But do we? It would be nice if we had a definite answer that the hw was > > ready before we started using it in anger, but I don't see any reason > > why we would have to delay userspace for a slow microcode update... > > > > (This presupposes that userspace batches are unaffected by GuC/execlist > > setup, which for userspace sanity I hope they are - or at least using > > predicate registers and conditional execution.) > > Well I figured a wait_completion or flush_work unconditionally in execbuf > is not to your liking, and it's better to keep that in open. But I think > we should be able to get away with this at execbuf time. Might even be > better since this wouldn't block sw-rendered boot-splashs. > > But either way should be suitable I think. I am optimistic that we can make the request interface robust enough to be able queue up not only the ring initialisation and ppgtt initialisation requests, but also userspace requests. If it all works out, we only need to truly worry about microcode completion in hangcheck. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
