NVIDIA 435 driver looks exciting

im not exactly sure what the difference is between glxgears and glxgears_pixmap but the only game i've tested (briefly) was native borderlands 2 and it was struggling on medium/low settings. on my prime setup it runs great on high settings. i'll have to try different intel driver options, "TearFree" comes at a cost on the intel driver, and prime uses modesetting but it's able to use prime sync so it fixes the tearing issues i have with the modesetting driver. i was not able to get prime sync to work with render offload, enabling it always ended in xorg failing to start.

if anyone is using these new drivers, could you try running a vulkan game with vsync enabled and see if it's working properly.

i'm using a PRIME setup, not this new "render offload" feature but i think it has something to do with the combination of the new 435.* drivers + vulkan + vsync. results in an unusable setup. further explanation

I got 435 + vulkan + vsync. Im on gnome and modesetting driver with nvidia offload. Everything is fine at here ^^

the problem happens with the combination of prime+vulkan+vsync on 435 drivers. render offload, while a good thing that nvidia is doing something for hybrid graphics on linux is also not very practical because even when your not using the nvidia gpu it has to remain powered on because the xorg process needs to be run on the nvidia for offload to work.

for everyday use you end up using the power cost of 2 gpu's while only getting the benefit of 1 unless you run the program using the launch variable.

i dont have concrete benchmarks but comparing the performance between prime and offload also didnt fare well for render offload.

red faction: remarstered on render offload and no vsync struggled to get 50+ fps while on prime with vsync disabled it easily hits 70+ fps. (identical settings, stock clock/mem)

offload also will not work with coolbits, so no fan or clocking capabilities. aside from the novelty of it being the latest shiny & new thing available, it's really nothing to get excited over and was more disappointing than anything else in it's current state so i'll be sticking to a prime setup and possibly add the functionality of a third mode to optimus-switch for this render offload so i can easily switch back and forth to check the progress on it if any.

2 Likes

I would also like to test how this works but my hardware is old (nvidia390xx).

I thought it was supposed to replace the "bumblebee" method, without the auto-select feature, like using optirun/primusrun. Similar... I think I've read some nvidia notes with Power Saving configuration on the new driver feature. Maybe the power consumption is better controlled? Wishes... I know... :disappointed_relieved:

1 Like

Turing cards are suppose to have better power management to use less power, but can never be powered off (using offload) because xorg needs to run on it.

dont worry, your not missing much. i'm hoping for a true on-demand optimus setup like on windows but this is definitely not it.

if the card remaining on was the only downside i wouldnt care, but losing performance, losing coolbits, on top of having the nvidia gpu powered on doing nothing but wasting power until launching with a parameter is silly. with prime both cards remain on, performance is better, no launch variables are needed.

on the upside with this new render offload it seems the black screen issues that come with fumblebee are a non issue so making it the default setup for 435.xx driver compatible installs makes perfect sense. even when removing any video .conf file from /etc/X11/xorg.conf.d i was still met with a desktop and thats much better than i can say for crumblebee :wink:

2 Likes

With all this situation of nvidia beta primus driver needing to run both GPUs all the time to get primus working because xorg, I have read than wayland is supposed to provide a better environment for switchable cards.
I wonder if nvidia is planning to do a primus implementation in linux that is comparable in power usage to the one done in windows, so they will probably have to do it in wayland. I wonder if they are even considering doing this work for wayland as well.

So seems to be that last testing update deleted any trace of nvidia drivers. Then I guess this is the chance I have to try this new functionality before I go find my USB driver to format manjaro.

Then, at this point, what do I have to do to try the new prime stuff in my optimus laptop? First thing I though was to search for the driver in MHWD, but there is nothing here

Screenshot_20190825_172620

then what can I do?

i dont think nvidia is in there future plans. if the nvidia driver is loaded and you want to start sway you need to use the the flag sway --my-next-gpu-wont-be-nvidia :rofl: or it refuses to run.

remove any configurations left behind by your previous setup, install the 435 driver package
mhwd -i pci video-nvidia-435xx

then this
1 Like

Hey, thanks a lot, it worked surprisingly flawlessly.

1 Like

