Announcement

Collapse
No announcement yet.

Work-In-Progress RadeonSI+Nine Showing Big Performance Win For Source Engine Games

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

  • #21
    last time I check a lot of bugs in games, render issues they are better? performance is useless if the things don t work like it should

    Comment


    • #22
      Originally posted by doomie View Post

      can confirm, when i still used windows i lamented that i actually lost functionality and performance with some AMD upgrades. the windows situation is great if you like to only play the latest games with fancy new features, but often sucks if you actually enjoy classics. linux+wine tends to be less hassle (ty codeweavers and valve)
      this things are usual with amd

      Comment


      • #23
        Originally posted by kiffmet View Post

        There is no DX9 title that doesn't run with at least 120-140fps on AMD Navi. IMO that's good enough and expecting to get the maximum theoretically achievable performance in deprecated legacy APIs is a false expectation.
        There's plenty of them which require lowering settings. And 170hz is the new 144hz.

        Comment


        • #24
          Originally posted by Aryma View Post
          any plan for dx11 to Gallium or dx12 to Gallium

          Yes... kind of, VMware has already released their d3d10umd state tracker, and plan to release d3d11umd state tracker, though to my knowledge wine does not support umd ddi yet, and has no plans to so it would be strictly for virtual machines.

          DX12 wouldn't really make sense. but I suppose it could be possible. no plans for it that I know of.

          Comment


          • #25
            Originally posted by Aryma View Post

            why I think native dx12 better than Vkd3d or dxvk
            it would be, just not using gallium, or at least not likely using gallium

            Originally posted by rmfx View Post
            So Dx9 over Native GL beats Dx9 over Native Vulkan now ?
            this isnt over native GL, gallium is often mistaken as an opengl implementation but it isn't gallium nine for all intents and purposes is a native driver, there is no conversion to opengl

            Comment


            • #26
              Have I understood this correctly that instead of binary > d3d9 > togl > radeonsi > gallium > hardware it's now binary > d3d9 > nine > gallium > hardware?

              Comment


              • #27
                Originally posted by ResponseWriter View Post
                Have I understood this correctly that instead of binary > d3d9 > togl > radeonsi > gallium > hardware it's now binary > d3d9 > nine > gallium > hardware?
                Almost. I'll write APIs in parens for clarity.

                Before: game → (D3D9) → togl → (OpenGL) →Mesa Gallium OpenGL frontend → (Gallium) → Gallium driver → hardware

                After: game → (D3D9) → Mesa Gallium Nine frontend → (Gallium) → Gallium driver → hardware

                An alternative reported on previously is via Vulkan: game → (D3D9) → DXVK → (Vulkan) → Vulkan driver → hardware

                Comment


                • #28
                  Originally posted by Quackdoc View Post
                  Yes... kind of, VMware has already released their d3d10umd state tracker, and plan to release d3d11umd state tracker, though to my knowledge wine does not support umd ddi yet, and has no plans to so it would be strictly for virtual machines.

                  DX12 wouldn't really make sense. but I suppose it could be possible. no plans for it that I know of.
                  VMWare will need to support windows with own software rendering will need at least 5 UMD


                  Required: D3D9 - UMD DDI
                  Required: D3D10- UMD DDI
                  Required: D3D10.1- UMD DDI
                  Required: D3D11 - UMD DDI
                  Required: D3D11.1 - UMD DDI
                  Interesting point is D3D10,D3D10.1,D3D11 and D3D11.1 UMD drivers can be all build from one source tree using different ifdef to enable and disable features as amd, intel and nvidia do this to make these 4 UMD drivers with their graphics cards so we should expect VMware todo the same here.

                  At this stage there is no quirks that cause applications to fail in the Microsoft software version of DX12/13 but there are quirks in Microsoft software rendering for dx9-dx11.1 that cause applications to fail. Yes people use wined3d(dx from wine) on windows to have some of those programs work on windows when in a virtual machine because microsoft software rendering is broke.

                  I would agree at the curent time DX12/13 in software rendering does not mandate VMWare makes their own. Of course in time this could change like if Windows 11 adds a quirk to DX12/3 software rendering support.

                  Thing to remember VMWare does still need software rendering for instances running without GPU. Missing D3D11.1 with windows 8 and 10 does result in desktop artefacts when you use the Microsoft software rendering for D3D11.1 and if you don't particular desktop appearance things disappear. Windows 11 might change the windows desktop requirement to render correctly to DX13 something and microsoft may not be checking this properly with their own software rendering as well(yes this would force VMware hand to work on own software rendering for DX12/13).

                  VMware need for DX software rendering is directly linked to how stuffed Microsoft own made DX software rendering is particularly when it a case its effecting desktop rendering adversely.

                  Comment


                  • #29
                    Originally posted by oiaohm View Post

                    VMWare will need to support windows with own software rendering will need at least 5 UMD

                    https://docs.microsoft.com/en-us/win...e-requirements


                    Interesting point is D3D10,D3D10.1,D3D11 and D3D11.1 UMD drivers can be all build from one source tree using different ifdef to enable and disable features as amd, intel and nvidia do this to make these 4 UMD drivers with their graphics cards so we should expect VMware todo the same here.

                    At this stage there is no quirks that cause applications to fail in the Microsoft software version of DX12/13 but there are quirks in Microsoft software rendering for dx9-dx11.1 that cause applications to fail. Yes people use wined3d(dx from wine) on windows to have some of those programs work on windows when in a virtual machine because microsoft software rendering is broke.

                    I would agree at the curent time DX12/13 in software rendering does not mandate VMWare makes their own. Of course in time this could change like if Windows 11 adds a quirk to DX12/3 software rendering support.

                    Thing to remember VMWare does still need software rendering for instances running without GPU. Missing D3D11.1 with windows 8 and 10 does result in desktop artefacts when you use the Microsoft software rendering for D3D11.1 and if you don't particular desktop appearance things disappear. Windows 11 might change the windows desktop requirement to render correctly to DX13 something and microsoft may not be checking this properly with their own software rendering as well(yes this would force VMware hand to work on own software rendering for DX12/13).

                    VMware need for DX software rendering is directly linked to how stuffed Microsoft own made DX software rendering is particularly when it a case its effecting desktop rendering adversely.
                    In the end it is still annoying that vmware would need to support legacy d3d9-11 in the first place when they migrate to d3d12, especially d3d11 considering windows has their own d3d11umd to d3d12 that is baked into windows. though I could see a similar wrapper being made for d3d9umd. I would obviously like to see microsoft officially support this, so drivers can finally leave at least d3d10 and d3d9 in the dust. that way each driver developer, regardless of virtual or physical can focus on d3d12 and vulkan, as soon d3d11 will be EOL (mind you I still think it will last longer than d3d10 did.).

                    and as far as gpu accelerated vgpu, I assume vmware is using API passthrough, which could in large part be why dx11 requires an nvidia gpu on linux host, I wouldn't be surprised, if the nvidia proprietary driver has the dx11 bits still in it that vmware can make use of.

                    edit Here is URL for d3d11umd to d3d12
                    The Direct3D11-On-12 mapping layer. Contribute to microsoft/D3D11On12 development by creating an account on GitHub.

                    Comment


                    • #30
                      Originally posted by Quackdoc View Post

                      In the end it is still annoying that vmware would need to support legacy d3d9-11 in the first place when they migrate to d3d12, especially d3d11 considering windows has their own d3d11umd to d3d12 that is baked into windows. though I could see a similar wrapper being made for d3d9umd. I would obviously like to see microsoft officially support this, so drivers can finally leave at least d3d10 and d3d9 in the dust. that way each driver developer, regardless of virtual or physical can focus on d3d12 and vulkan, as soon d3d11 will be EOL (mind you I still think it will last longer than d3d10 did.).

                      edit Here is URL for d3d11umd to d3d12
                      https://github.com/microsoft/D3D11On12
                      Fun point that implementation is not DX 11.1 UMD its only DX 11 UMD to make virtual machine running windows 8 work properly you need DX 11.1 UMD. I have been giving the windows 8 list for a reason. This is a problem you run into with Microsoft implementations of software and wrappers you run into half done implementations. they could have done all of DX11 UMB but no they did only half of the DX11 UMDs in that github project. Yes a DX11 program is allowed to use DX10 and DX9 parts in different places so you really need all of them.

                      Life would be a lot better all around if Microsoft was not doing this stuff half way.

                      Comment

                      Working...
                      X