Mesa 25.0 Clover OpenCL Drops Support For NIR Drivers

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • phoronix
    Administrator
    • Jan 2007
    • 67395

    Mesa 25.0 Clover OpenCL Drops Support For NIR Drivers

    Phoronix: Mesa 25.0 Clover OpenCL Drops Support For NIR Drivers

    As part of the transition to eventually drop the long dormant Clover OpenCL state tracker from Mesa's Gallium3D codebase in favor of the modern OpenCL Rusticl Rust-written driver, Mesa 25.0 has ended Clover support for NIR-based 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
  • Eirikr1848
    Senior Member
    • Jan 2022
    • 437

    #2
    What’s actually affected? Does not seem like a major loss…

    Comment

    • luno
      Senior Member
      • May 2022
      • 260

      #3
      Originally posted by Eirikr1848 View Post
      What’s actually affected? Does not seem like a major loss…
      it feels OpenVG

      Comment

      • R41N3R
        Senior Member
        • Jul 2017
        • 1113

        #4
        So r600 is now the blocker to get rid of the unmaintained clover, which is a little unfortunate as r600 is too limited for rusticl (as far as I know) and there is no alternative like rusticl/zink/Vulkan. But well, getting rid of NIR in clover is a good first step.

        Comment

        • ahrs
          Senior Member
          • Apr 2021
          • 587

          #5
          Originally posted by R41N3R View Post
          So r600 is now the blocker to get rid of the unmaintained clover, which is a little unfortunate as r600 is too limited for rusticl (as far as I know) and there is no alternative like rusticl/zink/Vulkan. But well, getting rid of NIR in clover is a good first step.
          Could they move it to Mesa Amber like they did with some of the other older drivers? Let whoever is still left wanting it get it from there and provide best-effort support.

          Comment

          • Developer12
            Senior Member
            • Dec 2019
            • 1584

            #6
            Originally posted by R41N3R View Post
            So r600 is now the blocker to get rid of the unmaintained clover, which is a little unfortunate as r600 is too limited for rusticl (as far as I know) and there is no alternative like rusticl/zink/Vulkan. But well, getting rid of NIR in clover is a good first step.
            There's no real reason it couldn't work. Indeed, it's already work in progress: https://www.phoronix.com/news/R600g-...l-Experimental

            It just needs someone to look at it. So many drivers, so little time.

            Comment

            • R41N3R
              Senior Member
              • Jul 2017
              • 1113

              #7
              Originally posted by Developer12 View Post

              There's no real reason it couldn't work. Indeed, it's already work in progress: https://www.phoronix.com/news/R600g-...l-Experimental

              It just needs someone to look at it. So many drivers, so little time.
              Thanks, I'm aware of that. I had a discussion in mind, that happened in a merge request:
              This adds all the code to implement cl_ext_buffer_device_address in a sane way. This will be required by chipStar (HIP on CL) as an alternative path besides to...


              Comment from Dave Airlie: "I don't think rusticl can support the new way and support drivers that can't do user VM mgmt. R600 hw (pre-cayman) cannot do hw vm mgmt so it's unlikely it will ever support this interface.

              At that point we get to decide if rusticl/r600 makes sense to keep the other path around for, or if we just nope out of it completely."

              Comment

              • R41N3R
                Senior Member
                • Jul 2017
                • 1113

                #8
                Originally posted by ahrs View Post

                Could they move it to Mesa Amber like they did with some of the other older drivers? Let whoever is still left wanting it get it from there and provide best-effort support.
                According to Erik Faye-Lund the amber branch is not an option for clover due to technical reasons:
                I'm not expecting this to be merged today. I'm not expecting it to be merged next week. But I'm not sure I see any...

                Comment

                • rmfx
                  Senior Member
                  • Jan 2019
                  • 764

                  #9
                  Yeah get rid of the rotten, and focus on the fresh stuff.

                  Comment

                  • Developer12
                    Senior Member
                    • Dec 2019
                    • 1584

                    #10
                    Originally posted by R41N3R View Post

                    Thanks, I'm aware of that. I had a discussion in mind, that happened in a merge request:
                    This adds all the code to implement cl_ext_buffer_device_address in a sane way. This will be required by chipStar (HIP on CL) as an alternative path besides to...


                    Comment from Dave Airlie: "I don't think rusticl can support the new way and support drivers that can't do user VM mgmt. R600 hw (pre-cayman) cannot do hw vm mgmt so it's unlikely it will ever support this interface.

                    At that point we get to decide if rusticl/r600 makes sense to keep the other path around for, or if we just nope out of it completely."
                    My reading of that thread, especially karol's comment upthread, is that the way the driver works needs to be cleaned up and reworked, and those internal interfaces might get reworked anyway. It's mostly all a matter of someone (perhaps triangle, as someone mentioned) being interested enough to put the work in.

                    Comment

                    Working...
                    X