Announcement

Collapse
No announcement yet.

Rusticl Can Run Atop Zink Gallium3D Atop Intel's ANV Vulkan Driver

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

  • Rusticl Can Run Atop Zink Gallium3D Atop Intel's ANV Vulkan Driver

    Phoronix: Rusticl Can Run Atop Zink Gallium3D Atop Intel's ANV Vulkan Driver

    Red Hat's Karol Herbst has managed to get his Rust-based OpenCL implementation "Rusticl" running atop the Zink Gallium3D driver that in turn runs atop Vulkan drivers...

    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
    Why does rusticl need a gallium driver? Doesn't it convert things to SPIRV? Shouldn't any driver capable of ingesting SPIRV be able to work with Rusticl?

    Comment


    • #3
      Regarding the ability of using Zink for non top-of-the-line Vulkan drivers and hardware (i.e. most ARM SOCs like the mentioned PowerVR hardware), seeing the current requirements of Zink in terms of what is required by both the vulkan driver and the hardware (see Mesa documentation) I find it incredibly hard that Zink can be used for anything other than new (desktop targeted) hardware (i.e. intel, nvidia, amd).

      Compare the list of requirements with what is exposed in Vulkan GPU Info, for example for a Mali G52 for which the Panfrost driver exposes OpenGL 3.1, Zink is unable to provide even OpenGL 3.0 for the lack of conditional rendering. For an Adreno 660, which the Freedreno exposes OpenGL 3.3 Zink is unable to provide OpenGL 3.2 for lack of shaderTessellationAndGeometryPointSize​.
      And, yes I know, developers should test for features instead of versions, and that probably means that you can get more mileage from Zink with respects to native OpenGL drivers.

      Understand that I'm not criticising the work put in by Mike in both Zink and Mesa, I truly think he's doing amazing work, work that has tons of uses (validation, new hardware enablement, etc). I'm just saying that (existing) mobile GPUs, due to the difference in target use-cases, is not the kind of hardware that is best served by Zink (unless Mike decides to write even more super good code that would help) and is naive on our part to expect so.

      Comment


      • #4

        6w2vda.jpg


        Please enter a message with at least 5 characters​​

        Comment


        • #5
          Can confirm that the same thing works with RADV as well. Karol and me sat down after his lightning talk and tried it.

          Comment


          • #6
            That's really interesting. Among projects attempting to implement OpenCL over Vulkan there is clvk and PoCL with vulkan, both being based on Google's clspv. But this rusticl-over-zink-over-vulkan is already more complete than them if it can run LuxMark.

            Now the obligatory question would be performance: rusticl also provides a CPU-based OpenCL implementation thanks to llvmpipe, but something like PoCL is likely more performant at this task.

            But anyway this is really a demonstration of how well Mesa is architectured, when someone starts an OpenCL driver and the same platform starts to support Intel, Nvidia and AMD GPU hardware, plus CPU hardware and vulkan drivers.
            Last edited by illwieckz; 07 October 2022, 10:18 AM.

            Comment


            • #7
              Originally posted by fahrenheit View Post
              Regarding the ability of using Zink for non top-of-the-line Vulkan drivers and hardware (i.e. most ARM SOCs like the mentioned PowerVR hardware), seeing the current requirements of Zink in terms of what is required by both the vulkan driver and the hardware (see Mesa documentation) I find it incredibly hard that Zink can be used for anything other than new (desktop targeted) hardware (i.e. intel, nvidia, amd).
              That is true for most older of current GPUs on the market, but PowerVR for example has quite a modern and feature rich GPU. Not sure if it will support all the necessary bits for good Zink support, but I think it will be much better that other ARM SoCs.
              Also maybe this will push them to actually support all those Vulkan features, as now they are useful not just for gaming?

              Comment


              • #8
                Some targeted effort to make Zink work as a global GL replacement while keeping ~100% Xorg and Wayland compositors compatibility would be most welcome.

                Comment


                • #9
                  Now I want to see RustiCL running on top of Zink, running on top of Vulkan, running on top of Metal through MoltenVK.

                  Comment


                  • #10
                    Originally posted by fahrenheit View Post
                    Compare the list of requirements with what is exposed in Vulkan GPU Info, for example for a Mali G52 for which the Panfrost driver exposes OpenGL 3.1, Zink is unable to provide even OpenGL 3.0 for the lack of conditional rendering. For an Adreno 660, which the Freedreno exposes OpenGL 3.3 Zink is unable to provide OpenGL 3.2 for lack of shaderTessellationAndGeometryPointSize​.
                    And, yes I know, developers should test for features instead of versions, and that probably means that you can get more mileage from Zink with respects to native OpenGL drivers.
                    This information is outdated and is not the case anymore. At least Turnip has been recently updated to expose the necessary functionality. See Mike's Zink talk for details.

                    Comment

                    Working...
                    X