Announcement

Collapse
No announcement yet.

Microsoft Lands HEVC Video Encode/Decode Within Mesa Using VA-API To Direct3D 12

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

  • Microsoft Lands HEVC Video Encode/Decode Within Mesa Using VA-API To Direct3D 12

    Phoronix: Microsoft Lands HEVC Video Encode/Decode Within Mesa Using VA-API To Direct3D 12

    In addition to Microsoft continuing to work on OpenGL / OpenCL / Vulkan atop Direct3D 12 by leveraging Mesa in order to benefit Windows Subsystem for Linux (WSL2) and related use-cases, Microsoft engineers have also been working on exposing video acceleration to Linux software backed by Direct3D 12 Video Acceleration...

    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
    I wonder what's motivating them to do this, when Vulkan presumably works in WSL for free.

    Comment


    • #3
      Originally posted by hamishmb View Post
      I wonder what's motivating them to do this, when Vulkan presumably works in WSL for free.
      Presumably, they want to keep their proprietary lock in technologies relevant. Vulkan is a threat to the stake they carved out in the gaming market. A vulkan enabled game engine is easier to port. If everything is built atop D3D in the Windows world, vulkan and cross platform support is a mere afterthought. Also, if D3D is the gateway to Windows graphics, anything using it will by their sheer market share be tested and optimized more for it. Cementing Microsoft's position.

      Microsoft has gotten far better at PR, but underneath it is still the same old leopard with its usual spots. They love Linux if it furthers their goals of staying the computing behemoth. They hate it if it makes them less relevant. That is why anything Linux within Microsoft, that is consumer facing, is atop Windows. They can sell Windows. Linux not so much, but it is a nice extra if it is locked away in a Microsoft controlled VM.​

      Comment


      • #4
        Originally posted by r_a_trip View Post

        Presumably, they want to keep their proprietary lock in technologies relevant. Vulkan is a threat to the stake they carved out in the gaming market. A vulkan enabled game engine is easier to port. If everything is built atop D3D in the Windows world, vulkan and cross platform support is a mere afterthought. Also, if D3D is the gateway to Windows graphics, anything using it will by their sheer market share be tested and optimized more for it. Cementing Microsoft's position.

        Microsoft has gotten far better at PR, but underneath it is still the same old leopard with its usual spots. They love Linux if it furthers their goals of staying the computing behemoth. They hate it if it makes them less relevant. That is why anything Linux within Microsoft, that is consumer facing, is atop Windows. They can sell Windows. Linux not so much, but it is a nice extra if it is locked away in a Microsoft controlled VM.​
        But aren't Microsoft selling GNU+Linux via their Azure cloud services?

        Comment


        • #5
          Originally posted by gnarlin View Post

          But aren't Microsoft selling GNU+Linux via their Azure cloud services?
          Good luck playing games on that!

          Comment


          • #6
            Originally posted by hamishmb View Post
            I wonder what's motivating them to do this, when Vulkan presumably works in WSL for free.
            D3D12 allows for driver level gpu paravirt allowing high preformance acceleration in VMs, though as far as I can tell it's more like api passthrough then paravirt. (think something like vulkan venus on qemu) however it being driver level means that there should be less overhead, ofc this means jack when you have the overhead of vk-> d3d12, libva ->d3d12 etc.

            however like I said, it is something microsoft supports on all semi modern D3D12 gpus. this allows potential native integration with their hyper-v and wsl technologies. and without relying in vulkan which does not have native integration in windows.

            EDIT: ofc I would prefer vulkan, but there are technical benefits to doing this instead of vulkan (especially when vulkan video is still young)

            Comment


            • #7
              I am fairly certain Vulkan is not supported on WSL2. OpenGL and DirectX yes, but there is no hardware Vulkan support. I have no idea about the Vulkan CPU driver, however.

              Comment


              • #8
                Originally posted by dragorth View Post
                I am fairly certain Vulkan is not supported on WSL2. OpenGL and DirectX yes, but there is no hardware Vulkan support. I have no idea about the Vulkan CPU driver, however.
                microsoft and collabora devs are working on dozen or "dzn" which is a vulkan -> d3d12 layer, the code is in mesa iirc, so wsl2 will probaly get vulkan support if you enable that.

                Comment


                • #9
                  My bad then. I wonder why Vulkan isn't supported if OpenGL is. I feel like making a translation layer is probably harder than just supporting Vulkan natively, but *shrug*
                  Last edited by hamishmb; 16 September 2022, 05:27 PM. Reason: Typo

                  Comment


                  • #10
                    Originally posted by hamishmb View Post
                    My bad then. I wonder why Vulkan isn't supported of OpenGL is. I feel like making a translation layer is probably harder than just supporting Vulkan natively, but *shrug*
                    opengl works the exact same way on wsl2. the issue is that vulkan isn't ready yet

                    it's just doing
                    OGL -> Gallium (this is what I think all mesa opengl drivers do btw don't think this ads significant overheads) -> D3D12
                    Vulkan -> D3D12

                    Comment

                    Working...
                    X