PRIME and PRIME Synchronization
[quote="OdelPasso"]@agoins : I expect that you're looking about my issue too and don't forget me. To have 2 cursors and to have a system which is slow comparing to a system without PRIME (2 minutes to load Wasteland 2 with PRIME and 10s without PRIME)[/quote] Yes, I have your bug reproducing locally and am currently looking into addressing it. It's in our bug tracker and a high priority item. [quote="TimRichardson"]I have an old Thinkpad W520 (quadcore i7 with a 1000M card). Ubuntu 17.04 (64 bit) with xserver 19.2 once again, prime sync default to 0 but on this machine xrandr --output LVDS-1-1 --set "PRIME Synchronization" 1 works as confirmed by xrandr --verbose but there is still screen tearing. [/quote] Strange. Could you please provide an nvidia-bug-report.log.gz (running nvidia-bug-report.sh)? A video of the tearing you are seeing would also be helpful if possible, because the tearing that results from unsynchronized PRIME is pretty characteristic. Does Xorg print "randr: Falling back to unsynchronized pixmap sharing" when you set a mode on the PRIME display? Thanks,
OdelPasso said:@agoins : I expect that you're looking about my issue too and don't forget me. To have 2 cursors and to have a system which is slow comparing to a system without PRIME (2 minutes to load Wasteland 2 with PRIME and 10s without PRIME)

Yes, I have your bug reproducing locally and am currently looking into addressing it. It's in our bug tracker and a high priority item.


TimRichardson said:I have an old Thinkpad W520 (quadcore i7 with a 1000M card). Ubuntu 17.04 (64 bit) with xserver 19.2
once again, prime sync default to 0 but on this machine
xrandr --output LVDS-1-1 --set "PRIME Synchronization" 1

works as confirmed by xrandr --verbose
but there is still screen tearing.

Strange. Could you please provide an nvidia-bug-report.log.gz (running nvidia-bug-report.sh)? A video of the tearing you are seeing would also be helpful if possible, because the tearing that results from unsynchronized PRIME is pretty characteristic.

Does Xorg print "randr: Falling back to unsynchronized pixmap sharing" when you set a mode on the PRIME display?

Thanks,

Alex Goins
NVIDIA Linux Graphics

Posted 03/14/2017 06:16 PM   
Update: attachment. Actually, Prime Sync will not set to 1 on my machine so I don't have evidence that it's not working. I just can't activate it. I don't know why, I can't see what's wrong with my setup. [code]tim@tim-ThinkPad-P50:/etc/modprobe.d$ sudo modprobe -v nvidia-drm insmod /lib/modules/4.10.0-11-generic/updates/dkms/nvidia_375.ko insmod /lib/modules/4.10.0-11-generic/updates/dkms/nvidia_375_modeset.ko insmod /lib/modules/4.10.0-11-generic/updates/dkms/nvidia_375_drm.ko modeset=1 javascript:void(); tim@tim-ThinkPad-P50:/etc/modprobe.d$ [/code] [code]tim@tim-ThinkPad-P50:/etc/modprobe.d$ xrandr --verbose | grep PRIME PRIME Synchronization: 0 tim@tim-ThinkPad-P50:/etc/modprobe.d$ xrandr --output eDP-1-1 --set 'PRIME Synchronization' 1 tim@tim-ThinkPad-P50:/etc/modprobe.d$ xrandr --verbose | grep PRIME PRIME Synchronization: 0 tim@tim-ThinkPad-P50:/etc/modprobe.d$ [/code] Note: the screen flashes black and on again when doing the set. It report no error. I just assumed it worked. [code]tim@tim-ThinkPad-P50:/etc/modprobe.d$ Xorg -version X.Org X Server 1.19.2 Release Date: 2017-03-02 X Protocol Version 11, Revision 0 Build Operating System: Linux 4.4.0-66-generic x86_64 Ubuntu Current Operating System: Linux tim-ThinkPad-P50 4.10.0-11-generic #13-Ubuntu SMP Wed Mar 1 21:27:28 UTC 2017 x86_64 Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.10.0-11-generic.efi.signed root=UUID=f7c4e1a0-3d0d-4c66-9051-664f8e78b0ef ro quiet splash Build Date: 11 March 2017 08:39:52AM xorg-server 2:1.19.2-1ubuntu2 (For technical support please see http://www.ubuntu.com/support) Current version of pixman: 0.34.0 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. tim@tim-ThinkPad-P50:/etc/modprobe.d$ [/code]
Update: attachment.

Actually, Prime Sync will not set to 1 on my machine so I don't have evidence that it's not working. I just can't activate it. I don't know why, I can't see what's wrong with my setup.