triggered
Black screen comes with Bumblebee sometimes but not because of Bumblebee. It happens due to current implementation. What mhwd Bumblewee options lack is adding i915 to the list of modules in mkinitcpio.conf and regenerating of initramfs when selecting video-hybrid-intel-nvidia-bumblebee (or whatever it's called). In fact, this should be a must for Intel driver if system is configured to use i915 as primary display driver since it also makes external monitors' early initialisation (not critical, but anyway). Inclusion of i915 to the list of modules does not prevent using of modesetting, nouveau or nvidia drivers. It is harmless (to the best of my knowledge) for any system with or without Intel graphics.

2 Likes

This thread is overblown with the interesting info. My mind is melting.

I came to conclusion that with my current optimus-manager setup I rather stay on 430 series. There are too many uncertainties:

  • nvidia is never fully powered down
  • 435 drivers work slower on KDE
  • not sure how the configuration will really work with optimus-manager that does some deep level changes to the systemd and creates own configs that may not be compatible with 435 driver

Thanks @philm that we have now static series and we can stay on the 430 one. This was a good decision although it creates some initial pains but also excitement. 435 is rather not suitable for the stable branch as it seems. Too many things are unsure, including the driver management in Manjaro.

Since drivers 430 works fine and my optimus-manager setup is OK too I refrain from jumping into 435 wagon. I'm not knowledgeable enough to work on this or provide valuable output here. I see that smart people are already working on it so I just sit and wait like other average users till this will be sorted out.

Anyone seen it yet?
There's a new update, now v. 435.21

  • Fixed a bug that caused the X server to crash when using HardDPMS with an NVIDIA-driven GPU Screen.
  • Fixed a bug which caused the kernel to panic when exiting a single X server when multiple X servers were active and in an SLI configuration.
  • Fixed a regression introduced in the 430.* series of releases that caused a segmentation fault in libnvcuvid.so while using Video Codec SDK APIs on certain graphics boards. (hey @korealinux :wink:)
  • Added initial experimental support for runtime D3 (RTD3) power management on Turing notebook GPUs.
  • Improved nvidia-bug-report.sh to collect runtime D3 (RTD3) power management information.
  • Improved nvidia-bug-report.sh to collect ACPI tables when the acpidump tool is available.
  • Added Vulkan and OpenGL+GLX support for PRIME render offload. Please see the PRIME Render Offload chapter in the README for system requirements and configuration details.
  • Added support for changing Digital Vibrance in the display controls section of nvidia-settings on Turing hardware.
  • Fixed the cuvidParseVideoData API in the NVCUVID driver to correctly propagate errors returned by the PFNVIDSEQUENCECALLBACK callback function to the application.
  • Fixed a bug that caused the NVIDIA X driver to behave incorrectly or crash when a client queried Xinerama information on X servers with a non-NVIDIA X screen as screen 0.
  • Fixed the "Image Settings" options in the "OpenGL Settings" page of nvidia-settings for Quadro GPUs. Previously, OpenGL rendering on Quadro would behave as if the "High Quality" option were selected regardless of the selection. Now, the setting will default to "High Quality" for Quadro but selecting a lower option will affect rendering accordingly. (Other GPUs are unchanged: the default remains "Quality", but other options can be selected if desired.)
  • Fixed a bug that could cause Vulkan applications to generate spurious warning messages about a missing NV-GLX extension.
  • Removed the non-GLVND OpenGL libraries from the NVIDIA Linux driver installation package. The GLVND OpenGL libraries were introduced in release 361.16, and have been installed by default since release 364.12, with the non-GLVND versions available as an alternative via the "--no-glvnd-glx-client" and "--no-glvnd-egl-client" installer options. As the non-GLVND libraries are no longer included in the installation package, these options will no longer have any effect.
  • Fixed a bug that prevented nvidia-drm from marking preferred modes properly when reporting display information via the DRM-KMS API.
  • Updated nvidia-installer to make compiler mismatches non-fatal when adding precompiled kernel interfaces to an installer package using the "--add-this-kernel" option, to be more consistent with the behavior when installing without precompiled interfaces.
  • Fixed the NvEncodeAPI driver to correctly reject the encoding of sequences with resolutions smaller than what the NVENC supports.
  • Fixed display color range handling on pre-Turing GPUs, such that when limited color range is selected through the display controls page in nvidia-settings, output pixel values will be correctly clamped to Consumer Technology Association (CTA) range.
2 Likes

Most likely they will backport that fix to 430xx series ...

2 Likes

That is the 435.17 highlights.

I think the only change for 435.21 is

Fixed a bug that caused the X server to crash when using HardDPMS with an NVIDIA-driven GPU Screen.


[TMI Warning]
Even though 435 fixed the cuda segmentation faults, the fix has changed cuda behavior for my particular needs. Most people could live with such a specific cosmetic bug for a very niche video format, but I just happen to work with a lot of interlaced videos. And cuda is the fastest when seeking through interlaced videos of any decoder I've tested (backwards seeking especially). So I am very happy 418 is available now. :hugs:

2 Likes

I installed the driver from the unstable branch and it comes up when I run nvidia-smi but trying to run a game like dota 2 with the offload commands just gives me the following error:

Panorama requires a full render system, please check your launch settings.

Have any of you seen something similar?

Have you rebooted the system?

Hi all!

According to NVIDIA's instructions here:
http://download.nvidia.com/XFree86/Linux-x86_64/435.21/README/primerenderoffload.html

the configuration of xserver is very simple, as long as the following requirements applied:

X Server Requirements
NVIDIA's PRIME render offload support requires the following git commits in the X.Org X server:

7f962c70 - xsync: Add resource inside of SyncCreate, export SyncCreate

37a36a6b - GLX: Add a per-client vendor mapping

8b67ec7c - GLX: Use the sending client for looking up XID's

56c0a71f - GLX: Add a function to change a clients vendor list

b4231d69 - GLX: Set GlxServerExports::{major,minor}Version

But as I see here


only one commit has already be done.

So I wonder how long will it take to have a fully functional PRIME system in Manjaro, since so many things depend on 3rd party work... I've read somewhere, the patches should be ready in xorg version 1.20.6 but I'm not sure if this is true.
I have an OPTIMUS laptop (like so many people) and so far I'm forced to function it in NVIDIA full strength, since bumblebee, and optimus-manager have caused me issues from time to time. I'm not a gamer but I do 3d rendering often, and under these conditions, my battery has already dropped to 96% fully charged.

PS: I haven't read all the posts here very carefully, so forgive me if I'm missing something... Any answer would be appreciated!

Thanks

The point of a forum thread is to be read. Please read it. This isn't XDA :wink:

XDA! I liked that :slight_smile:

Ok, sorry...
I've read it now.

2 Likes

Followed the directions here and now I cannot boot. It prompts me to select an OS (I only have Manjaro) and once I select it, it stays on my motherboard splash screen. Alt + ctrl + f2 doesn't allow me to go in and delete the config file to try and undo my mess. Anyone have a suggestion? Thank you!

Forum kindly sponsored by