Very low AppVM refresh rate on high resolution monitor setups

Yethal commented 6 years ago

Qubes OS version (e.g., `R3.2`):

3.2

Affected TemplateVMs (e.g., `fedora-23`, if applicable):

All of them (tested on fedora-23, fedora-25, debian-8)

Steps to reproduce the behavior:

Launch terminal in templateVM
Open /etc/X11/xorg-qubes.conf file
Search for refresh rate

Expected behavior:

Refresh rate in the config file is equal to maximum supported refresh rate of the monitor (60hz)

Actual behavior:

Refresh rate is 24hz

General notes:

Changing the refresh rate manually to 60hz and restarting all vms caused the entire GUI to become more responsive. No idea why 24hz is used by default.

Related issues:

marmarek commented 6 years ago

That's interesting - there should be a range, not a single value. Also the thing that is set to "24" is color depth, not refresh rate. The later is calculated dynamically based on your screen resolution and available clock speed (see /usr/bin/qubes-run-xorg.sh). Can you post here xorg-qubes.conf before and after the change?

Yethal commented 6 years ago

Before

`Section "ServerLayout"   
        Identifier     "Default Layout"
        Screen      0  "Screen0" 0 0  
        InputDevice "qubesdev"
EndSection

Section "Device"
        Identifier  "Videocard0"
        Driver      "dummyqbs"
    VideoRam 65536
EndSection

Section "Monitor"
        Identifier "Monitor0"
        HorizSync 49-50
    VertRefresh 23-24
    Modeline "QB1920x2160" 96 1920 1921 1922 1923 2160 2161 2162 2163 
EndSection

Section "Screen"
        Identifier "Screen0"
        Device     "Videocard0"
    Monitor    "Monitor0"
        DefaultDepth     24
        SubSection "Display"
                Viewport   0 0
                Depth     24 
        Modes "QB1920x2160" 
        EndSubSection
EndSection

Section "InputDevice"
        Identifier  "qubesdev"
        Driver      "qubes"
EndSection`

After

`Section "ServerLayout"   
        Identifier     "Default Layout"
        Screen      0  "Screen0" 0 0  
        InputDevice "qubesdev"
EndSection

Section "Device"
        Identifier  "Videocard0"
        Driver      "dummyqbs"
    VideoRam 65536
EndSection

Section "Monitor"
        Identifier "Monitor0"
        HorizSync 49-50
    VertRefresh 59-60
    Modeline "QB1920x2160" 96 1920 1921 1922 1923 2160 2161 2162 2163 
EndSection

Section "Screen"
        Identifier "Screen0"
        Device     "Videocard0"
    Monitor    "Monitor0"
        DefaultDepth     24
        SubSection "Display"
                Viewport   0 0
                Depth     24 
        Modes "QB1920x2160" 
        EndSubSection
EndSection

Section "InputDevice"
        Identifier  "qubesdev"
        Driver      "qubes"
EndSection`

The only value I changed was VertRefresh from 23-24 to 59-60

0spinboson commented 6 years ago

Thanks for noticing -- definitely makes for a better UX :)

marmarek commented 6 years ago

Ok, but you know that /etc/X11/xorg-qubes.conf is regenerated (from /etc/X11/xorg-qubes.conf.template) before each X server startup, right?

Yethal commented 6 years ago

I assumed as much. Which would imply that the %VREFR_START% and %VREFR_END% variables are improperly calculated by qubes-run-xorg.sh script. THe only thing that comes to my mind is that the script may take into account refresh rate at max resolution supported by the GPU (my GPU uses HDMI 1.4 so 24hz at 4K is max) instead of the refresh rate at the resolution actually used by the screen (which is 60hz). That would explain the 24hz refresh rate.

0spinboson commented 6 years ago

Mine was also set at 23-24hz, while that GPU supports both 2160p30hz over hdmi, and 2160p60 over DP.

Yethal commented 6 years ago

Does it support 2880p24 over dp?

0spinboson commented 6 years ago

Not that card, no. (HD 7750)

Yethal commented 6 years ago

Out of ideas then. I'll probably hardcode this value in the template until a better solution comes up.

0spinboson commented 6 years ago