tim@tim-ThinkPad-P50:/etc/modprobe.d$ sudo modprobe -v nvidia-drm
insmod /lib/modules/4.10.0-11-generic/updates/dkms/nvidia_375.ko
insmod /lib/modules/4.10.0-11-generic/updates/dkms/nvidia_375_modeset.ko
insmod /lib/modules/4.10.0-11-generic/updates/dkms/nvidia_375_drm.ko modeset=1 javascript:void();
tim@tim-ThinkPad-P50:/etc/modprobe.d$



tim@tim-ThinkPad-P50:/etc/modprobe.d$ xrandr --verbose | grep PRIME
PRIME Synchronization: 0
tim@tim-ThinkPad-P50:/etc/modprobe.d$ xrandr --output eDP-1-1 --set 'PRIME Synchronization' 1
tim@tim-ThinkPad-P50:/etc/modprobe.d$ xrandr --verbose | grep PRIME PRIME Synchronization: 0
tim@tim-ThinkPad-P50:/etc/modprobe.d$


Note: the screen flashes black and on again when doing the set. It report no error. I just assumed it worked.

tim@tim-ThinkPad-P50:/etc/modprobe.d$ Xorg -version

X.Org X Server 1.19.2
Release Date: 2017-03-02
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.4.0-66-generic x86_64 Ubuntu
Current Operating System: Linux tim-ThinkPad-P50 4.10.0-11-generic #13-Ubuntu SMP Wed Mar 1 21:27:28 UTC 2017 x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.10.0-11-generic.efi.signed root=UUID=f7c4e1a0-3d0d-4c66-9051-664f8e78b0ef ro quiet splash
Build Date: 11 March 2017 08:39:52AM
xorg-server 2:1.19.2-1ubuntu2 (For technical support please see http://www.ubuntu.com/support)
Current version of pixman: 0.34.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
tim@tim-ThinkPad-P50:/etc/modprobe.d$

Posted 03/14/2017 09:30 PM   
Yeah, looking through the logs in nvidia-bug-report.log.gz, nothing stands out to me as being set up incorrectly. DRM is loading with modeset=1 and the dmesg logs confirm that it actually took effect, and all of your drivers and xorg.conf look right. However, in Xorg.0.log, there are many of the "randr: Falling back to unsynchronized pixmap sharing" messages. This means that in xserver/randr/rrcrtc.c:rrSetupPixmapSharing() [[url]https://cgit.freedesktop.org/xorg/xserver/tree/randr/rrcrtc.c[/url]] one of the components is failing. Unfortunately, it isn't verbose with respect to what actually failed. If any part of setting up PRIME Sync fails, it will automatically print that message, set the "PRIME Synchronization" output property to 0, and then attempt to set up PRIME without sync as a fallback. It could have either failed due to the ABI functions not being defined, or via a failure in any of rrCreateSharedPixmap()/rrEnableSharedPixmapFlipping()/rrStartFlippingPixmapTracking(). If nvidia-drm is loaded with modeset=1, and you're using the modesetting driver, all the ABI functions should be defined. One of the latter two functions is mostly likely to the culprit. If I had the bug reproducing in front of me, I would step through rrSetPixmapSharing() to see what failed. Actually, where did you get your Xorg 1.19.2? From the logs, it looks like it was built for a package in Ubuntu 17.04 (development branch), but on Launchpad for Zesty they are still on 1.18.4. Canonical applies their own patches to their X server/driver builds, and it's possible that the modesetting driver was patched to a version that fails rrEnableSharedPixmapFlipping(); perhaps a developer ran into a problem with PRIME Sync and decided to disable it unconditionally. I can already tell that some patches are being applied, because your PRIME display doesn't have rotation. Canonical patched the X server to disable rotation for PRIME displays unconditionally, although the NVIDIA driver has since come to support rotation with PRIME. Thanks,
Yeah, looking through the logs in nvidia-bug-report.log.gz, nothing stands out to me as being set up incorrectly. DRM is loading with modeset=1 and the dmesg logs confirm that it actually took effect, and all of your drivers and xorg.conf look right.

However, in Xorg.0.log, there are many of the "randr: Falling back to unsynchronized pixmap sharing" messages. This means that in xserver/randr/rrcrtc.c:rrSetupPixmapSharing() [https://cgit.freedesktop.org/xorg/xserver/tree/randr/rrcrtc.c] one of the components is failing. Unfortunately, it isn't verbose with respect to what actually failed. If any part of setting up PRIME Sync fails, it will automatically print that message, set the "PRIME Synchronization" output property to 0, and then attempt to set up PRIME without sync as a fallback.

It could have either failed due to the ABI functions not being defined, or via a failure in any of rrCreateSharedPixmap()/rrEnableSharedPixmapFlipping()/rrStartFlippingPixmapTracking(). If nvidia-drm is loaded with modeset=1, and you're using the modesetting driver, all the ABI functions should be defined. One of the latter two functions is mostly likely to the culprit. If I had the bug reproducing in front of me, I would step through rrSetPixmapSharing() to see what failed.

Actually, where did you get your Xorg 1.19.2? From the logs, it looks like it was built for a package in Ubuntu 17.04 (development branch), but on Launchpad for Zesty they are still on 1.18.4. Canonical applies their own patches to their X server/driver builds, and it's possible that the modesetting driver was patched to a version that fails rrEnableSharedPixmapFlipping(); perhaps a developer ran into a problem with PRIME Sync and decided to disable it unconditionally. I can already tell that some patches are being applied, because your PRIME display doesn't have rotation. Canonical patched the X server to disable rotation for PRIME displays unconditionally, although the NVIDIA driver has since come to support rotation with PRIME.

Thanks,

Alex Goins
NVIDIA Linux Graphics

Posted 03/15/2017 12:32 AM   
Hi Alex, the 19.2 build comes from a staging repository ...in preparation for release into 17.04 mainline. In other words, this is what17.04 will get, and then some months later it will be included to the LTS release 16.04.3. I don't know how to report bugs on that PPA (repository) so I emailed a general address, because it would be a crying shame if it doesn't work in Ubuntu 17.04 & 16.04 LTS after all the work which has been done. https://launchpad.net/~canonical-x
Hi Alex, the 19.2 build comes from a staging repository ...in preparation for release into 17.04 mainline. In other words, this is what17.04 will get, and then some months later it will be included to the LTS release 16.04.3. I don't know how to report bugs on that PPA (repository) so I emailed a general address, because it would be a crying shame if it doesn't work in Ubuntu 17.04 & 16.04 LTS after all the work which has been done.


https://launchpad.net/~canonical-x

Posted 03/15/2017 01:00 AM   
I just looked through the patches included with that package, and tried testing with the package on my machine. I didn't see any patches that would do that, and didn't see the bug when testing. It must be something else...
I just looked through the patches included with that package, and tried testing with the package on my machine. I didn't see any patches that would do that, and didn't see the bug when testing. It must be something else...

Alex Goins
NVIDIA Linux Graphics

Posted 03/15/2017 01:58 AM   
HI Alex, I will help in any way. I assume I have this problem in both of my Thinkpads, the P50 and the older W520 with a 1000M card. I'll get a debug log from the W520 too just in case it throws something up.
HI Alex, I will help in any way. I assume I have this problem in both of my Thinkpads, the P50 and the older W520 with a 1000M card. I'll get a debug log from the W520 too just in case it throws something up.

Posted 03/15/2017 02:33 AM   
[quote="TimRichardson"]HI Alex, I will help in any way. I assume I have this problem in both of my Thinkpads, the P50 and the older W520 with a 1000M card. I'll get a debug log from the W520 too just in case it throws something up. [/quote] Much appreciated. I wouldn't assume that the other machine will reproduce it; we have yet to see the problem here. However, if you do find that it reproduces with the exact same software setup on the other hardware, it sounds like it would be worthwhile for me to replicate your installation and see if I can reproduce it myself. Thanks,
TimRichardson said:HI Alex, I will help in any way. I assume I have this problem in both of my Thinkpads, the P50 and the older W520 with a 1000M card. I'll get a debug log from the W520 too just in case it throws something up.

Much appreciated. I wouldn't assume that the other machine will reproduce it; we have yet to see the problem here. However, if you do find that it reproduces with the exact same software setup on the other hardware, it sounds like it would be worthwhile for me to replicate your installation and see if I can reproduce it myself.

Thanks,

Alex Goins
NVIDIA Linux Graphics

Posted 03/15/2017 02:38 AM   
On the W520 I also can't set PRIME Sync to 1. However, xrandr --verbose does report PRIME Sync=1 for a non-existing display The nvidia debug log will be attached here [code]xrandr --output LVDS-1-1 --set "PRIME Synchronization" 1[/code] [code]tim@tim-ThinkPad-W520:~$ xrandr --verbose | grep -B25 PRIME ConnectorType: DisplayPort ConnectorNumber: 4 _ConnectorLocation: 4 LVDS-1-1 connected primary 1920x1080+0+0 (0x44) normal (normal) 344mm x 193mm Identifier: 0x41 Timestamp: 159414 Subpixel: horizontal rgb Gamma: 1.0:1.0:1.0 Brightness: 1.0 Clones: CRTC: 0 CRTCs: 0 3 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: EDID: 00ffffffffffff0030aeb24000000000 0113010380221378ea2135ad5037aa24 11505400000001010101010101010101 0101010101014c368082703832403c30 aa0058c1100000183f2d808270383240 3c30aa0058c1100000180000000f00d1 0932d109281b190006af5634000000fe 004231353648573031205634200a00d6 PRIME Synchronization: 0 -- 576x432 (0x65) 40.810MHz -HSync +VSync DoubleScan h: width 576 start 608 end 668 total 760 skew 0 clock 53.70KHz v: height 432 start 432 end 434 total 447 clock 60.06Hz 512x384 (0x66) 32.500MHz -HSync -VSync DoubleScan h: width 512 start 524 end 592 total 672 skew 0 clock 48.36KHz v: height 384 start 385 end 388 total 403 clock 60.00Hz 400x300 (0x67) 20.000MHz +HSync +VSync DoubleScan h: width 400 start 420 end 484 total 528 skew 0 clock 37.88KHz v: height 300 start 300 end 302 total 314 clock 60.32Hz 400x300 (0x68) 18.000MHz +HSync +VSync DoubleScan h: width 400 start 412 end 448 total 512 skew 0 clock 35.16KHz v: height 300 start 300 end 301 total 312 clock 56.34Hz 320x240 (0x69) 12.587MHz -HSync -VSync DoubleScan h: width 320 start 328 end 376 total 400 skew 0 clock 31.47KHz v: height 240 start 245 end 246 total 262 clock 60.05Hz VGA-1-1 disconnected (normal) Identifier: 0x42 Timestamp: 159414 Subpixel: unknown Clones: CRTCs: 0 3 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: PRIME Synchronization: 1 [/code]
On the W520 I also can't set PRIME Sync to 1. However, xrandr --verbose does report PRIME Sync=1 for a non-existing display

The nvidia debug log will be attached here

xrandr --output LVDS-1-1 --set "PRIME Synchronization" 1




tim@tim-ThinkPad-W520:~$ xrandr --verbose | grep -B25 PRIME
ConnectorType: DisplayPort
ConnectorNumber: 4
_ConnectorLocation: 4
LVDS-1-1 connected primary 1920x1080+0+0 (0x44) normal (normal) 344mm x 193mm
Identifier: 0x41
Timestamp: 159414
Subpixel: horizontal rgb
Gamma: 1.0:1.0:1.0
Brightness: 1.0
Clones:
CRTC: 0
CRTCs: 0 3
Transform: 1.000000 0.000000 0.000000
0.000000 1.000000 0.000000
0.000000 0.000000 1.000000
filter:
EDID:
00ffffffffffff0030aeb24000000000
0113010380221378ea2135ad5037aa24
11505400000001010101010101010101
0101010101014c368082703832403c30
aa0058c1100000183f2d808270383240
3c30aa0058c1100000180000000f00d1
0932d109281b190006af5634000000fe
004231353648573031205634200a00d6
PRIME Synchronization: 0
--
576x432 (0x65) 40.810MHz -HSync +VSync DoubleScan
h: width 576 start 608 end 668 total 760 skew 0 clock 53.70KHz
v: height 432 start 432 end 434 total 447 clock 60.06Hz
512x384 (0x66) 32.500MHz -HSync -VSync DoubleScan
h: width 512 start 524 end 592 total 672 skew 0 clock 48.36KHz
v: height 384 start 385 end 388 total 403 clock 60.00Hz
400x300 (0x67) 20.000MHz +HSync +VSync DoubleScan
h: width 400 start 420 end 484 total 528 skew 0 clock 37.88KHz
v: height 300 start 300 end 302 total 314 clock 60.32Hz
400x300 (0x68) 18.000MHz +HSync +VSync DoubleScan
h: width 400 start 412 end 448 total 512 skew 0 clock 35.16KHz
v: height 300 start 300 end 301 total 312 clock 56.34Hz
320x240 (0x69) 12.587MHz -HSync -VSync DoubleScan
h: width 320 start 328 end 376 total 400 skew 0 clock 31.47KHz
v: height 240 start 245 end 246 total 262 clock 60.05Hz
VGA-1-1 disconnected (normal)
Identifier: 0x42
Timestamp: 159414
Subpixel: unknown
Clones:
CRTCs: 0 3
Transform: 1.000000 0.000000 0.000000
0.000000 1.000000 0.000000
0.000000 0.000000 1.000000
filter:
PRIME Synchronization: 1

Posted 03/15/2017 02:57 AM   
EDIT: I can't attach a debug file here. The forum gives an error that this thread has exceeded its maximum allowed size ( so until that's fixed, no more log files I guess). try this: https://drive.google.com/file/d/0B6R0mGl6gkD1NkpJTnExUzBMVk0/view?usp=sharing The Ubuntu developer made some changes: [code]Anyway, here's a newer version with two patches dropped (once it has finished building): https://launchpad.net/~tjaalton/+archive/ubuntu/test/+packages there's still one patch left that is actually created by a NVIDIA dev.. but let me know how this version does.[/code] but on the ThinkPad W520 (1000M), there is no change
EDIT: I can't attach a debug file here. The forum gives an error that this thread has exceeded its maximum allowed size ( so until that's fixed, no more log files I guess).

try this: https://drive.google.com/file/d/0B6R0mGl6gkD1NkpJTnExUzBMVk0/view?usp=sharing

The Ubuntu developer made some changes:


Anyway, here's a newer version with two patches dropped (once it has
finished building):

