Intel's OpenGL Mesa Driver To Better Handle Recovery In Case Of GPU Hangs

[phoronix]

Phoronix: Intel's OpenGL Mesa Driver To Better Handle Recovery In Case Of GPU Hangs

It's sure been a busy week in the Intel open-source graphics driver space... The latest improvement is a patch series providing better context restoration in the case of GPU hangs...

http://www.phoronix.com/scan.php?page=news_item&px=Intel-Mesa-Context-Restoration

[Mthw]

...a few dozen likes of code...

[dwagner]

I hope this does not mean Intel will follow AMD's example in considering GPU hangs a normal thing to happen.
Does anyone know a good reason why GPU hangs should be more acceptable or "unavoidable" than CPU hangs?

[RomuloP]

I hope this does not mean Intel will follow AMD's example in considering GPU hangs a normal thing to happen.
Does anyone know a good reason why GPU hangs should be more acceptable or "unavoidable" than CPU hangs?

Because GPUs do not produce sensitive data with OpenGL? It is the same logic of using UDP for videos, the kind of information presented is much more resilient to failure than lets say checksums. At last for the uses OpenGL has it is totally acceptable, if we where talking of OpenCL it would be 100% unacceptable, as it is used to manipulate more sensitive data, like checksums and scientific calculus. As CPUs mostly manipulate very sensitive to corruption data it is not a good idea.

[dwagner]

Because GPUs do not produce sensitive data with OpenGL?

Given that screens are the predominant place where sensitive information is handed over from computers to humans, I would argue that the confidentiality, integrity and availability of almost any IT function is at stake when GPU drivers produce incorrect results, crash, or expose data to unauthorized access.

[RomuloP]

Given that screens are the predominant place where sensitive information is handed over from computers to humans, I would argue that the confidentiality, integrity and availability of almost any IT function is at stake when GPU drivers produce incorrect results, crash, or expose data to unauthorized access.

Image corruption do not result in sensitive data misinterpretation and do not result in storing corrupted sensitive information or in sensitive information being lost (at last when the stack is developed taking recovery as a possibility, otherwise will bring entire kernel down, what is not reasonable when the state is recoverable). Also GPU security flaws generally have nothing to do with GPUs bugs that produce KP or hard corrupted driver state.

Anyway it is not a excuse for more bugs in GPUs neither for more security bugs, people could argue exceptions are a excuse for more bugs in software, no, the point is that there is no reason on bringing the entire kernel down because of corrupted frame-buffer or any recoverable case where the state can be reb, it should be handled orthogonally as any recoverable error, recovered, in a secure manner.