Thanks to Valve’s Linux graphics team, VK_EXT_device_generated_commands is now supported by the Radeon “RADV” Vulkan driver with the upcoming Mesa 24.3 release.

Prominent RADV developer Samuel Pitoiset at Valve has landed support for VK_EXT_device_generated_commands, the multi-vendor device generated commands “DGC” implementation. Last month with Vulkan 1.3.296 the VK_EXT_device_generated_commands extension was introduced to succeed NVIDIA’s vendor-prefixed DGC extension. The device generated commands extension allows for the GPU device to generate a number of commands for command buffers. VK_EXT_device_generated_commands is a very big and important addition to the Vulkan API: Valve’s Mike Blumenkrantz has argued that DGC is the biggest addition to Vulkan since ray-tracing.

  • eldavi@lemmy.ml
    link
    fedilink
    arrow-up
    2
    ·
    1 month ago

    i tapped on the easy button the last time i wanted a new linux rig and bought a linux laptop from a linux company with its own os and its own paid developers and i’ve learned recently that it’s made me unaware of the state of ATI and linux compatability vs nvidia’s. what’s your take on the state of affairs now?

    i went with the easy button because of my experiences with nvidia and especially on my laptops; but my klutzy self has made getting a new one a necessity and i’m thinking that i’m going to go with AMD/ATI next time and do it the hard way like i used on a windows laptop; or maybe a mac.

    • Semperverus@lemmy.world
      link
      fedilink
      English
      arrow-up
      5
      ·
      edit-2
      1 month ago

      The story goes that around the time the AMD RX480 came out - or maybe a little after - AMD almost completely opensourced their GPU drivers on Linux.

      They gave two offerings: amdgpu (open source) and amdgpu-pro (Closed source, included some extra features most people wouldn’t care about but some really do). Thus retiring the old radeon driver.

      At first, the new drivers were decent, if slightly unstable.

      AMD also provided a Vulkan driver by the name of amdvlk, which was good but the performance wasn’t very exciting.

      Then Valve started contributing. They started providing a Vulkan driver for AMD cards that is better than AMD’s called RADV, which has since become the default and has been mainlined into mesa. Performance went through the roof.

      I may be wrong but I think Valve may also contribute back to the amdgpu driver.

      Wayland finally became a thing, and between AMD, Nvidia, and Intel, AMD was king in stability and performance in this arena. Especially on KDE, which had very early adoption of many important features long before Gnome had them - Mixed monitor scaling, Variable refresh rate, mixed monitor refresh rate, DRM modesetting for VR headsets, HDR monitor support, etc., in addition to a bunch of extra security features which some appreciate greatly and others find frustrating.


      Over in Nvidia land, they were busy doing Nvidia things. And by Nvidia things, I mean doing nothing new.

      Nvidia’s drivers mostly remained just as you remember them from 15 years ago, with the Nvidia config tool for X11 and so on. Their closed-source driver performance on Linux was good but not great.

      Wayland threw a wrench in Nvidia’s gears. Nvidia tried to control the narrative by trying to force EGLStreams as the standard, several years after the community had settled on GBM as the standard (I won’t dive much into what those are - for now, you only need to know that they’re important in making Wayland work at all and affect performance, stability, and the ability to talk to the Wayland protocol). For a very long time, Nvidia card users were either unable to use Wayland, or had a very poor experience with it; experiencing stuttering, flashing or flickering screens, black boxes, and so on. This whole thing locked Nvidia users to the outdated X11 system which is missing a lot of modern features mentioned previously in the AMD section.

      Some time later, Nvidia was hacked by a group called LAPSUS$, who among other things demanded that Nvidia fully open-source their drivers. They essentially got ahold of Nvidia’s code and said “Either you open-source it or we do.”

      I forget exactly what Nvidia’s direct response to them was, but interestingly some time later, they opted to “open-source” their drivers by reducing the size of and wrapping the closed proprietary binaries in what the Linux community was calling an “open-source condom.” Effectively, we got drivers that behaved the way the Linux kernel expected, despite not being truly open source. A neat hat trick.

      Something else happened, I think maybe more bits got open sourced, but as of recently there are now new open source Nvidia drivers as of driver version 555, called nvidia-open (not to be confused with nouveau open source community drivers), and you can now use Nvidia cards with 80-90% as much ease and performance as AMD users have on Linux. There is still some jank and rough edges that need to be smoothed out, but Nvidia is now part of the 21st century on Linux.

      I personally would recommend avoiding Nvidia due to their history and how they treat their Linux customers, but if you already have an Nvidia card and don’t want to or can’t afford to switch, you can now use your card with relatively smooth and high performance on Linux - and use Wayland to boot.

      • eldavi@lemmy.ml
        link
        fedilink
        arrow-up
        2
        ·
        1 month ago

        you can now use Nvidia cards with 80-90% as much ease as AMD users have on Linux

        i’ve got a couple of goals that i want to accomplish with my new build and i think that forcing myself to do it the hard way like i used to 20ish years ago would help with that; but if amd has gotten easy, i wonder if i should go with nvidia again.

        you’ve made me aware that i’ve missed the whole wayland/x11 situation by going with certified linux hardware and avoiding nvidia at all costs because of my experiences with it in the past. this endeavor has made me realize how disconnected i’ve made myself from the reality of 95% of linux users by sitting in my little bubble of certified linux hardware and only talking to other linux professionals instead of the general public.

        my conversations with those professionals are NOTHING like the ones here and you can tell when capitalism has sucked the passion out of it for them because it takes one to know one. i’m finding that jumping back in is rekindling it for me; i’ve spent a considerable about of times making plans for this build and i can’t remember how long it’s been since if felt any excitement about a linux-centric project.

      • eldavi@lemmy.ml
        link
        fedilink
        arrow-up
        3
        ·
        1 month ago

        that dated comment was right and i hit that easy button five years ago. also i’m realizing now that doing so has completely removed me from the discourse that happens nowadays when it comes to gpu’s and linux.

        amd had already bought ati by the time i hit that easy button and that distinction that i used wasn’t out of place at the last time i was paying attention and participating; or atleast wasn’t so in my experience.

        there used to be lists of rankings for compatibility for nvidia drivers and open source drivers as well. i wonder how i would go about finding the same for amd.

        • Semperverus@lemmy.world
          link
          fedilink
          English
          arrow-up
          2
          ·
          edit-2
          1 month ago

          For AMD, it’s literally just make sure mesa is installed (it is by default on most distros), make sure radv is installed (it is by default on most distros), and then go.

          From there, if you are gaming, you handle whatever your games need like enabling 32-bit libraries for Steam if your distro doesn’t by default, or doing whatever WINE or Lutris wants you to do.

          Done.

    • DaPorkchop_@lemmy.ml
      link
      fedilink
      arrow-up
      4
      ·
      1 month ago

      Traditional graphics code works by having the CPU generate a sequence of commands which are packed together and sent to the GPU to run. This extension let’s you write code which runs on the GPU to generate commands, and then execute those same commands on the GPU without involving the CPU at all.

      This is a super powerful feature which makes it possible to do things which simply weren’t feasible in the traditional model. Vulkan improved on OpenGL by allowing people to build command buffers on multiple threads, and also re-use existing command buffers, but GPU pipelines are getting so wide that scenes containing many objects with different render settings are bottlenecked by the rate at which the CPU can prepare commands, not by GPU throughput. Letting the GPU generate its own commands means you can leverage the GPU’s massive parallelism for the entire render process, and can also make render state changes much cheaper.

      (For anyone familiar, this is basically a more fleshed out version of NVIDIA’s proprietary NV_command_list extension for OpenGL, except that it’s in Vulkan and standardized across all GPU drivers)