Announcement

Collapse
No announcement yet.

Vulkan 1.2.139 Released With VK_EXT_robustness2 Extension

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

  • Vulkan 1.2.139 Released With VK_EXT_robustness2 Extension

    Phoronix: Vulkan 1.2.139 Released With VK_EXT_robustness2 Extension

    The routine Vulkan 1.2.139 maintenance update brings with it two new extensions...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Typo;

    Originally posted by phoronix View Post
    only should should be used when necessary.

    Comment


    • #3
      In order to implement GPU reset/hot-insertion/removal under Linux, every application, the compositor and the display server, if any (like X.Org) must use any available robustness capability.

      The difference is that OpenGL is designed around a static hardware model, in where the hardware isn't expected to change at any time. Therefore it assumes that all data structures stored under the graphics card(s) (e.g. textures) will exist forever.
      This causes drastic failure under low memory pressure and if the graphics card were to be removed.

      DirectX, being oriented towards consumer (e.g. gaming) usage, went the other way, and assumed that "textures can be destroyed at any time by the system".
      This paved the way for a GPU reset/hot-swap mechanism under Windows, and the ability to play games under memory pressure (despite very low speeds).

      The problem is that not every application uses robustness extensions, and I am not so sure about Vulkan.
      My best idea would be the following:

      1. "Volatile": applications that don't use any robustness extensions. If textures are destroyed (e.g. by a GPU reset or hot-swap) they will not be recovered. Fastest.
      2. "Pseudo-robust" mode: applications that don't use any robustness extensions. Textures are copied to system memory as well, and recovered by the driver in case of their destruction in the GPU memory. This is useful for critical applications, but does hamper performance.
      3. "Robust" mode: applications that do support the extensions. Nothing else is done.

      Comment


      • #4
        How does it work with GPU compatibility?
        I mean... Khronos releases Vulkan 1.2 and the GPU company says: "Hey my GPU is Vulkan 1.2 compatible".
        But now we have Vulkan 1.2.1xx with new commands/features. Is it possible, that this GPU supports Vulkan 1.2.0 but not Vulkan 1.2.1xx or is there some special fallback or something? How does it work, that 1.2.1xx is still complete 1.2.0 GPU "compatible" ?
        Last edited by Pranos; 27 April 2020, 03:13 AM.

        Comment


        • #5
          How does it work with GPU compatibility?
          Look at the names. VK_EXT are extensions they are optional and don't need to be implemented to be compliant.

          The other API entry has a vendor string in this case VK_QCOM and is specific to that vendor and are optional as well.

          Comment


          • #6
            I guess these new extensions are optional. So drivers are 1.2 compatible even without implementing the new extensions, as long as they don't advertise supporting that extension. Of course when Khronos releases the Vulkan 1.3 or 2.0 specification, they can declare some extensions to be obligatory for 1.3/2.0, and then applications don't have to check if the extension is supported if drivers claim 1.3/2.0 compatibility.

            Note I'm not sure this is really the way the handle it, but appears to be the only sane way IMO.

            Comment


            • #7
              i wish if they add new extensions for video playback and emulation next

              Comment


              • #8
                Originally posted by tildearrow View Post
                In order to implement GPU reset/hot-insertion/removal under Linux, every application, the compositor and the display server, if any (like X.Org) must use any available robustness capability
                What this has to do with robustness, which is bounds checking?

                Originally posted by tildearrow View Post
                under low memory pressure
                Driver is free to migrate vram conents to system memory. No need to destroy anything.
                Last edited by xpue; 06 May 2020, 10:01 PM.

                Comment


                • #9
                  Originally posted by xpue View Post
                  What this has to do with robustness, which is bounds checking?
                  Are you kidding me?

                  I thought robustness extensions were for something like checking if a texture still exists?!?!?!?!

                  Originally posted by xpue View Post
                  Driver is free to migrate vram conents to system memory. No need to destroy anything.
                  And introduce lag spikes that are worse than if the game were to handle them.
                  Also tell me how would the driver do that in the event of a card hot-swap or reset.

                  Comment


                  • #10
                    Originally posted by tildearrow View Post
                    I thought
                    There is VK_ERROR_DEVICE_LOST for things you describe.

                    Originally posted by tildearrow View Post
                    And introduce lag spikes
                    But this is what windows does...

                    Comment

                    Working...
                    X