Announcement

Collapse
No announcement yet.

Wine 4.6 Released With Initial Bits Towards Vulkan WineD3D Backend

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

  • Wine 4.6 Released With Initial Bits Towards Vulkan WineD3D Backend

    Phoronix: Wine 4.6 Released With Initial Bits Towards Vulkan WineD3D Backend

    Wine 4.6 is now available as the latest bi-weekly development release and is actually quite exciting on the feature front with the developers -- especially those at CodeWeavers -- being quite active this spring...

    http://www.phoronix.com/scan.php?pag...e-4.6-Released

  • #2
    This wine version add new build dependency mingw cross compiler, have more work in mfplat - quartz and others

    Resident Evil 6 + Mods

    Last test with Pentium G3258 @ 4.1ghz + Artic Cooling Alpine 11 Plus



    With Core i3 8350K Tri-Core @ 5.0ghz + Zalman CNPS 10x Performa+



    Comment


    • #3
      So are they still going to work on using dxvk (or at least parts of it) for their WineD3D to Vulkan layer?
      Or are they going to write it from scratch without even looking at dxvk?

      Comment


      • #4
        What a waste of human resources! Sometimes people just can't avoid political and ideological reasons and get pragmatic.

        Comment


        • #5
          Originally posted by simburde View Post
          What a waste of human resources! Sometimes people just can't avoid political and ideological reasons and get pragmatic.
          It's the same with the US and Canada. Why the need for two governments?! What a waste of human resources!

          Comment


          • #6
            Originally posted by sdack View Post
            It's the same with the US and Canada. Why the need for two governments?! What a waste of human resources!
            Exactly! Why do we need a whole different government for our 51st state? That's just wasteful.

            Comment


            • #7
              Yeah, why would Wine consider to use a fast and stable project like DXVK and soon D9VK, when they can start something from scratch again ;-)

              Comment


              • #8
                Originally posted by R41N3R View Post
                Yeah, why would Wine consider to use a fast and stable project like DXVK and soon D9VK, when they can start something from scratch again ;-)
                Only in your dreams. DXVK dropped their latest release, because it crashes too many drivers. That's no stable at all. It's then never been stable, but only reasonably stable for some titles. Everyone who had a difference experience continues to hold their breath and utters only praise in hope it doesn't upset the author and so that their favorite game still finds support soon.

                And while it's faster than OpenGL - only thanks to Vulkan of course - is it also no where near the speed of Windows itself. It remains a slow solution and the choice of using OpenGL or Vulkan remains about as pathetic as two homeless guys who are fighting over a banana. Even when you there get a title to run solid at 60 fps+vsync with DXVK does it still produce microstutter and just doesn't feel as smooth as Windows.

                My only hope is that competition will change things up. I'm definitely happy to see others implementing DX11 on Vulkan support into WINE. It means it will become an integral part of it and receive fixes and support for many years to come. I sure don't see that happening with DXVK. The author wasn't interested in contributing to the WINE code base in the first place, nor is he interested in a cooperation now, so why will he care in the future about his own project? Only in your dreams.

                Comment


                • #9
                  Originally posted by MastaG View Post
                  So are they still going to work on using dxvk (or at least parts of it) for their WineD3D to Vulkan layer?
                  Or are they going to write it from scratch without even looking at dxvk?
                  Originally posted by R41N3R View Post
                  Yeah, why would Wine consider to use a fast and stable project like DXVK and soon D9VK, when they can start something from scratch again ;-)
                  Both of you the story is more complex.

                  https://mesamatrix.net/
                  spirv is the shader language of Vulkan. Do notice GL_ARB_gl_spirv in Opengl 4.6 here. So sections of Vulkan support have to be implemented in the Opengl Wined3d anyhow to take full advantage of Opengl 4.6.

                  Dxvk is design purely for a Vulkan back end. There can be differences between opengl spirv and vulkan spirv as well so there need to be a Wined3d form that will be slightly different to Dxvk in places.

                  Yes this is kind of the question why maintain independent Opengl and Vulkan direct x implementations particularly when the opengl one has to contain Vulkan parts anyhow for the most recent version of opengl.

                  It was predictable that at some point wined3d would grow Vulkan support as the requirements of Opengl was going to push Wined3d that way.

                  Extending wined3d is not starting from scratch either. The developer adding Vulkan support to Wined3d was tied up working vkd3d the DX12 implementation. Only reason Vulkan support in Wined3d did not start sooner is lack of wine project resources.

                  Think about it we want systems that are stuck with opengl for some reason to perform the best possible as well. DXVK/D9VK is not the end of the story they have been good prototypes to show the Vulkan form can perform well and be good for vulkan wined3d to run against.

                  Comment


                  • #10
                    Regarding mictostuttering - I don't get why Valve still not using their shader cache distribution infrastructure. I get that it's preparation for something bigger than us (probably something like second wave of SteamOS-based console, this time with Proton) but they could at least let people upload shader caches for stable Mesa releases, upload and re-distribute shaders among Proton users automatically or something like that. It's such a waste that every Proton user get microstuttering while shaders is compiled in background, instead of downloading pre-compiled shader cache.

                    Comment

                    Working...
                    X