So I'm also out of ideas, though at a much more elementary level, because I'm much more hopeless. Why, when I set 'VREFR_START=59', does the template become unaccessible in any way (including xl console), even though it boots fine, after the first shutdown?

marmarek commented 6 years ago

So I'm also out of ideas, though at a much more elementary level, because I'm much more hopeless. Why, when I set 'VREFR_START=59', does the template become unaccessible in any way (including xl console), even though it boots fine, after the first shutdown?

R4.0? If so, remember to add -t pv option to xl console. Then, you can check why GUI haven't started.

0spinboson commented 6 years ago

Okay. vrefresh out of range. / dummyqbs no valid modes found. Xorg.0.txt

Edit: I've also tried 39-40Hz and 29-30Hz, both lead to the same issue. Could this have something to do with bandwidth limitations of some sort?

marmarek commented 6 years ago

Try setting some wide range and see what value will actually be used.

0spinboson commented 6 years ago

When I set the range to 0-60 and boot, ~/.local/share/xorg/Xorg.0.log tells me that it's running at 3840*2160 at 23.1Hz vertical refresh rate.

tonsimple commented 6 years ago

Okay, I've been poking around due to my own weird dual-headed refresh rate / vsync woes (https://github.com/QubesOS/qubes-issues/issues/3194) , and even with both monitors set to refresh rate of 60 HZ (in the main Dom0 display settings menu) /etc/X11/xorg-qubes.conf inside VMs reads:

Section "Monitor" Identifier "Monitor0" HorizSync 49-50 VertRefresh 46-47 Modeline "QB3840x1080" 192 3840 3841 3842 3843 1080 1081 1082 1083 EndSection

Weird. Shouldn't it allow for at least 60 HZ, given that minimum supported monitor refresh rate is 60 HZ?

0spinboson commented 6 years ago

That's certainly suggestive of a bandwidth issue of some sort -- looks like it's exactly double the refresh rate, at half the pixels.

tonsimple commented 6 years ago

@0spinboson yep, and trying to hardcode it in the /etc/X11/xorg-qubes.conf.template prevents the GUI from working (qubes 3.2), presumably to same "out of range" shtick.

The system tested on is running a monitor at 144 HZ (displayport) and another at 60 HZ via HDMI (it's a dual head config) so it should "handle" at least 60 HZ

Very weird.

Yethal commented 6 years ago

Quote from qubes-run-xorg.sh script: DUMMY_MAX_CLOCK=300 #hardcoded in dummy_drv

Is this the root cause here?

0spinboson commented 6 years ago

for you, possibly. For me, it was that the preferred_hsync was set too low for my screen size / refresh rate. When I increase that to 134kHz, it supports 36.1Hz vertical, which is the upper limit allowed by that dummy_max_clock=300 setting. I don't know why that exists, though. Is it to protect the (graphics card) memory against flooding (when running multiple VMs?)?

marmarek commented 6 years ago

I think this is technical limitation of dummy driver used in the VM, without any apparent reason (other than no one have implemented support for other values). Tracking from where it came, leads to initial commit of dummy driver back in 2003.

There is an upstream commit from 2015 making it configurable, I'll port it to our driver. For now, you can switch "dummyqbs" to "dummy" driver in xorg-qubes.conf.template to test it. You'll loose xrandr support, but you'll get configurable clock speed.

Yethal commented 6 years ago

Switching driver to dummy caused qubes-run-xorg to write VertRefresh 0-1 to xorg-qubes.conf

andrewdavidwong commented 5 years ago

This issue is being closed because:

This issue has the "Release 3.2 updates" milestone.
Qubes OS 3.2 recently reached end-of-life (EOL).
This issue has not been updated in over a year.

If anyone believes that this issue should be reopened, please let us know in a comment here.

0spinboson commented 5 years ago

it also applies to r4.0. :)

brendanhoar commented 5 years ago

Thinkpad W520, running 4.01 current-testing in dom0 and templates, up to date as of yesterday. snippet of xrandr output below: dom0: 1920x1080 60.00+ 50.00 deb9: QB1920x1080 46.10+ fed29: QB1920x1080 46.10*+

Would the non-matching refresh rates between the hardware in the display VM (dom0) and the dummy driver(s) in all other VMs impact video playback usability in Qubes?

B

