Announcement

Collapse
No announcement yet.

RADV Enables Zero vRAM Option For All Games With VKD3D

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

  • RADV Enables Zero vRAM Option For All Games With VKD3D

    Phoronix: RADV Enables Zero vRAM Option For All Games With VKD3D

    Mesa's Radeon "RADV" Vulkan driver is now enabling the "zero vRAM" option for all VKD3D games -- Direct3D 12 titles running on Steam Play / Wine with this D3D12 to Vulkan layer -- in order to workaround various rendering bugs...

    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
    Citing myself from elsewhere:
    Originally posted by aufkrawall View Post
    Can anybody qualified please shed light on whether D3D12 -> Vulkan mapping can happen without any additional shader compile stutter?

    Comment


    • #3
      AFAIK Doom Eternal uses a Vulkan renderer, not DX12.

      Comment


      • #4
        Originally posted by spykes View Post
        AFAIK Doom Eternal uses a Vulkan renderer, not DX12.
        Looking at the patch, it does not add it for Doom Eternal as that was already there. I think that's miswording in the article.

        Comment


        • #5
          Originally posted by aufkrawall View Post
          Can D3D12 -> Vulkan mapping can happen without any additional shader compile stutter
          Not an expert, but it depends. Even pure Vulkan can stutter because you can generate shaders at runtime as needed, and though the source code of the shader is precompiled, there's a lot more stuff you have to do at runtime for a shader to be ready to use by the app (that's why Vulkan has the concept of a shader cache). Also, Vulkan might depend on certain extensions to be on feature parity with a certain version of D3D12. It can also depend on the quality of the translation layer between Vulkan and D3D12. So there's many variables involved.

          Comment


          • #6
            Originally posted by atomsymbol
            The default value for clearing the depth-buffer is 1.0 instead of zero - at least in OpenGL (mesa issue 2937), I am not sure about Vulkan or DX12. Zeroing allocated memory might not resolve depth-buffer-related issues (if such issues happen to exist in VKD3D).
            The thing is a little bit tricky if you're dealing with raw memory value. iirc z buffer commonly stores 1/z instead of the raw z value for performance and precision (https://developer.nvidia.com/content...ion-visualized). So clearing the buffer with zero would give you the right result (initial z = infinite or far plane).

            Comment


            • #7
              Originally posted by atomsymbol
              The default value for clearing the depth-buffer is 1.0 instead of zero - at least in OpenGL (mesa issue 2937), I am not sure about Vulkan or DX12. Zeroing allocated memory might not resolve depth-buffer-related issues (if such issues happen to exist in VKD3D).
              Well, this isn't workaround isn't for clearing, it's for the inital data in newly allocated vram. That vram is always zero allocated in D3D12 is implementation detail on windows but apparently game developers don't care. Now with that radv patch the behavior is exactly like on windows and the "broken" games run fine.

              Comment


              • #8
                So using uninitialized VRAM is allowed in graphics APIs? No wonder all games are trash.

                Comment


                • #9
                  Originally posted by angrypie View Post
                  So using uninitialized VRAM is allowed in graphics APIs? No wonder all games are trash.
                  Of course it's allowed. There's no reason at all for it not to be, and your comment is simply ignorant trash, to use your phrasing.

                  What IS surprising is that this is actually causing problems, with the buffer data not being overwritten reliably. But if devs CAN expect buffers to have been pre-cleared by D3D12, regardless of whether that's "an implementation detail" rather than part of the spec or not (because if the nvidia driver does it, AMD and Intel have no choice but to follow along, or users will blame their drivers rather than the game devs) then yeah - stupid and unnecessary though this hack fundamentally is, it's needed, and thus it's good to have from an end-user perspective despite that.

                  I think the more interesting aspect to consider here though is the potential for optimisation by clearing chunks of vram with idle shaders so that the next frame's allocations can be satisfied by regions that are alredy zeroed out. Given the density of modern shaders I doubt it would be a significant speedup, but it would very likely be a measurable one.
                  Last edited by arQon; 03 June 2020, 08:16 PM.

                  Comment


                  • #10
                    arQon maybe you should remove whatever is stuck up your ass, it's not doing you any good.

                    Comment

                    Working...
                    X