Announcement

Collapse
No announcement yet.

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

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

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

    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?pag...xt-Restoration

  • #2
    ...a few dozen likes of code...

    Comment


    • #3
      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?

      Comment


      • #4
        Originally posted by dwagner View Post
        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.

        Comment


        • #5
          Originally posted by RomuloP View Post
          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.

          Comment


          • #6
            Originally posted by dwagner View Post
            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.

            Comment

            Working...
            X