The delay phenomenon is serious in 'External display mode' during the 'On-demand' mode working

@Alberto,

 Now I used 'ubuntu-drivers install' to install nvidia driver, it set 'on-demand' by default, but it won't work for 'External display mode', it works fine when I changed 'on-demand' to 'Perfomance' mode. Could you help check if it's the nvidia's bug. Thanks!

Did you restart the system after installing the driver and setting it to on-demand?

I tested on a ThinkPad P1 Gen 4, GPU is RTX A5000, with nvidia driver 470, this issue exists after restarting the system.

When I switched the mode, it will take effects after reboot.

IIRC, this issue could be reproduced when
1) 5.10 + nvidia 460
2) 5.10 + nvidia 470
3) 5.13 + nvidia 460
4) 5.13 + nvidia 470

For (1), this case is a common case in each OEM project.

The one of difference between OEM projects on external ports is MUX, before dig with ACPI. Could we please try.

1) Remove "/usr/share/X11/xorg.conf.d/11-nvidia-offload.conf"
1.1) after 1), check issue exist or not.
1.2) after 1), add /usr/share/X11/xorg.conf.d/11-nvidia-prime.conf
```
# Test for LP: #1940247
Section "OutputClass"
    Identifier "Nvidia Prime"
    MatchDriver "nvidia-drm"
    Driver "nvidia"
    Option "AllowEmptyInitialConfiguration"
    Option "IgnoreDisplayDevices" "CRT"
    Option "PrimaryGPU" "Yes"
    ModulePath "/lib/%s/nvidia/xorg"
EndSection
```
If all (1) could reproduce this issue, then
2) comment out the content of `/lib/modprobe.d/nvidia-runtimepm.conf` and then re-generated initramfs.

To clarify it's nvidia or X related?

@jeremyszu,

 Thanks for your idea, but all (1) and (2) could not work.

I tried to install NVIDIA-Linux-x86_64-470.57.02.run on system, it will use 'on-demand' mode by default, and I still could reproduce this issue.

@Bin,

Sorry about typo of comment#6.
Could you please help to try

# Test for LP: #1940247
Section "OutputClass"
    Identifier "Nvidia Prime"
    MatchDriver "nvidia-drm"
    Driver "nvidia"
    Option "AllowEmptyInitialConfiguration"
    Option "IgnoreDisplayDevices" "CRT"
    Option "PrimaryGPU" "Yes"
    ModulePath "/lib/x86_64-linux-gnu/nvidia/xorg/"
EndSection

@jeremyszu,

 I tried the #9 again, it didn't help, thanks!

 1) removed "/usr/share/X11/xorg.conf.d/11-nvidia-offload.conf"
 2) add new /usr/share/X11/xorg.conf.d/11-nvidia-prime.conf

@alberto,

 Do you have any idea about this issue? Thanks!

On ThinkPad P1 Gen 3, I installed NVIDIA-Linux-x86_64-470.63.01.run, when I switch to external only, I could reproduce this issue.

It used Intel for redener, and nvidia for output by default.

$ glxgears -info
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
GL_RENDERER = Mesa Intel(R) UHD Graphics P630 (CML GT2)
GL_VERSION = 4.6 (Compatibility Profile) Mesa 21.0.3
GL_VENDOR = Intel

Nvidia bug #3374575 has been submitted.

NV update for NV#3374575:
Hi Kevin - This is an expected issue for all drivers with the currently shipping X server (1.20.9 in the bug report): https://gitlab.freedesktop.org/xorg/xserver/-/issues/1028 . https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1875015 .

The issue is that X Present doesn't support synchronizing to PRIME heads. When the external display (via Reverse PRIME) is the only head left, X Present vsync apps have nothing to sync to and throttle to 1 FPS by default. The only solution right now is to disable vsync, try adding a .sh script in /etc/profile.d with the following contents:
export CLUTTER_VBLANK=none
export vblank_mode=0

That should fix the 1 FPS issue but obviously you won't have vsync. If the system is muxed such that external displays are connected to the iGPU in this configuration, you won't have the problem.

Thanks and hope this helps, THX

NV update:
we will process your engineer's comment accordingly but to unblock current situation is to go with the recommended WAR (vsync disablement) as short term solution. THX

@haosheng.lu,

 Thanks for your updates. I will confirm with Lenovo if we need the workaround or just wait updates.

Currently we used 5.14.0-oem kernel with 495.46, this issue is fixed.