https://launchpad.net/~tjaalton/+archive/ubuntu/test/+packages

there's still one patch left that is actually created by a NVIDIA dev..
but let me know how this version does.


but on the ThinkPad W520 (1000M), there is no change

Posted 03/15/2017 09:38 PM   
@TimRichardson: I cannot get any machine I have to cooperate Prime Sync with kernel 4.10. The only time Prime Sync works is when I'm using kernel 4.9. Have you tested 4.9 on your configuration?
@TimRichardson:

I cannot get any machine I have to cooperate Prime Sync with kernel 4.10. The only time Prime Sync works is when I'm using kernel 4.9. Have you tested 4.9 on your configuration?

Posted 03/15/2017 11:29 PM   
Hi Ryan, I will see if there is a 4.9 kernel in Ubuntu 17.04 but I doubt it; the distribution is definitely preparing 4.10 for the release.
Hi Ryan, I will see if there is a 4.9 kernel in Ubuntu 17.04 but I doubt it; the distribution is definitely preparing 4.10 for the release.

Posted 03/16/2017 04:13 AM   
Hi, Which is the difference between the xorg.conf used in this topic and the specific Xorg.conf used by Fedora and Archlinux ? These both OS use glvnd for Mesa and Nvidia driver so it's an other approach for optimus on Linux ? "nvidia-drm.modeset=1" is stil necessary in grub.conf ? Same thing for AccelMethod=none for Intel driver on the Xorg.conf ? Thaïs for tour answer
Hi,

