I've not read the series yet, but I think we should also "lose" the context on a command submission failure and drop all future CS requests for that context. You don't need a working GPU reset for that and it's a very sensible thing to do. It would also be a good test for all the interfaces. Marek <div class="gmail_extra"> <div class="gmail_quote">On Oct 4, 2016 10:11 AM, "Nicolai Hähnle" <<a href="mailto:nhaehnle@gmail.com" target="_blank">nhaehnle@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all, so after the discussion on the KHR_robustness patch, it seemed like a good idea to set up a path by which the driver can notify the state tracker of a device reset even when it isn't explicitly queried for. This series does that, with an initial implementation for radeon. The current radeon implementation is still a bit sketchy. Really, I think that it should be the kernel's job to notify us of resets via appropriate error codes on relevant ioctls. In particular, we have no choice but to rely on the kernel for implementing the right semantics for fences during/after a reset. Then again, it's all a bit academic anyway unless the kernel's reset mechanism is bullet-proof. In any case, I think the interface and state tracker bits are sound, and the radeon parts can be improved once the kernel driver gets better. Please review! Thanks, Nicolai _______________________________________________ mesa-dev mailing list <a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a> <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a> </blockquote></div></div>