| Summary: | destroy GL context on stall recovery | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Stanisław Halik <sthalik> |
| Component: | Mesa core | Assignee: | mesa-dev |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | minor | ||
| Priority: | medium | ||
| Version: | git | ||
| Hardware: | All | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Stanisław Halik
2014-08-28 14:08:42 UTC
Sorry, but I don't understand this bug report. What stalls are you talking about? What recovery process? CP/CS stall, recovery after several seconds, in dmesg. If GPU hangs, recovery, GLX process causing it runs as previous, it'll repeat the stall. Just to be extra-clear: Talking about GPU reset procedure. The one where dmesg prints register state. Is that enough context or is further info needed? -sh I don't think there is a Mesa core bug here. We support the GL_ARB_robustness extension, which allows applications to detect GPU hangs, and possibly tell whether or not it was their fault. (This requires kernel driver support for your particular hardware.) Such applications can decide to gracefully stop what they're doing to avoid continuing to hang the GPU. For example, Chrome will disable WebGL on pages if it detects GPU hangs, but otherwise keeps working. The kernel driver for your hardware may also ban processes from accessing the GPU if they hang it too many times. This guards against applications that crash a lot but don't use ARB_robustness. For example, the Intel driver does this. If your hardware driver does not, feel free to open a bug against your kernel driver. We can't solve a problem like this for Mesa as a whole. It's very driver specific. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.