Announcement

Collapse
No announcement yet.

Vulkan 1.1 Released As The First Major Update To This Graphics/Compute API

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

  • #11
    Originally posted by ElectricPrism View Post

    Idk if I can take you seriously when you spell Vulkan wrong.
    More to the point, his complaint seems to be currently getting attention already: https://github.com/swaywm/wlroots/issues/642

    Comment


    • #12
      Originally posted by Karbowiak View Post
      This is probably a dumb question, but what with Vulkan 1.1 supporting HLSL in some form - wouldn't this make the work for the guy writing DXVK easier?
      Vulkan doesn't support HLSL or any shading language directly, they have SPIRV which you can think of as LLVM IR in clang, with GLSL/HLSL being front-end (C, C++, C# and whatever else). Basically you use third party / Khronos endorsed compilers that translate HLSL to SPIRV.

      The problem with porting between GL and DX9 is that they are very different beasts and architecturally different, bunch of GL driver is implemented in userspace whereas DX drivers run in kernel mode (which has been historically seen as downside of DX, because kernel context switches are costly).
      MS did improve on this with DX10 (or 11, don't recall), allowing parts of "certified" DX drivers to run in userspace. But without straying too off-topic, DX9 models graphics concepts, whereas Vulkan/DX12 models graphics hardware concepts. Hence why it's easier to port DX12 <> Vulkan and why it's difficult to port GL <> DX9.
      It's not terribly hard to do machine translation, but doing so efficiently is much easier when underlying models are same.

      Back to your original question, unless you really don't care about backwards compatibility, any change (even for better) just means more work.

      Comment


      • #13
        So, instead of amalgamating Vulkan and OpenCL they've put DRM right into APIā€¦ what a time to be alive ! As if HDCP abomination wasn't enough. What next, hardware remote backdoors in GPU chips ?

        Comment


        • #14
          Originally posted by tpruzina View Post
          unless you really don't care about backwards compatibility
          all vulkan drivers support 1.1, so compatibility with what?

          Comment


          • #15
            Originally posted by pal666 View Post
            all vulkan drivers support 1.1, so compatibility with what?
            Games support 1.0.XX though, it's not like newly released games will start supporting newer point releases by default. Whatever version they were build against is the version you need to support. I'm not aware of anything breaking so far (except for little stuff from early 1.0). Game developers typically freeze with whatever they started with. Anyways, I was replying to his comment about new stuff making it "easier" to do translation layer, whereas new stuff == more work.

            Comment


            • #16
              Originally posted by tpruzina View Post
              Games support 1.0.XX though
              you replied to question about directx games, and they don't support any vulkan
              Originally posted by tpruzina View Post
              new stuff == more work.
              not necessarily. if new stuff will do work for you, it is less work

              Comment


              • #17
                Originally posted by oiaohm View Post

                Maybe yes maybe no. If DXVK wants to keep Vulkan 1.0 support might mean needing two shader compliers to get best performance.



                Above is interesting right. HLSL to SPIR-V is being included in Microsoft compiler its DXIL ot SPIR-V and back that is interesting problem as well.
                Dilithium is a bidirectional shader converter for converting between DXIL and SPIR-V. - gongminmin/Dilithium

                Above is interesting.

                This repo hosts the source for the DirectX Shader Compiler which is based on LLVM/Clang. - microsoft/DirectXShaderCompiler


                Targeting DX11 means you have to support dxbc2dxil.dll that beast allows DX11 program to use shaders for older versions of DX back to dx9. So there is room for a joint project working on shaders.

                Targeting DX12 is where you get to drop legacy.

                Also these extra SPIR-V features for simpler DX shader conversion will this come to opengl SPIR-V as well.

                Its been interesting that DXIL is open specification and the old dxbc is closed specification. Yes dxbc support is quite a big pain in tail.
                Vulkan1.1 HLSL is HLSL source to SPIRV and it's made for game developers only. Once the game is out for sale it distributes to DXBC, the cartel will never give you DXBC to SPIRV. If they do, it's like they give you a D3D11 state tracker for Vulkan. The 90% of DXVK is DXBC to SPIRV.

                Comment


                • #18
                  Originally posted by dfx. View Post
                  So, instead of amalgamating Vulkan and OpenCL they've put DRM right into APIā€¦ what a time to be alive !
                  You're looking at it wrong. You seem to think the choice is between the content being copy-protected vs. not.

                  But, if someone is insistent on copy protection, then the choice is rather one of enabling an extensible Vulkan backend or having a closed, proprietary path. At least making it open and extensible lets media players (and video processing plugins, I think) do some interesting things with the content.

                  The way I see it, the DRM battle was lost, long ago. It's here to stay. The best we can hope for is to minimize the downsides - and one significant downside was the inability to have open and extensible post-processing (e.g. sophisticated deinterlacing, motion interpolation, noise reduction, film grain & scratch removal, blur reduction, super-resolution, black level correction, de-banding, etc.). I'm no fan of DRM, but I'm happy for it to get in the way a bit less.

                  Comment


                  • #19
                    Typo:
                    he also reassured us that OpenCL will continue to move forward in its own trajector while there will obviously be some overlap, nothing is happening to that API anytime soon.

                    Comment

                    Working...
                    X