Quoting Daniel Vetter (2017-07-03 09:03:36) > On Fri, Jun 30, 2017 at 5:39 PM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > >> Yeah, but my point is that this here is an extremely fancy and fragile > >> (and afaics in this form, incomplete) fix for something that in the past > >> was fixed much, much simpler. Why do we need this massive amount of > >> complexity now? Who's asking for all this (we don't even have anyone yet > >> asking for fully queued atomic commits, much less on gen4)? > > > > It was never "fixed", it was always borked; broken by design. > > Hm, what was broken by design in gen3/4 reset? We never bothered to > resubmit rendering when the gpu died, but besides that I'm not aware > of a deisgn issue in that logic. We nuked in-flight pageflips (and > restored those), and we stalled for any pending modesets (grabbing > locks did that since all modesets where blocking), and that made sure > the hw was in a consistent state. KMS reset was taking mutexes within reset without any means of breaking the inherent deadlock, instead relying on something else to magically fix it. We only ever engineered around struct_mutex for reset, the remains of the deadlock upon struct_mutex within modeset is an issue but not the one causing trouble here. Please do note the bugs that indicate that even without modeset reset, hw is not in a consistent state. -Chris _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
