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 On Oct 4, 2016 10:11 AM, "Nicolai Hähnle" <[email protected]> wrote: > 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 > [email protected] > https://lists.freedesktop.org/mailman/listinfo/mesa-dev >
_______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
