Announcement

Collapse
No announcement yet.

NVIDIA 510.39.01 Linux Beta Brings Vulkan Dynamic Rendering, AV1 VDPAU Decode & More

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

  • #51
    Originally posted by Cybmax View Post
    sudo dkms remove nvidia/495.46 -k all
    sudo update-initramfs -k all -u
    reboot to safe mode -> Choose "Networking" (to mount filesystems) -> choose root
    I prefer to install the driver using my own user, so
    su - username
    sudo ./NVIDIA-xxxxx.run
    Answer "YES" if you want to use DKMS, and YES to 32-bit libraries - NO to generating xorg.
    After the setup is done, you can install driver for other kernels if you are using it - eg. sudo dkms autoinstall -k 5.11.xxx (or whatever)
    Finish up by running
    sudo update-initramfs -k all -u
    I just wanted to add you need to ensure that you blacklist nouveau driver as well before rebooting to install via the .RUN file:

    $ sudo bash -c "echo blacklist nouveau > /etc/modprobe.d/blacklist-nvidia-nouveau.conf"
    $ sudo bash -c "echo options nouveau modeset=0 >> /etc/modprobe.d/blacklist-nvidia-nouveau.conf"
    $ sudo update-initramfs -u

    Comment


    • #52
      Originally posted by bple2137 View Post
      Was it a good idea to buy a NVIDIA GPU?
      No. It sucks. I didn't touch any NVIDIA hardware for a decade after I ditched my old PC around 2012. Once I helped a friend to get PRIME going on his laptop and it wasn't pleasant experience. The support for NVIDIA hardware is worse than it remember it back in 2007. It was problematic to install, but it was running fine when configured properly. Now it's easy to install, but the experience with GNOME or KDE Plasma is just terrible. So NVIDIA...
      My question to you is; If you use OBS Studio, would you really be fine living without NVENC? At least in my experience, beyond the use cases for CUDA specific ML models, NVENC is one of the best things about recent NVIDIA GPUs, my understanding is that AMD's hardware encoding doesn't do that well in comparison. I feel like this along side with CUDA dominance in GPU compute, I think some of the pains on the NVIDIA side are worth living with, at least for me.

      I would love to go for a full AMD system, but I just don't see it happening until at least RDNA3, I'll need to review all of these requirements then to see if it's worthwhile. In the meantime, sitting on my STRIX 2080 Super I bought for $789.97 seems like a pretty good deal right now given the current market.

      Comment


      • #53
        Originally posted by Cybmax View Post

        Using the .run package works just fine on Ubuntu if you are not horribly daunted by using manual commands... Easy as windows? Nope.. But i tend to test whatever nVidia driver they got due to hacking around with various Wine/DXVK/vkd3d stuff all the time.

        I only use the .run driver these days, and what i do is somewhat cumbersome, but very reliable.
        sudo dkms remove nvidia/495.46 -k all
        sudo update-initramfs -k all -u
        reboot to safe mode -> Choose "Networking" (to mount filesystems) -> choose root
        I prefer to install the driver using my own user, so
        su - username
        sudo ./NVIDIA-xxxxx.run
        Answer "YES" if you want to use DKMS, and YES to 32-bit libraries - NO to generating xorg.
        After the setup is done, you can install driver for other kernels if you are using it - eg. sudo dkms autoinstall -k 5.11.xxx (or whatever)
        Finish up by running
        sudo update-initramfs -k all -u

        reboot

        Easy? Nah.. probably not, but i have done it so many times so i am not scared. Can you mess stuff up and never see your desktop again? Sure.. Comparable to the "windows experience"? Well.. depends if you are running DDU cleaner from safemode and whatnot (which you kinda need to do especially if you are downgrading)..

        Things are usually not easy until you have done it a few times. Building software with Ubuntu Launchpad is not overly hard either.. Loads of templates usable for making your own backports there, but most things seems very hard until you have done it a few times.
        I'm actually surprised people still do it these days. That's a great tip if you want to make it more likely to bork your OS at some point (e.g. dist-upgrade). I remember messing the Ubuntu install many many times back when I was noob in late 00's. That's cool you know what you're doing, but please don't recommend the method.

        Comment


        • #54
          Originally posted by bple2137 View Post

          I'm actually surprised people still do it these days. That's a great tip if you want to make it more likely to bork your OS at some point (e.g. dist-upgrade). I remember messing the Ubuntu install many many times back when I was noob in late 00's. That's cool you know what you're doing, but please don't recommend the method.
          I am truly sorry if i came across as "recommending the method". I had hoped "Can you mess up and never see your desktop again? Sure..." would be a indicator of likelyhood of actually borking your desktop.

          So.. nope, i am absolutely not recommending the method at all, but it CAN be done if you like me really NEED to use a different driver than the distro provided one.

          PS. And i HAVE actually completely borked my Windows box by messing with DDU and various registry cleaners to get rid of old drivers when needing to downgrade, so even THAT can be done. Safest bet would ofc be to run the M$ WHQL (windowsupdate) provided driver... but who in their right mind does that these days if you play anything other than solitaire...

          Comment


          • #55
            Originally posted by Cybmax View Post

            I am truly sorry if i came across as "recommending the method". I had hoped "Can you mess up and never see your desktop again? Sure..." would be a indicator of likelyhood of actually borking your desktop.

            So.. nope, i am absolutely not recommending the method at all, but it CAN be done if you like me really NEED to use a different driver than the distro provided one.

            PS. And i HAVE actually completely borked my Windows box by messing with DDU and various registry cleaners to get rid of old drivers when needing to downgrade, so even THAT can be done. Safest bet would ofc be to run the M$ WHQL (windowsupdate) provided driver... but who in their right mind does that these days if you play anything other than solitaire...
            No hard feelings, just not a fan of that method and memories of inferior experience. Also yet another reason why I feel bad about Debian-like distros, even though I spent with them most of my childhood. Why the darn packaging system has to be so complicated and what the complexity brings actually besides pain for both user and package maintainer? Why there's no simple and good way for you to build a deb using any nvidia*.run file? Why we still need to blacklist nouveau after all these years (I mean remember to create the blacklist file yourself)? Why Debian systems usually include so many modifications that are out of control of the package manager? And I'm not only talking desktop system, but even more importantly I have Debian servers in mind, which by the way are just as flawed.

            Comment


            • #56
              Originally posted by Random_Jerk View Post
              Forget AV1 Decode, but is there a way to get VDPAU working with VP9 decode on Nvidia 20xx/30xx cards on Chromium based browsers? I always seem to not be able to get it to work.
              Depends on your distro. On Arch it takes like 3 steps, and I have VP9 video decode working in Chromium, Chrome, and Brave.

              You need the fork of the libva-vdpau-driver, it's in the AUR at https://aur.archlinux.org/packages/l...driver-vp9-git

              If you're not on an Arch-based distribution, then you just need to go to https://github.com/xuanruiqi/vdpau-va-driver-vp9and build from the instructions (it's just a simple meson/ninja build, like 3 steps).

              The only difficult part for non-Arch-based distros is your lack of the ability to use ~/.config/chromium-flags.conf (or ~/.config/chrome-flags.conf for Chrome, and ~/.config/brave-flags.conf for Brave). But I think nowadays all you have to do is enable some options in chrome://flags (like ignore gpu blocklist, and enable hardware accelerated video decode). Otherwise you'll have to copy the .desktop file to ~/.local/share/applications and append a bunch of flags in between the `/usr/bin/chromium` (or whatever) and the %U in the Exec= line.

              You don't need a patched build of Chromium because as I said, it works in regular Chrome which is proprietary and obviously can't be patched by distro maintainers to add VAAPI support. And I don't leave it up to looking at media internals, I look at GreenWithEnvy and watch the "Decoder" usage bar go active when I play a VP9 video in Chromium/Chrome/Brave. So I know for a fact it's working.

              Once you have the vp9 vdpau driver installed like I told you, you can test it out by running chromium from the terminal with something like this:

              Code:
              chromium --disable-gpu-driver-bug-workarounds --enable-native-gpu-memory-buffers --enable-gpu-rasterization --enable-oop-rasterization --disable-gpu-vsync --enable-zero-copy --use-gl=desktop --enable-accelerated-video-decode --ignore-gpu-blocklist --enable-gpu-compositing --disable-gpu-driver-workarounds --disable-font-subpixel-positioning --enable-features=VaapiVideoDecoder
              I'm not sure if all of those are needed, but launching with that works for me (and it's basically the same as the contents of my ~/.config/chromium-flags.conf:

              Code:
              >_ cat ~/.config/chromium-flags.conf
              
              --disable-gpu-driver-bug-workarounds
              --enable-native-gpu-memory-buffers
              --enable-gpu-rasterization
              --enable-oop-rasterization
              --disable-gpu-vsync
              --enable-zero-copy
              --use-gl=desktop
              --enable-accelerated-video-decode
              --ignore-gpu-blocklist
              --enable-gpu-compositing
              --enable-smooth-scrolling
              --disable-gpu-driver-workarounds
              --disable-font-subpixel-positioning
              --enable-features=VaapiVideoDecoder
              Like I said, on Arch-based distributions it literally just takes installing the AUR packages, setting up your ~/.config/chromium-flags.conf (or chrome-flags.conf for Chrome and brave-flags.conf for Brave), and that's it. Well, and also making sure you don't have any h264ify extensions installed or active or anything.

              I think that Chromium and Chrome have exposed the stuff you need to enable in chrome://flags (the reason why all those flags used to be needed was that it wasn't exposed, but I believe everything you need is exposed now). Here's a screenshot of my chrome://flags on chromium:

              Screenshot_20220126_031526.png

              If you can't click on that to enlarge it, you can look at it here https://i.imgur.com/9wWPiT6.png

              The ones I've highlighted are the only ones that should have anything to do with video decoding. You might still need
              Code:
              --enable-features=VaapiVideoDecoder
              though.

              I've tried to go as in-depth as possible, but really it shouldn't take more than 5 minutes to set up on a non-Arch distro. Install the vdpau vp9 driver from GitHub (if you're not on Arch or a derivative), enable the flags, and if it doesn't work, try launching from the terminal (after making sure all processes are dead) with the flags I gave you.
              Attached Files

              Comment


              • #57


                There's a repository run by nvidia.

                The holy grail.

                Comment

                Working...
                X