Announcement

Collapse
No announcement yet.

Zink OpenGL-On-Vulkan Lands Tessellation Shader Support In Mesa 21.0

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

  • Zink OpenGL-On-Vulkan Lands Tessellation Shader Support In Mesa 21.0

    Phoronix: Zink OpenGL-On-Vulkan Lands Tessellation Shader Support In Mesa 21.0

    Landing in Mesa 21.0 on Tuesday was support for OpenGL tessellation shaders (ARB_tessellation_shader) with the Zink Gallium3D code implementing generic OpenGL support atop Vulkan...

    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
    I am loving how quickly this is all coming together

    Comment


    • #3
      This is getting awkward for those that made the Terascale drivers in Mesa. Soon even an imaginary video card beats their ass.

      Comment


      • #4
        Originally posted by eydee View Post
        This is getting awkward for those that made the Terascale drivers in Mesa. Soon even an imaginary video card beats their ass.
        Not quite, the underlying vulkan drivers zink is using already have this feature

        Comment


        • #5
          Hope the patches from Mike get reviewed a little faster so that OpenGL 4.6 support will land in time for Mesa 21.0 :-)

          Comment


          • #6
            Originally posted by boxie View Post
            I am loving how quickly this is all coming together
            True! Just ~500 new lines but big impact!

            Comment


            • #7
              Don't be too excited yet. There is still few hundredth patches to go.

              Also the tessellation kind of works, but is also broken with zink. https://gitlab.freedesktop.org/zmike/mesa/-/issues/22

              But it will get fixed, no worries.

              If you want to be excited, I can tell you that I measured about 75%-85% performance of radeonsi, when running zink+radv_aco, across variety of complex workloads. At least in highly GPU intensive stuff, indicating the generated shader code is still not as good as it could be. It can go as low as 66% on average, in less GPU bound scenarios. And multi threading support is broken at the moment. But, it is progressing. And we are squashing bugs, like (most) memory leaks, and (all) VRAM leaks, just get patched yesterday.

              Considering that correctness were the primary goal initially, and there are some Vulkan optimisations, but almost nothing put into SPIR-V optimisations, it is a very good result. I am pretty sure we can get 95% performance of radeonsi, and maybe more in the future.

              The formal review during merge request is going to probably find few extra bugs here and there.

              For anybody curious, testing zmike/zink-wip branch, is really recommended.

              Also if you want to compare performance with mangohud, be sure to take a look at this patch https://github.com/flightlessmango/MangoHud/pull/443
              Last edited by baryluk; 23 December 2020, 11:21 AM.

              Comment


              • #8
                baryluk do you think it is theoretically possible to go over 100%??

                Comment


                • #9
                  Originally posted by Creak View Post
                  baryluk do you think it is theoretically possible to go over 100%??
                  Maybe in 2022.

                  Right now the shaders go though the glsl -> tgsi/nir -> spirv -> nir -> aco ir -> isa. A lot of of context is loss, in the optimiser phases, or lack of them. Maybe some MESA vulkan extension could be made to feed directly nir back to radv, to improve a latency and performance a bit. This is really very low on priority list for foreseeable future.

                  Plus, any draw calls, and bindings stuff, goes though a lot of translation layers, adding a bit to CPU overhead. zink tries to cache a lot of stuff, but still, there will be some minor stutter here and there. This are at the moment something that can't be avoided, but In the future it could be improved.

                  I think 105% is possible. But that would require a lot of work, in the nir, optimiser, better memory allocator (it is now extremely primitive and naive). I think If we reach 90-95% consistently (on radv and anv), that would be a huge success. Once zink has fully working threading (it is there, just buggy), it could get further gains, in some games and apps, but again radeonsi is already doing really good job. The main maintainer of radeonsi is also primary author of NIR, and radeonsi is most optimized driver in Mesa, more so even than intel (who have more people maintaining it!).

                  I do expect the zink to show some over 100% (maybe 150%?) gains in some other drivers, like broadcom (Raspberry Pi 3, 4). But not necessarily.

                  I also hope the zink -> MoltenVK -> metal, and zink -> nvidia, or zink on Windows/WSL, could show some interesting performance benefits, and be faster than vendor provided OpenGL drivers in many cases. In fact it is very likely. This work is ongoing.
                  Last edited by baryluk; 23 December 2020, 03:58 PM.

                  Comment


                  • #10
                    66% will still be faster than being stuck with software rendering under Xwayland due to Nvidia not providing drivers.

                    90-95 on open source drivers I would say would be realistic top side zink vs open source Intel and amd drivers. Thing to remember as zink finds areas to improve things the other open source drivers in Mesa will learn from it so if Zink finds a 105% somewhere its likely in a generation of mesa drivers it will be back to 90-95%. Of course 90-95% is nothing to sneeze at.

                    There are a lot of cases where 66% is good enough like for a custom version of opengl for a old game depending on some horrible quirk of opengl that should never be implemented that way. Even at 90% there will be a lot of good enough cases. I really do wounder at 90% of performance does this cover 99.9% of the opengl use case well enough?

                    Comment

                    Working...
                    X