331.49: Optimus offloading graphics display with xrandr 1.4

Hi,

I have an Acer V3-772g optimus based laptop and I’m using the setup described here to use my nvidia graphics card’s (GT 750M) capabilities. Everything works fine but I didn’t manage to work around the following two issues:

  1. The login screen provided by KDM is a 640x480 screen in the upper left corner of the display although the display has the proper 1920x1080 resolution. The rest of the display contains the tiled background of KDM of size 640x480 (approx 3x2 tiles)

I’m running this before starting KDM:

xrandr --setprovideroutputsource modesetting NVIDIA-0
xrandr --auto

I think this is caused by the fact that, because there is not display connected to the nvidia graphics card directly, the virtual screen size is incorrectly set to 640x480. When this screen is offloaded into the intel card it is tilled to fill the 1920x1080 resolution.

[ 10299.683] (II) NVIDIA(0): NVIDIA GPU GeForce GT 750M (GK107) at PCI:1:0:0 (GPU-0)
[ 10299.683] (--) NVIDIA(0): Memory: 4194304 kBytes
[ 10299.683] (--) NVIDIA(0): VideoBIOS: 80.07.a6.00.0d
[ 10299.683] (II) NVIDIA(0): Detected PCI Express Link width: 16X
[ 10299.683] (--) NVIDIA(0): Valid display device(s) on GeForce GT 750M at PCI:1:0:0
[ 10299.683] (--) NVIDIA(0):     none
[ 10299.683] (II) NVIDIA(0): Validated MetaModes:
[ 10299.683] (II) NVIDIA(0):     "NULL"
[ 10299.683] (II) NVIDIA(0): Virtual screen size determined to be 640 x 480

Any ideas what I could to to make the driver set the virtual screen size to 1920x1080? I feel that if I would be able to do this the issue I’m seeing it KDM would be gone.

  1. My second problem is resuming from suspend. It works but it causes artifacts until X is restarted. I’ve read the caveats of this setup but isn’t there something that I could to to reinitialize this graphics offloading mechanism? I would really like to be able to use suspend/resume on my laptop.

Thanks for any help you can provide.
nvidia-bug-report.log.gz (150 KB)

I’ve attached the data generated by nvidia-bug-report.sh

Since it seems that it’s pretty hard to have stable nvidia support on my optimus enabled laptop I switched to using the integrated Intel card. That leaves me without VDPAU but at least suspend/resume works as expected and the login screen has a proper resolution. I guess the joke is on me for thinking of buying a laptop with an nvidia card having expected to have the same support on Linux as the desktop cards.

Now I’m left with an unusable GT 750M with 4GB of memory, real nice.

I’ve used bumblebee without any issues with suspend/resume on my Optimus laptop… I know the optirun syntax is not the ideal solution, but it tends to behave better and has decent power management capabilities vs xrandr offloading.

I would use bumblebee also (I know it’s stable considering the power management) but it doesn’t fit my use case since it only offers OpenGL offloading and I would really need VDPAU. Thats why I was happy with xrandr offloading (it handles VDPAU also) until I saw that I can’t suspend/resume without needing to restart X on each resume.

Now I have a script for switching between two setups before starting X:

  1. Intel integrated card only (can use bumblebee for opengl but I need VDPAU) with intel (or mesa, I’m not sure) opengl libraries; in this setup I can use suspend/resume without problems
  2. Rendering with nvidia discrete card then offloading that into the intel integrated card with nvidia opengl libraries; in this setup I can use VDPAU but I can’t suspend/resume without needing to restart X

I would really prefer any setup that could give me VDPAU and suspend/resume just like on my desktop, without restarting X, which is a pain for a regular user (my wife).

If this is a bug in xrandr at least let me know so I can seek help with it’s developers.

Not giving up on this I found the following patch wich was never applied. I think that this is just what I need to have in xrandr. If I apply this patch after resume I would run:

xrandr --setprovideroutputsource modesetting 0

This would reset the graphics offloading, the I would set it again with this:

xrandr --setprovideroutputsource modesetting NVIDIA-0
xrandr --auto

