On Fri, Dec 13, 2013 at 8:26 PM, Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> wrote: > Obviously still need a lot of work (and I didn't quite get the patch > split correctly, I meant commit the first bits earlier). > > I think the approach may be sound though, and is actually not too hard > to get right with all the cross checking we have in place. Things to > fix: > - modeset cross check - we don't want to sync after a mode set just to > check, maybe we could put this off until the actual enable happens > - split flushing of disable and enable to actually make full mode sets > fast When I've last pondered this async_domains looked like a suitable thing. We can create as many of them as we want or reuse them, and they have a nice primitive for syncing up with all previously launched async work items. I haven't checked how well they take being called from different processes (since we still want to do the very last sync from a work item to fully asynchronously launch the the state checker). But my impression was that they fit the bill or are at least fairly close. We could also try to abuse them in the driver load/suspend/resume code and e.g. run the gem restore in parallel with early modeset stuff. I'm not sure whether the syncing would be flexible enough though. But worth a shot imo. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
