Announcement

Collapse
No announcement yet.

It Looks Like AMD Is About To Post The Open-Source Radeon "Navi" Driver Code

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

  • #11
    Originally posted by skeevy420 View Post
    Because that "hybrid driver" is AMDGPU-Pro and contains proprietary components and DKMS doesn't help when we don't have all of the source code to actually build it.
    There is nothing closed on the kernel driver side. The packaged drivers use the same dkms kernel packages regardless of whether you use the closed or open source user mode components. The dkms packages include the full source code, but we also post the entire tree if you want the history, etc. E.g., for 18.50:

    Comment


    • #12
      I found this: https://cgit.freedesktop.org/~agd5f/...ms?h=amd-18.50

      Comment


      • #13
        I hope they make another consumer GPU with 16GiB of HBM, been using a Radeon VII for the last week or so and it is fantastic for my memory-intensive applications. I can afford to move ~5GiB of data per frame on the 165Hz display, and not miss any frames.

        Comment


        • #14
          I will be happy when AMD releases opensource graphical interface for Mesa.

          Comment


          • #15
            SR-IOV Please!! I don't care if I have to pay MUCH more for that feature, but please put it on a gaming GPU for a change.

            Comment


            • #16
              Originally posted by agd5f View Post

              There is nothing closed on the kernel driver side. The packaged drivers use the same dkms kernel packages regardless of whether you use the closed or open source user mode components. The dkms packages include the full source code, but we also post the entire tree if you want the history, etc. E.g., for 18.50:
              I was referring to the shader compiler, etc...the parts of the Pro driver that are closed (AFAIK) in regards to building the entire package suite, not just the kernel. I suppose I could have made that a bit more clear -- Even with all the -Pro kernel parts being open and buildable via DKMS, that only gets us so far in regards to building the entire Pro stack.

              It it nice to know that all of the kernel components are open source. I've always been unsure on that part.

              Thanks for clarifying that for myself and probably others...and for even bothering to come here and respond to users such as myself. For me, little things like that mean a lot and it really helps with brand loyalty when you can make a random comment and get a response straight from the horse's mouth.

              Comment


              • #17
                Originally posted by shmerl View Post

                Thanks! Are there some instructions how to build and use the dkms module though?
                If you install the dkms kernel driver package, it builds the kernel driver modules at install time using dkms against the current kernel in the distro. The package (rpm, deb) has everything you need. Note that we only validate the dkms build against the kernels in supported distros. For other random kernels, YMMV.

                Comment


                • #18
                  Originally posted by skeevy420 View Post

                  I was referring to the shader compiler, etc...the parts of the Pro driver that are closed (AFAIK) in regards to building the entire package suite, not just the kernel. I suppose I could have made that a bit more clear -- Even with all the -Pro kernel parts being open and buildable via DKMS, that only gets us so far in regards to building the entire Pro stack.
                  I said nothing about pro being open. My whole point was to answer Michael's idea that until upstream kernel catches up, there might be a need to use the hybird driver. Since dkms module is open, there is no need to. You can have that dkms with older kernel, and use Mesa on top. So still open stack.

                  Comment


                  • #19
                    Originally posted by torbido View Post
                    I will be happy when AMD releases opensource graphical interface for Mesa.
                    This first comment won't help much, but between Lutris and adriconf most things have a graphical interface.

                    AFAIK, we don't have GUIs anywhere for AMD/R600_DEBUG, the MSAA>EQAA override, the anisotropic filter override, or to use the AMDVLK extensions in development. IMHO, only the middle two need them since the Windows GUI offers similar functionality.

                    Between posting it in a KDE thread where I doubt it got much attention from AMD users and being slightly updated since, here's my list of AMDGPU and other gaming related environment variables. My apologies to those who know these for the wall of text.


                    Code:
                    ## Wine Variables
                    
                    # Wine Esync
                    export WINEESYNC=1
                    
                    # Wine PBA
                    export PBA_ENABLE=1
                    
                    # DXVK Async
                    export DXVK_ASYNC=1
                    
                    ## System Vulkan (only enable one)
                    # AMDVLK
                    #export VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/amd_icd64.json
                    
                    # AMDVLK-Pro (thanks, TK-Glitch)
                    #export VK_ICD_FILENAMES=/opt/amdgpu-pro/etc/vulkan/icd.d/amd_icd64.json
                    
                    # AMDVLK Experimental Features
                    #export AMDVLK_ENABLE_DEVELOPING_EXT="all"
                    
                    # RADV
                    export VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/radeon_icd.x86_64.json
                    
                    ## AMDGPU/MESA Tuning
                    # AMDGPU 16x anisotropic filtering
                    export R600_TEX_ANISO=16
                    
                    # AMD\R600 Debug options
                    # Mesa 19.1+
                    export AMD_DEBUG=sisched,nir,forcedma,unsafemath,llvm,gisel,dpbb,dfsm
                    # Mesa 19.0-
                    export R600_DEBUG=sisched,nir,forcedma,unsafemath,llvm,gisel,dpbb,dfsm
                    
                    # MSAA>EQAA Modes (all based on an AMD tech sheet; actual EQAA modes bug Dirt Rally :(; can be set global and per game)
                    # Requires game to use MSAA to convert it to EQAA.
                    #No MSAA
                    #export EQAA=0,0,0
                    
                    #2x MSAA
                    #export EQAA=2,2,2
                    
                    #2f4x EQAA
                    #export EQAA=4,2,2
                    
                    #4x MSAA
                    #export EQAA=4,4,4
                    
                    #2f8x EQAA
                    #export EQAA=8,2,2
                    
                    #4f8x EQAA
                    #export EQAA=8,4,4
                    
                    #4f16x EQAA
                    #export EQAA=16,4,4
                    
                    #8x MSAA
                    export EQAA=8,8,8
                    
                    #8f16x EQAA
                    #export EQAA=16,8,8
                    
                    ## MLAA (best to use only use one MLAA...color blurs the fonts of KDE when global...better to set as an env variable in Lutris)
                    # Jimenez MLAA
                    #export pp_jimenezmlaa=16
                    
                    # Jimenez MLAA Color
                    #export pp_jimenezmlaa_color=16
                    
                    ## Libstrangle Tuning (all below require libstrangle to be installed and programs to be launched with strangle name_of_program)
                    # Cap FPS for OpenGL/Vulkan programs to 60 FPS
                    export FPS=60
                    
                    # Force enable VSYNC (enabling it via xorg.conf is also recommended)
                    export VSYNC=1
                    
                    # Tweak Vuklan/OGL mipmap lod bias for crisper textures
                    export PICMIP=-1

                    Comment


                    • #20
                      Originally posted by shmerl View Post

                      I said nothing about pro being open. My whole point was to answer Michael's idea that until upstream kernel catches up, there might be a need to use the hybird driver. Since dkms module is open, there is no need to. You can have that dkms with older kernel, and use Mesa on top. So still open stack.
                      And I wasn't talking to you there

                      But it's all bit of a miscommunication in regards to the entire stack including the kernel and just the kernel on my part.

                      Comment

                      Working...
                      X