Announcement

Collapse
No announcement yet.

Zink OpenGL-On-Vulkan Implements Front-End Shader Caching

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

  • Zink OpenGL-On-Vulkan Implements Front-End Shader Caching

    Phoronix: Zink OpenGL-On-Vulkan Implements Front-End Shader Caching

    Adding to the long list of Zink OpenGL-on-Vulkan driver improvements coming with Mesa 22.3 this quarter is now a working Mesa front-end shader caching implementation...

    https://www.phoronix.com/news/Zink-Front-End-Caching

  • #2
    Ah, that may explain why some apps may perform less well than some others. For example last year I compared Unvanquished on the same R9 390X with radeonsi, amgdpu-pro, fglrx and zink-over-radv, and Unvanquished on zink was performing like fglrx (so, like an older official driver, so not bad), but Unvanquished implements it own shader caching so any lack of caching in underlying software would not have any impact anyway. That may be different with other apps.

    Comment


    • #3
      Why does this need to be done per driver and not just in the generic gallium part?

      Comment


      • #4
        Originally posted by geearf View Post
        Why does this need to be done per driver and not just in the generic gallium part?
        The gallium part is able to do the caching, but the driver has to track it's internal state and inform the gallium layer when something has changed that needs to generate a new shader for the cache. That's all internal and specific to each driver/hardware combination.

        In this case, it seems like the main thing that needed to be tracked was the vulkan pipeline cache uuid that zink generates.

        Comment


        • #5
          Originally posted by smitty3268 View Post

          The gallium part is able to do the caching, but the driver has to track it's internal state and inform the gallium layer when something has changed that needs to generate a new shader for the cache. That's all internal and specific to each driver/hardware combination.

          In this case, it seems like the main thing that needed to be tracked was the vulkan pipeline cache uuid that zink generates.
          I thought this was all in the front end going from GLSL to NIR, which wouldn't seem to depend on what the driver does no?

          Thank you!

          Comment


          • #6
            Originally posted by geearf View Post

            I thought this was all in the front end going from GLSL to NIR, which wouldn't seem to depend on what the driver does no?

            Thank you!
            There are two parts that can be cached. Part 1, where the GLSL or SPIR-V is converted to NIR and optimized (the shader compile). And part 2, where the NIR is converted to binary code and optimized again (the shader linking).

            Part 1 can be generic, but part 2 is hardware specific, and it can be considerably slower than just generating the NIR part so it's important to have that cached as well.

            Comment


            • #7
              Originally posted by smitty3268 View Post

              There are two parts that can be cached. Part 1, where the GLSL or SPIR-V is converted to NIR and optimized (the shader compile). And part 2, where the NIR is converted to binary code and optimized again (the shader linking).

              Part 1 can be generic, but part 2 is hardware specific, and it can be considerably slower than just generating the NIR part so it's important to have that cached as well.
              Right, but isn't the front end just part 1?

              Thank you!

              Comment

              Working...
              X