This could get rid of the artifacts after resume and I could live with the login screen issue for now. I’ll try this later today and report back if it works or not.

Tried the above patch but unfortunately running:

xrandr --setprovideroutputsource modesetting 0

after resume (with the artifacts present) would not reset the graphics offloading (it has no effect at all), maybe a dev can shed some light on what would it take to reset it.

Hi cristianonet,

Thanks for pointing out Dave Airlie’s patch. It does look like it just fell through the cracks. I’ll try to find it in my email client and see about getting it applied.

For KDM, is the problem that the screen is being resized after KDM starts, or is there a 640x480 display device reported by xrandr? On one of my laptops, the NVIDIA device reports a nonexistent CRT-0 display that isn’t actually visible anywhere, with a default resolution of 640x480. If that’s what’s happening, you should be able to fix it by adding “xrandr --output CRT-0 --off” to your startup commands.

If it’s just that KDM is getting confused by the initial size of the desktop, you can control that using the Virtual option in xorg.conf.

The suspend & resume problem has been tracked down and should be fixed in the next release.

I just pushed Dave’s xrandr patch. Some earlier changes to xrandr make decimal numbers be interpreted as index values, so “xrandr --setprovideroutputsource modesetting 0” is the same as “xrandr --setprovideroutputsource modesetting NVIDIA-0” when NVIDIA-0 is provider #0. To actually disconnect it, you’ll need to specify the provider as an XID in hexadecimal:

xrandr --setprovideroutputsource modesetting 0x0

Hi Aaron,

Thanks for your help. I’m confident that the suggestions might fix the problems I have. I wouldn’t have figured out the need for 0x0 by myself. I’m happy to hear that the suspend & resume issue will be fixed in the next release. Until then I can live with this if resetting the xrandr offload does not solve this.

As for the KDM issue it can be seen, by looking at the attached nvidia-bugreport.sh data, that no bogus displays are detected by the nvidia card because no displays are actually connected to the card (optimus laptop) so I guess that the default 640x480 is used. I’ll try if, by using the Virtual option, I can tell nvidia that the virtual screen should be 1920x1080.

Here are the results of your suggestions the Virtual option did solve the problem I was having with KDM. With this in the “nvidia” screen section of xorg.conf

SubSection "Display"
    Virtual 1920 1080 
EndSubSection

I now get this in Xorg.0.log and KDM displays fine on the whole screen

[  3161.437] (II) NVIDIA(0): Validated MetaModes:
[  3161.437] (II) NVIDIA(0):     "NULL"
[  3161.437] (**) NVIDIA(0): Virtual screen size configured to be 1920 x 1080
[  3161.437] (**) NVIDIA(0): DPI set to (96, 96); computed from "DPI" X config option

Which is what I was trying to achieve, thanks.

The suspend problem can’t be solved as I hoped by running

xrandr --setprovideroutputsource modesetting 0x0

after resume. It seems that it does nothing, not even a screen flicker. I expected the screen to go black as before running

xrandr --setprovideroutputsource modesetting NVIDIA-0

but you know better the purpose of the patch. I was hoping it would get me back to the initial state.
Anyway since you’ve said that a fix will be available in the next release I’m happy to live with this for now. Thanks for your help.

Just one more thing: will that fix be in the next stable or in the next beta version?

Today I’ve installed nvidia-drivers-337.12 which fixed the suspend & resume problem. Thank you, I can finally use the nvidia card’s VDPAU capabilities.

Let me point out that Intel GPUs offer video acceleration via VA-API (libva); using video players that know about VDPAU but not VA-API (such as Flash) should be possible with libvdpau-va-gl.

I.e. unless you need some nvidia-specific capabilities, you don’t need xrandr offloading for vdpau; decoding video on intel gpu would be more energy efficient comparing to decoding on nvidia and then moving the decoded picture across pci-express.

Are you sure about that? Does the video decoding performance of the intel card matches that of the nvidia card? I saw lower CPU usage while playing 1080p video using nvidia with xrandr offloading than intel with vaapi.

Since the laptop is mostly plugged in I don’t really care that much about battery usage.

What player were you using? VLC does not use vaapi efficiently; mpv does.