Announcement

Collapse
No announcement yet.

The RADV Driver Developer Experience Working With AMD's Next-Gen Geometry "NGG"

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

  • The RADV Driver Developer Experience Working With AMD's Next-Gen Geometry "NGG"

    Phoronix: The RADV Driver Developer Experience Working With AMD's Next-Gen Geometry "NGG"

    Mesa's Radeon Vulkan "RADV" driver contributor Timur Kristóf known for being one of the Valve contractors to improve the open-source Linux graphics stack has shared his experiences working on the Next-Gen Geometry (NGG) support for AMD RDNA GPUs with this open-source driver...

    https://www.phoronix.com/scan.php?pa...NGG-Experience

  • #2
    Maybe the engineers can talk to their marketing people to only hype up features that are a) meaningful and b) get implemented. I am still sour over Vega's NGG implementation and hype, Timur wrote about it that it wasn't even worth his time looking into it...

    Comment


    • #3
      When we switched to NGG, we still compiled our shaders the same way as before, so even though we used the new geometry pipeline, we didn’t do anything to take advantage of its new capabilities. The actual perf improvement came after I also implemented shader-based culling.
      I love that explanation. Gave me a genuine smile. That's like the smart person version of not thinking to tweak the resolution settings on the DVD player hooked up to a 4K TV.

      After upgrading to a 4K TV movies weren't any better. It wasn't until after the 2nd movie that I remembered to check "Menu>Settings>Resolution".

      Comment


      • #4
        Originally posted by ms178 View Post
        Maybe the engineers can talk to their marketing people to only hype up features that are a) meaningful and b) get implemented. I am still sour over Vega's NGG implementation and hype, Timur wrote about it that it wasn't even worth his time looking into it...
        Heh. That reminds me of my and Bridgman's old asterisk conversations where I was asking if the AMD folks would put a * next to things like the GUI and other things that Linux won't get or currently doesn't support. I mean, if you only researched as far as AMD's product page you'd think you'd be getting the same features on Windows and Linux and that is not the case at all.

        I'm still sour over that.

        To this day there is a big discrepancy between what the AMD page for my RX 580 says it supports and what it actually supports on Linux simply because it has everything all lumped in together like Linux has a GUI, Chill, Super Resolution, etc. I'm surprised that no one has Class Action-ed AMD over how misleading their product specification pages are.

        They way it is written up makes it appear that all the OSs support all the listed Features:


        Comment


        • #5
          Performance aside, does simplified hardware usage translate to any noticeable power savings? That would still be worthwhile for many applications, not the least of which would be steam deck.

          Comment


          • #6
            Originally posted by skeevy420 View Post
            To this day there is a big discrepancy between what the AMD page for my RX 580 says it supports and what it actually supports on Linux simply because it has everything all lumped in together like Linux has a GUI, Chill, Super Resolution, etc. I'm surprised that no one has Class Action-ed AMD over how misleading their product specification pages are.
            This is somewhat off-topic here but there are actually more than one GUI apps that you can use.

            Comment


            • #7
              Originally posted by Venemo View Post

              This is somewhat off-topic here but there are actually more than one GUI apps that you can use.
              I know. None of them are guaranteed to be maintained for long-term since they're not official or made/sponsored/etc by a distribution. It sucks getting used to something and then it never being updated again so I have to stroll on. That's literally the same reason I dislike using GNOME plugins.

              My personal hope, the wish in one hand, would be a generic Mesa GUI that all the manufacturers could target. Because the GUI problem is more than just wanting overclocking controls, it's needing to set things like fan controls, frame rate modes, scaling modes, application profile editing, individual company features (like a Vulkan driver picker for AMD), a quick way to see supported features and specs, performance and temperature monitoring, gaming features (like vkBasalt integration), and more. Most all of that is handled within the AMD or NVIDIA tools on Windows or the Reshade GUI. On Linux you have to set 32 variables on the command line, create custom text files to tweak effects, and run 4 or 5 different GUI programs to do the rest. A lot of those features aren't necessarily device exclusive and could be added to a common Mesa GUI. And before y'all say it -- If I could I would and if I had the money I'd sponsor it and if I knew of an internship opening at AMD that would pay me to learn how to make the GUI and then make it I'd apply for that.

              AMD is flush with cash. They could gamble $1M a year on some internships, their hardware, and their instructor(s).

              Anyhoo, that's all I have to say about that.

              Comment


              • #8
                Originally posted by skeevy420 View Post
                None of them are guaranteed to be maintained for long-term since they're not official or made/sponsored/etc by a distribution.
                Just my personal opinion but "official" and "made by a distribution" are not guarantees for long-term maintenance at all.

                Originally posted by skeevy420 View Post
                My personal hope, the wish in one hand, would be a generic Mesa GUI that all the manufacturers could target.
                Two thoughts about this.
                Firstly, most of the things you want from this GUI are not part of mesa and wouldn't fit into what mesa is.
                Second, what's the point of reinventing the wheel by making yet another GUI when several exist already? If I really wanted to have this, I'd sooner start to contribute to one of the pre-existing projects rather than starting my own from scratch.

                Originally posted by skeevy420 View Post
                Because the GUI problem is more than just wanting overclocking controls, it's needing to set things like fan controls, frame rate modes, scaling modes, application profile editing, individual company features (like a Vulkan driver picker for AMD), a quick way to see supported features and specs, performance and temperature monitoring, gaming features (like vkBasalt integration), and more.
                Most of those things are outside the scope of what mesa is doing and don't belong in mesa.

                Originally posted by skeevy420 View Post
                On Linux you have to set 32 variables on the command line, create custom text files to tweak effects, and run 4 or 5 different GUI programs to do the rest.
                Can you tell me more about what exactly are you doing that needs such a complicated setup?
                When I play a game I usually never need any special config and just use the defaults (unless I specifically want to test a driver feature for my work).

                Comment

                Working...
                X