Which is the difference between the xorg.conf used in this topic and the specific Xorg.conf used by Fedora and Archlinux ?
These both OS use glvnd for Mesa and Nvidia driver so it's an other approach for optimus on Linux ?
"nvidia-drm.modeset=1" is stil necessary in grub.conf ?
Same thing for AccelMethod=none for Intel driver on the Xorg.conf ?

Thaïs for tour answer

Posted 03/16/2017 09:08 AM   
@OdelPasso: By default, most distributions do not create an Xorg.conf because it is automatically generated at boot time. However, for configuration of Prime Sync it is required to set these specific settings to have a working setup. You ask if it's necessary to have this set, try both with and without and see what[code] xrandr --verbose [/code] shows you on output.
@OdelPasso:

By default, most distributions do not create an Xorg.conf because it is automatically generated at boot time. However, for configuration of Prime Sync it is required to set these specific settings to have a working setup.

You ask if it's necessary to have this set, try both with and without and see what
xrandr --verbose

shows you on output.

Posted 03/19/2017 04:23 AM   
Is Ryan correct that [code]xrandr --output LVDS-1-1 --set "PRIME Synchronization" 1[/code] doesn't work with kernel 4.10 ?
Is Ryan correct that
xrandr --output LVDS-1-1 --set "PRIME Synchronization" 1


doesn't work with kernel 4.10 ?

Posted 03/21/2017 06:24 AM   
@TimRichardson Depends on how you define "working". It will somewhat function as a setting but with sporadic and continuous [code]BUG: scheduling while atomic: kworker[/code] errors flooding your logs. So, if someone was stuck with only one machine and needed vsync to work, it's an option. But, for a reliable and stable machine, it is definitely not "working" with kernel 4.10.
@TimRichardson

Depends on how you define "working". It will somewhat function as a setting but with sporadic and continuous
BUG: scheduling while atomic: kworker
errors flooding your logs. So, if someone was stuck with only one machine and needed vsync to work, it's an option. But, for a reliable and stable machine, it is definitely not "working" with kernel 4.10.

Posted 03/24/2017 12:13 AM   
Scroll To Top

Add Reply