Announcement

Collapse
No announcement yet.

There Is Experimental Patches Providing Support For DXIL Shaders With VKD3D

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

  • There Is Experimental Patches Providing Support For DXIL Shaders With VKD3D

    Phoronix: There Is Experimental Patches Providing Support For DXIL Shaders With VKD3D

    The Wine project's VKD3D initiative for translating Direct3D 12 support to Vulkan took another step forward today with patches for handling DXIL (Shader Model 6.0+) shaders with VKD3D, but the work in the current form may need to be re-worked...

    http://www.phoronix.com/scan.php?pag...D-DXIL-Shaders

  • #2
    Shouldn't it be "There Are Experimental Patches"?

    Comment


    • #3
      Originally posted by tildearrow View Post
      Shouldn't it be "There Are Experimental Patches"?
      It's "There Be Experimental Patches".
      (but, yeah, it's "Are")

      Comment


      • #4
        Originally posted by skeevy420 View Post

        It's "There Be Experimental Patches".
        (but, yeah, it's "Are")
        There be experimental patches. Arrrr...

        /pirate

        Comment


        • #5
          Too bad LLVM is the single largest library on my system right now. I feel that using it is setting yourself up for long term failure. It really isn't a friendly ecosystem to be in.

          Comment


          • #6
            Originally posted by grigi View Post
            Too bad LLVM is the single largest library on my system right now. I feel that using it is setting yourself up for long term failure. It really isn't a friendly ecosystem to be in.
            It's really a collection of libraries

            Comment


            • #7
              Regardless, it gets updated and maintained as a single entity, and is downright massive. It feels much like the Boost issue of a decade ago. It was a benefit for everyone when packaging was made more granular.

              Comment


              • #8
                Originally posted by grigi View Post
                Regardless, it gets updated and maintained as a single entity, and is downright massive. It feels much like the Boost issue of a decade ago. It was a benefit for everyone when packaging was made more granular.
                * sys-devel/llvm-9.0.1: 45.1M
                * sys-devel/clang-9.0.1: 66.3M

                * sys-libs/glibc-2.30-r3: 19.1M
                * sys-devel/gcc-9.2.0-r3: 57.3M

                * dev-libs/boost-1.72.0-r1: 26.2M

                * media-libs/mesa-9999: 41.6M

                * x11-libs/gtk+-2.24.32-r1: 7.0M
                * x11-libs/gtk+-3.24.13: 13.7M

                * dev-qt/qtcore-5.14.1: 19.5M

                I mean it's big, but it's not massive and as soon as you start splitting it up more than it already is you start having to deal with intra-dependencies - I think that's why their main git tree has all the llvm subproject under one umbrella. It's much easier to do global updates and even bisect issues over the related components

                Comment


                • #9
                  Interesting your mesa is so big, mine is about 26M? (not git version, so that might explain it) But true, there are other large packages.

                  I just find using llvm as a transpiler engine from a dxil bytecode to spirv bytecode a bit funny as they are so similar.

                  Also,I have been badly burnt with llvm and their active sabotage of unladen-swallow. Recently the aliasing issues that hit rust (which spawned cranelift), and the frustration of random regressions that llvm refuse to fix (which spawned ACO) reminding me about the bad days.

                  Comment

                  Working...
                  X