Announcement

Collapse
No announcement yet.

AMDVLK 2021.Q2.2 Brings Minor Improvements But No Vulkan Ray-Tracing Yet

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

  • #11
    Originally posted by obri View Post
    I do not understand, why
    AMD needs a closed AND and an open source driver.

    That sounds to me like a lot of work has to be done twice.
    But why?
    1. It probably shares code with windows DRM related stuff. that and/or licensed code.
    2. People still believe in the myth in security by obfuscation. Closed source is a method of obtaining it.
    3. Amd closed source has some really great preformance stuff in it, that I doubt AMD would want competitors to use
    4. People also still believe that something being closed source means support will be better, its a common misconception. or rather FOSS community as a whole has contributed to this. and while not always true, it certainly is for somethings.

    These are the reasons off the top o my head anyways

    Comment


    • #12
      Originally posted by obri View Post
      I do not understand, why
      AMD needs a closed AND and an open source driver.

      That sounds to me like a lot of work has to be done twice.
      But why?
      It's not two separate drivers - the AMDVLK code is extracted from the closed source driver code base other than the shader compiler.

      The closed source driver uses the same shader compiler as the rest of the Windows graphics stack while the AMDVLK driver uses an llvm-based compiler similar to what we use in the open source OpenGL driver and the open source ROCm stack compilers.
      Test signature

      Comment


      • #13
        Originally posted by obri View Post
        I do not understand, why
        AMD needs a closed AND and an open source driver.

        That sounds to me like a lot of work has to be done twice.
        But why?
        They do it just to give those open source only people another thing to complain and moan about. They need no other reason lol. Their annoying complaining will never end as closed source isn't going away.

        Comment


        • #14
          Originally posted by aufkrawall View Post
          The compile times of the amdvlk-open compiler are definitely really, really bad. I haven't tested with Navi, but with Polaris it was several times worse than upstream LLVM. When a game has lots of shaders, it can take over an hour to compile them all at once (which most Vulkan and D3D12 games do) with a slow CPU & amdvlk-open. With ACO, it would be a matter of a few minutes.
          For some unknown reason for me, as a layman, DirectX 12 (and you say also Vulkan) games compile so much shaders at each start. DirectX 11 games don't need that. Probably something about working with the GPU low level (low level APIs). And I'm talking about running games in Windows, not Linux. In my case Borderlands 3 takes like minutes on my old CPU to compile them. Also because of a bug in AMD GPU drivers for this game in DX12 (introduced after just one day of playing the game around this Christmass), I switched to DX11, so no waiting at starting the game for me :-) (I don't want to Google how to set permanently Windows 10 to a previous version of the drivers).

          Comment


          • #15
            Originally posted by Ladis View Post

            For some unknown reason for me, as a layman, DirectX 12 (and you say also Vulkan) games compile so much shaders at each start. DirectX 11 games don't need that. Probably something about working with the GPU low level (low level APIs). And I'm talking about running games in Windows, not Linux. In my case Borderlands 3 takes like minutes on my old CPU to compile them. Also because of a bug in AMD GPU drivers for this game in DX12 (introduced after just one day of playing the game around this Christmass), I switched to DX11, so no waiting at starting the game for me :-) (I don't want to Google how to set permanently Windows 10 to a previous version of the drivers).
            Compiling shaders ahead of time reduces load during gameplay, enabling better performance. It's one of the big draws of OpenGL 4.6 - less verbose coding than vulkan, (all else being equal) better performance than OpenGL 4.5.

            Comment

            Working...
            X