0spinboson commented 5 years ago

Slightly, but not that badly, I'd guess. It's mostly at higher resolutions (esp. 4k) that this becomes a real issue, as it can't even manage 30hz then. (But imo it's more of a nuisance while browsing/scrolling than while playing back video.)

0spinboson commented 4 years ago

The title of this issue should probably be changed to "very low AppVM refresh rate on high resolution monitor setups" or something, as it's not that the refresh rate defaults to 24hz above a certain resolution. It depends on the total available pixel real estate (e.g. with a single 4k monitor it's 23hz, with a dual 4k monitor setup, vertical refresh goes down to 18hz).

andrewdavidwong commented 4 years ago

The title of this issue should probably be changed to "very low AppVM refresh rate on high resolution monitor setups" or something, as it's not that the refresh rate defaults to 24hz above a certain resolution. It depends on the total available pixel real estate (e.g. with a single 4k monitor it's 23hz, with a dual 4k monitor setup, vertical refresh goes down to 18hz).

Updated, thanks.

Yethal commented 4 years ago

I'd argue the "high-resolution" part considering even 2x1080p displays (so half of a 4k display) is enough to bring down the refresh rate to 24hz but otherwise yes, that title makes much more sense.

andrewdavidwong commented 4 years ago

I'd argue the "high-resolution" part considering even 2x1080p displays (so half of a 4k display) is enough to bring down the refresh rate to 24hz but otherwise yes, that title makes much more sense.

Well, "high" is relative. Even 720p is enough to count as "high definition." I'm not aware of an official definition of "high resolution."

amreddys commented 4 years ago

I found where the clock limits are and I modified them but I couldn't compile it back for 4.0. I always get PyYAML is not found but it compiles fine with 4.1. I do not have a dev machine so I cannot install 4.1 on my primary machine.

Can anyone test and confirm whether it works?

Line 559 in https://github.com/QubesOS/qubes-gui-agent-linux/blob/master/xf86-video-dummy/src/dummy_driver.c#L559 Change the value from 300000 to 1000000

and Line 28 in https://github.com/QubesOS/qubes-gui-agent-linux/blob/master/appvm-scripts/usrbin/qubes-run-xorg#L28 Change the max value to 1000 and modify the preferred_hsync to something that gets calculated based on vertical refresh rate

dylangerdaly commented 4 years ago

I'm getting really, really terrible refresh rate on 4.1 with a 5K screen, I can confirm 4.0.3 was smooth as butter on the same machine.

So I'm not sure what the matter is, any/all electron apps are really, really, really slow.

0spinboson commented 4 years ago

if using amd, try installing xorg-x11-drivers-amdgpu in dom0? That said, electron apps (like Franz 5.5) are very slow for me, too.

timdiels commented 3 years ago

Swapping dummyqbs for dummy as workaround no longer works as Xorg log says it can't load the 'dummy' module.

To try this out, do I understand correctly I'd have to build a qubes installer with those changes (I already have a qubes dev VM) and install that (on a different hard drive)?

timdiels commented 3 years ago

I've tried a modeline with reduced blanking at a clock < 300. dummyqbs reports in Xorg log Not using mode ... (monitor doesn't support reduced blanking). As my monitor is not a CRT screen I expect it does support reduced blanking; so perhaps dummyqbs does not support reduced blanking? Reduced blanking helps save bandwidth / pixel clock, useful to make the most of a weak GPU or a weak link like HDMI 1.4.

Edit: unless there's an Xorg setting I'm overlooking to indicate the monitor does support reduced blanking?

uint commented 3 years ago

Is there any news here? I'm hitting this on dual 4k.

Swapping dummyqbs for dummy as workaround no longer works as Xorg log says it can't load the 'dummy' module.

Can't get that to work either.

zezadas commented 2 years ago

Did some tests on Qubes4.1 and managed to increase the refresh rate, however I don't notice any differences. On 1080p videos it plays close to smooth and on 4k videos there is a small frame drop/lag. I'm using mplayer and big buck bunny videos (60fps) to test this modification:

http://bbb3d.renderfarming.net/download.html

I've recompiled xf86-video-dummy with int maxClock = 600000; Updated qubes-run-xorg with:

DUMMY_MAX_CLOCK=551 #300 #hardcoded in dummy_drv
PREFERRED_HSYNC=129 #50
[...]
#if [ $CLOCK -gt $DUMMY_MAX_CLOCK ] ; then CLOCK=$DUMMY_MAX_CLOCK ; fi

On appvm xrandr shows updated vertical and horizontal rate:

xrandr --verbose
[...]
Screen 0: minimum 64 x 64, current 3840 x 2160, maximum 32767 x 32767
DUMMY0 connected primary 3840x2160+0+0 (0x5f) normal (normal) 0mm x 0mm
QB3840x2160 (0x5f) 495.000MHz *current +preferred
        h: width  3840 start 3841 end 3842 total 3843 skew    0 clock 128.81KHz
        v: height 2160 start 2161 end 2162 total 2163           clock  59.55Hz
[...]

xorg-qubes.conf reflects the new values

[...]
Section "Monitor"
        Identifier "Monitor0"
        HorizSync 128-129
    VertRefresh 59-60
    Modeline "QB3840x2160" 495 3840 3841 3842 3843 2160 2161 2162 2163 
EndSection
[...]

Xorg logs:

[...]
[    60.814] (**) DUMMYQBS(0): VideoRAM: 42401 kByte
[    60.814] (--) DUMMYQBS(0): Max Clock: 600000 kHz
[    60.814] (II) DUMMYQBS(0): Monitor0: Using hsync range of 128.00-129.00 kHz
[    60.814] (II) DUMMYQBS(0): Monitor0: Using vrefresh range of 59.00-60.00 Hz
[    60.814] (II) DUMMYQBS(0): Clock range:  11.00 to 600.00 MHz
[...]

dom0:

3840x2160 (0x4d) 551.120MHz +HSync -VSync *current +preferred
        h: width  3840 start 3888 end 3920 total 4160 skew    0 clock 132.48KHz
        v: height 2160 start 2164 end 2168 total 2208           clock  60.00Hz

GPU:

VGA compatible controller: Intel Corporation TigerLake-H GT1 [UHD Graphics] (rev 01)

CPU:

vendor_id   : GenuineIntel
model name  : 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz

On browser(firefox): youtube plays nice; other videos such as big buck bunny, it's awful.

0spinboson commented 2 years ago

could you upload the packages for me somewhere so I can also give this a go? I tried compiling myself but I'm getting errors I don't understand, and I'd like to know how much of a difference it makes for me.

ranchester2 commented 1 year ago

I am using the stable version and I have a low refresh rate on only one of my devices.

On one of my laptops, I have 2 1440p monitors and it works at 60hz.

However, on my other laptop, when I have set video mem to 1 1440p monitor, when using 1080p desktop (if that matters), I have 46.1 hz.

If I can have 2 1440p monitors at 60hz on the other laptop, why on a different one with half the video mem I get only 46 hz?

ztmzzz commented 10 months ago

I've conducted some tests on Qubes 4.2.0rc5. My monitor is 4K 120Hz , and my CPU and GPU are AMD Ryzen 7 7700X.

In the default settings, xrandr shows 4k24Hz, but testufo shows 60Hz.

According to this, I've set the following parameters:

int maxClock = 1000000; DUMMY_MAX_CLOCK=1000; PREFERRED_HSYNC=1000.

It's not necessary to set PREFERRED_HSYNC this high. This is just for testing purposes.

In the appvm, I was able to achieve 4K 120Hz. When only one window is open, the performance is excellent. Testing with testufo yielded a smooth 120Hz, with CPU usage of Xorg is 35%. However, with two windows open, both are around 80Hz, with CPU usage of Xorg is 60%. Things get worse when three windows are open, the refresh rates for each window is 80Hz, 70Hz, 40Hz. CPU usage of Xorg is 90% and severe lagging and unresponsiveness occur. I don't think it's practical to go for high frame rates unless using a multi-threaded Xorg.

Translated by deepl and chatgpt.

rkfox commented 7 hours ago

I have the same issue with a 240hz monitor only being able to reach 35hz in a single monitor setup. Is there any working being done on this? I'm not sure I understand how to patch the xf86-video-dummy package or if this is even worth doing per @ztmzzz's experience.

QubesOS / qubes-issues