Announcement

Collapse
No announcement yet.

Microsoft Wants To Add DirectX + HLSL Support To The Upstream LLVM/Clang Compiler

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

  • Microsoft Wants To Add DirectX + HLSL Support To The Upstream LLVM/Clang Compiler

    Phoronix: Microsoft Wants To Add DirectX + HLSL Support To The Upstream LLVM/Clang Compiler

    Microsoft has laid out a proposal whereby they are hoping to contribute support for DirectX, the HLSL shading language, and Vulkan graphics support to the upstream LLVM/Clang compiler...

    https://www.phoronix.com/scan.php?pa...-Upstream-LLVM

  • #2
    question: is this something actually useful for linux users, or is this just more of the linux hardware accel when run on top of windoze crap?

    Comment


    • #3
      Well, as it would be in LLVM and presumably maintained by MS themselves, it could be used by anyone, including DXVK and Mesa. It would still require some work, but could be more compatible that the current solutions, or at least have different bugs.

      Comment


      • #4
        Originally posted by lectrode View Post
        question: is this something actually useful for linux users, or is this just more of the linux hardware accel when run on top of windoze crap?
        This is about adding DirectX HLSL support to LLVM. Nothing to do with Linux.

        It’s always useful to have choice of compilers. And to be honest, LLVM is an modern and nicely maintained compiler. Would be insane to roll your own, unless you have really specific requirements.

        I think Microsoft will eventually deprecate MSVC and fully embrace LLVM.

        Comment


        • #5
          Originally posted by lectrode View Post
          question: is this something actually useful for linux users, or is this just more of the linux hardware accel when run on top of windoze crap?
          Neither directly, this is putting a shader compiler into LLVM to turn HLSL into low level code useable by the GPU drivers. It may be useful for Wine, and HLSL -> SPIR-V may be useful on both WIndows and Linux... otherwise this is about as useful as Microsoft saying they're going to drop MSVC completely and switch purely to LLVM for Windows. Them helping themselves may help Linux by helping LLVM, but it's got nothing intrinsically to do with Linux.

          Comment


          • #6
            Originally posted by amxfonseca View Post

            This is about adding DirectX HLSL support to LLVM. Nothing to do with Linux.

            It’s always useful to have choice of compilers. And to be honest, LLVM is an modern and nicely maintained compiler. Would be insane to roll your own, unless you have really specific requirements.

            I think Microsoft will eventually deprecate MSVC and fully embrace LLVM.
            While we could do this in our own fork, we believe that integrating our compiler and community with the LLVM community will allow us to expand both communities, and to deliver a better compiler for our users.
            That would be my guess. I assume that anytime I see statements similar to: "While we could do this in our own fork".

            I have to imagine that there's a lot of effort involved when maintaining a fork of something as complex as LLVM and, in the long term, that it's easier adapting your niche to XYZ than it is to fork XYZ and adapt that fork to your niche; that eventually your XYZ fork becomes XWV because you're now so backwards from upstream. There's a reason why open source is winning in the long run and that's basically why.

            Comment


            • #7
              Originally posted by skeevy420 View Post
              There's a reason why open source is winning in the long run and that's basically why.
              Strongly agree. Independent companies, no matter how big they are just can't keep up.

              It would be nice to weaponize this fact a little more. For example:

              "No Microsoft, you will have to maintain your HLSL stuff out of tree because you consistently demonstrate that you are a bunch o' nobs"

              Same with Intel and their potential "pay as you go" hardware activation. Sure this has existed in various forms for a while but the open-source community should be making it as hard as possible for them rather than giving them the convenience of it residing in the upstream kernel tree.
              Last edited by kpedersen; 09 March 2022, 12:42 PM.

              Comment


              • #8
                Originally posted by skeevy420 View Post



                That would be my guess. I assume that anytime I see statements similar to: "While we could do this in our own fork".

                I have to imagine that there's a lot of effort involved when maintaining a fork of something as complex as LLVM and, in the long term, that it's easier adapting your niche to XYZ than it is to fork XYZ and adapt that fork to your niche; that eventually your XYZ fork becomes XWV because you're now so backwards from upstream. There's a reason why open source is winning in the long run and that's basically why.
                maybe this would be an option for AOCC don't know why they don't change the march=znverXY branches to their AMD likes.

                Comment


                • #9
                  This is kinda neat.

                  Comment


                  • #10
                    Originally posted by Phoronix
                    Microsoft... ...contribute... ...Vulkan graphics support...
                    *checks*

                    No, not April yet.

                    Comment

                    Working...
                    X