NVIDIA 364.12 release: Vulkan, GLVND, DRM KMS, and EGLStreams
This looks like an impressive release. I'm having a hard time following a lot of the new features, but by any chance is the xrandr 1.5 support for display port 1.2 MST monitors included in this release? Thanks.
This looks like an impressive release. I'm having a hard time following a lot of the new features, but by any chance is the xrandr 1.5 support for display port 1.2 MST monitors included in this release?

Thanks.

#31
Posted 03/23/2016 08:44 PM   
[quote=""]After nvidia-drm has been loaded with modeset=1, attempting to run weston-launch outputs the following error in the journal: [code] [ 5338.262318] vgaarb: device changed decodes: PCI:0000:02:00.0,olddecodes=none,decodes=none:owns=io+mem [ 5338.262416] nvidia-nvlink: Nvlink Core is being initialized, major device number 250 [ 5338.262437] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 364.12 Wed Mar 16 21:11:26 PDT 2016 [ 5338.263459] nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 364.12 Wed Mar 16 20:44:12 PDT 2016 [ 5338.263950] [drm] [nvidia-drm] [GPU ID 0x00000200] Loading driver [ 5338.824705] nvidia-modeset: Allocated GPU:0 (GPU-595b3d36-aaea-d916-d4ce-4efa80c7c223) @ PCI:0000:02:00.0 [ 5338.886475] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 5338.886476] [drm] No driver support for vblank timestamp query. [ 5350.257392] [drm:nvidia_drm_gem_import_nvkms_memory [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000200] Failed to import NVKMS memory to GEM object [/code] [b]Failed to import NVKMS memory to GEM object[/b] -- What could I have missed?[/quote] Did you apply the necessary patches to weston to support the interfaces NVIDIA uses for buffer sharing (EGLStreams)? Did you launch weston as "weston --use-egldevice"?
said:After nvidia-drm has been loaded with modeset=1, attempting to run weston-launch outputs the following error in the journal:

[ 5338.262318] vgaarb: device changed decodes: PCI:0000:02:00.0,olddecodes=none,decodes=none:owns=io+mem
[ 5338.262416] nvidia-nvlink: Nvlink Core is being initialized, major device number 250
[ 5338.262437] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 364.12 Wed Mar 16 21:11:26 PDT 2016
[ 5338.263459] nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 364.12 Wed Mar 16 20:44:12 PDT 2016
[ 5338.263950] [drm] [nvidia-drm] [GPU ID 0x00000200] Loading driver
[ 5338.824705] nvidia-modeset: Allocated GPU:0 (GPU-595b3d36-aaea-d916-d4ce-4efa80c7c223) @ PCI:0000:02:00.0
[ 5338.886475] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 5338.886476] [drm] No driver support for vblank timestamp query.
[ 5350.257392] [drm:nvidia_drm_gem_import_nvkms_memory [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000200] Failed to import NVKMS memory to GEM object


Failed to import NVKMS memory to GEM object -- What could I have missed?


Did you apply the necessary patches to weston to support the interfaces NVIDIA uses for buffer sharing (EGLStreams)? Did you launch weston as "weston --use-egldevice"?

#32
Posted 03/23/2016 09:32 PM   
I was using weston-launch which wasn't sufficient. Your question drove me to launch weston with full options and it's working now. Very slick job NVidia. Will now figure out how to get google-chrome to run in it. Thanks.
I was using weston-launch which wasn't sufficient. Your question drove me to launch weston with full options and it's working now. Very slick job NVidia.

Will now figure out how to get google-chrome to run in it. Thanks.

#33
Posted 03/23/2016 09:57 PM   
with GLVND, how is libglx.so (the X-server extension, not libGLX) supposed to be handled? The X-Server comes with its own version of it, and nvidia driver provides one as well. Which one should be used?
with GLVND, how is libglx.so (the X-server extension, not libGLX) supposed to be handled? The X-Server comes with its own version of it, and nvidia driver provides one as well. Which one should be used?

#34
Posted 03/24/2016 07:27 AM   
Strange, my current setup has a modprobe.d file that sets the modeset option to 1. When I boot with kernel parameter 3 so that I start into TTY1 I can run the eglstreams-kms-example. When I boot normally which starts the GDM Login and then switch to TTY2 and stop gdm, I can't run the example anymore. I confirmed that no instance of Xorg or anything is running anymore. In that case I have to modeprobe -r nvidia-drm and then load it again with modeset=1.
Strange, my current setup has a modprobe.d file that sets the modeset option to 1. When I boot with kernel parameter 3 so that I start into TTY1 I can run the eglstreams-kms-example. When I boot normally which starts the GDM Login and then switch to TTY2 and stop gdm, I can't run the example anymore. I confirmed that no instance of Xorg or anything is running anymore. In that case I have to modeprobe -r nvidia-drm and then load it again with modeset=1.

#35
Posted 03/24/2016 02:40 PM   
GLVND only applies to GLX clients at the moment. You still need the NVIDIA libglx.so in the X server in order to use OpenGL with the NVIDIA driver.
GLVND only applies to GLX clients at the moment. You still need the NVIDIA libglx.so in the X server in order to use OpenGL with the NVIDIA driver.

Aaron Plattner
NVIDIA Linux Graphics

#36
Posted 03/24/2016 02:44 PM   
[quote="aplattner"]GLVND only applies to GLX clients at the moment. You still need the NVIDIA libglx.so in the X server in order to use OpenGL with the NVIDIA driver.[/quote] Just so I understand this correctly: Even if mesa some day gets glvnd support, the only benefit is that both mesa and nvidia driver won't overwrite each others' libGL, but I still need to point the x-server to the nvidia libglx if I want to render on the quadro (and use the x-server provided libglx.so for rendering on the intel)? Or am I missing the point of the libglx.so extension entirely?
aplattner said:GLVND only applies to GLX clients at the moment. You still need the NVIDIA libglx.so in the X server in order to use OpenGL with the NVIDIA driver.


Just so I understand this correctly: Even if mesa some day gets glvnd support, the only benefit is that both mesa and nvidia driver won't overwrite each others' libGL, but I still need to point the x-server
to the nvidia libglx if I want to render on the quadro (and use the x-server provided libglx.so for rendering on the intel)?
Or am I missing the point of the libglx.so extension entirely?

#37
Posted 03/24/2016 05:52 PM   
Right. The client-side glvnd allows multiple vendor libraries to coexist and for the correct one to be loaded automatically based on information sent by the X server. So it eliminates some of the tricks needed for things like Bumblebee to switch the client-side runtime by playing games with the loader search path. Ideally, there would be similar functionality on the server side, but that's not implemented yet.
Right. The client-side glvnd allows multiple vendor libraries to coexist and for the correct one to be loaded automatically based on information sent by the X server. So it eliminates some of the tricks needed for things like Bumblebee to switch the client-side runtime by playing games with the loader search path.

Ideally, there would be similar functionality on the server side, but that's not implemented yet.

Aaron Plattner
NVIDIA Linux Graphics

#38
Posted 03/25/2016 04:58 AM   
This driver was causing a slightly different refresh rate on my monitor than the one set in Gnome which caused thin vertical lines. The gnome developer suggested I remove ~/.config/monitors.xml but it didn't help. This is a HDMI cable. Reverting to 361.28 fixed it. I didn't want to accidentally damage my monitor.
This driver was causing a slightly different refresh rate on my monitor than the one set in Gnome which caused thin vertical lines. The gnome developer suggested I remove ~/.config/monitors.xml but it didn't help.
This is a HDMI cable.
Reverting to 361.28 fixed it. I didn't want to accidentally damage my monitor.

#39
Posted 03/25/2016 07:56 AM   
Regarding the last post, this is a nvidia-bug-report log http://d-h.st/FBQi from the stable driver. Please take a look before releasing the final version of the driver since I'm not sure if this kind of thing is safe for monitors. 8 hours now on old driver 361.28 and I can confirm it didn't have this bug.
Regarding the last post, this is a nvidia-bug-report log http://d-h.st/FBQi from the stable driver.
Please take a look before releasing the final version of the driver since I'm not sure if this kind of thing is safe for monitors.

8 hours now on old driver 361.28 and I can confirm it didn't have this bug.

#40
Posted 03/25/2016 11:11 AM   
I'm trying to get Vulkan to work on a Nvidia optimus laptop, but apparently neither "vkcube" or "vulkaninfo" see the Nvidia GPU, only the Intel one. It seems like "vkEnumeratePhysicalDevices" only return the Intel GPU.
I'm trying to get Vulkan to work on a Nvidia optimus laptop, but apparently neither "vkcube" or "vulkaninfo" see the Nvidia GPU, only the Intel one.

It seems like "vkEnumeratePhysicalDevices" only return the Intel GPU.

#41
Posted 04/03/2016 10:15 AM   
[quote=""]Regarding the last post, this is a nvidia-bug-report log http://d-h.st/FBQi from the stable driver. Please take a look before releasing the final version of the driver since I'm not sure if this kind of thing is safe for monitors. 8 hours now on old driver 361.28 and I can confirm it didn't have this bug.[/quote] Issue is still in 364.15 but only happens when using hdmi. Downgrading to 361.42 fixes it.
said:Regarding the last post, this is a nvidia-bug-report log http://d-h.st/FBQi from the stable driver.
Please take a look before releasing the final version of the driver since I'm not sure if this kind of thing is safe for monitors.

8 hours now on old driver 361.28 and I can confirm it didn't have this bug.

Issue is still in 364.15 but only happens when using hdmi.
Downgrading to 361.42 fixes it.

#42
Posted 04/07/2016 08:24 AM   
hi devs please fix suspend and ctl+alt+F7 ... great thankx mounir using ubuntu kernel 4.3
hi devs
please fix suspend and ctl+alt+F7 ...
great thankx
mounir

using ubuntu kernel 4.3

#43
Posted 04/09/2016 11:30 AM   
[quote=""][quote=""]Regarding the last post, this is a nvidia-bug-report log http://d-h.st/FBQi from the stable driver. Please take a look before releasing the final version of the driver since I'm not sure if this kind of thing is safe for monitors. 8 hours now on old driver 361.28 and I can confirm it didn't have this bug.[/quote] Issue is still in 364.15 but only happens when using hdmi. Downgrading to 361.42 fixes it.[/quote] Ok, it turns out this only happens when I have Samsung magicbright dynamic contrast enabled. But this was not a problem under the 361.42 driver so it is still a regression in the nvidia xorg driver. But now at least we know how to reproduce it. Can nvidia now take a look? Thank you.
said:
said:Regarding the last post, this is a nvidia-bug-report log http://d-h.st/FBQi from the stable driver.
Please take a look before releasing the final version of the driver since I'm not sure if this kind of thing is safe for monitors.

8 hours now on old driver 361.28 and I can confirm it didn't have this bug.

Issue is still in 364.15 but only happens when using hdmi.
Downgrading to 361.42 fixes it.

Ok, it turns out this only happens when I have Samsung magicbright dynamic contrast enabled.
But this was not a problem under the 361.42 driver so it is still a regression in the nvidia xorg driver.
But now at least we know how to reproduce it. Can nvidia now take a look?
Thank you.

#44
Posted 04/11/2016 09:58 PM   
Also disabling Dithering significantly mitigates the problem. Was Dithering always enabled by default?
Also disabling Dithering significantly mitigates the problem.
Was Dithering always enabled by default?

#45
Posted 04/11/2016 10:11 PM   
Scroll To Top

Add Reply