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

  • #11
    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


    • #12
      Originally posted by RussianNeuroMancer View Post
      It's such a waste that every Proton user get microstuttering while shaders is compiled in background, instead of downloading pre-compiled shader cache.
      Is microstutter really an issue with shader compile? I thought shader compilation caused more issues with hitching and multiple frame drops at level/scene load time. Whereas microstutter was more a driver/display stack issue where frame present, buffer swaps, scanout/vsync, and animation time in the game engine start overshooting and/or undershooting. I'm seriously asking, I'd like to know more. My understanding of the display stack issues is based on things like Keith Packard's recent presentations on fixing up X and DRM drivers for VR.

      Comment


      • #13
        Does anyone else find it hard to mentally keep track of which Vulkan to DirectX translation project supports which DirectX version? The names are not intuitive at all.

        I'd be able to remember the projects properly if they named them something like:

        DX9VK-<original-author/origin>
        DX11VK-<original-author/origin>
        DX12VK-<original-author/origin>

        If one project supported multiple DirectX versions, those simple names above would still work. You could read the name as referencing a primary DirectX target version and the project description could state the details of all the major & minor DirectX versions it supports.

        At least they are doing better than Microsoft with product naming:

        XBox
        XBox 360
        XBox One

        Comment


        • #14
          Originally posted by cybertraveler View Post
          Does anyone else find it hard to mentally keep track of which Vulkan to DirectX translation project supports which DirectX version? The names are not intuitive at all.

          I'd be able to remember the projects properly if they named them something like:

          DX9VK-<original-author/origin>
          DX11VK-<original-author/origin>
          DX12VK-<original-author/origin>

          If one project supported multiple DirectX versions, those simple names above would still work. You could read the name as referencing a primary DirectX target version and the project description could state the details of all the major & minor DirectX versions it supports.

          At least they are doing better than Microsoft with product naming:
          Number 1 you have to watch out for trademark violation. DX9, DX10, DX11, DX12 are all trademarked by Microsoft.

          wined3d will grow a Vulkan part. This will be to cover from Dx1 to Dx11.

          Dx10-11 by Microsoft these days are referenced as 1 spec. DX8-9 are also under the hood one spec yet we see VK9 and galluim9 not doing the Dx8. Dx1-7 is also 1 spec.

          So there are 4 specifications of Direct x.
          Dx1-7
          Dx8-9
          Dx10-11
          Dx12

          This gets more complex when you look at specification to specification interconnection.

          Items allocated in Dx1-7 should be render by dx8-9 calls and reverse at times.
          Items allocated in dx9 should be renderable by Dx10-11 and reverse at times.

          There is only 1 vulkan dx12 implementation that is the vkd3d out of the wine project. Dx12 is one and only time in direct x history you have a specification that does not mandate interaction with the other specifications.

          DX9VK, Dx11VK really cannot live in isolation to each other implementing in isolation is a mistake. dxvk has dx10/11 and needs to grow dx9 support this will support vista and never applications.

          There were a lot of attempt to implement dx on opengl as well. Do note that wined3d is the last standing of those. This is because wined3d targeted all versions.

          Comment


          • #15
            Originally posted by RussianNeuroMancer View Post
            Regarding mictostuttering - I don't get why Valve still not using their shader cache distribution infrastructure (…) 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.
            No, they couldn't - re-distributing cache from users is a security issue and wouldn't work well anyway, because cache needs to be recreated for every vendor and driver version separately.

            To fix this, Valve is working on Fossilize - serialization library for Vulkan objects. Once it'll work, cache will be stored in verified, serialized form on Valve servers and then distributed to all users and de-serialized on their computers.

            So they are working on it, just instead of quick-and-dirty hack they decided to work on proper solution. Viva la Valve!

            Comment


            • #16
              Originally posted by nranger View Post
              Is microstutter really an issue with shader compile? I thought shader compilation caused more issues with hitching and multiple frame drops at level/scene load time.
              Unfortunately some engines load shader ingame, when it used for a first time. To get idea google info about running Overwatch in WINE.

              Comment


              • #17
                Originally posted by oiaohm View Post

                ...

                Interesting info. Thanks.

                Comment


                • #18
                  Calling a project DX[version]VK is also bad for the reason that the best naming convention is mother>daughter. Direct X being implemented on top of Vulkan the best names are VKD3D[version].

                  Comment


                  • #19
                    Originally posted by rmfx View Post
                    Calling a project DX[version]VK is also bad for the reason that the best naming convention is mother>daughter. Direct X being implemented on top of Vulkan the best names are VKD3D[version].
                    Vkd3d was taken by wine project for Dx 12 and newer. Kind of makes sense from the wine point of view Dx12 by it design cannot be implemented on top of opengl at all. wined3d covers all the Dx versions than can be implemented on opengl and vulkan. So to the wine project developers this makes sense.

                    dxvk currently covers dx10/11 in near future it could cover dx9 of course it could expand from dx9 to dx8 as well. Any long term dx on top of vulkan that is going to last is going to expand in support dx values if implementation only support 1 dx version they have made a mistake.

                    Comment


                    • #20
                      Originally posted by sdack View Post
                      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.
                      I don't think that they will implemented DX11 to Vulkan from scratch, they will just integrate DXVK to Wine.

                      DXVK is still in development, and if you have problem with it, it will be better to report it in DXVK's GitHub.

                      The micro-stutter can be overcome with using Esync, Feral gamemode, Proton FS hack, and disabling compositions during gaming. You will not get the same performance as Windows, but it will be a little close.
                      Last edited by torbido; 04-13-2019, 08:08 PM.

                      Comment

                      Working...
                      X