On my Fedora 28 system running a RX Vega 64 on open source drivers, the KDE compositor seems to set the wrong refresh rate. I have a 144Hz monitor, but the Kwin compositor seems to render at 60FPS. I have verified that the monitor is indeed set to 144Hz via xrandr. Moving windows around seems really laggy. If I disable the compositor, it feels silky smooth (minus all the window repainting of course). I am currently working around this issue by setting "MaxFPS=144" and "RefreshRate=144" in kwinrc, but I think the failure to detect the proper compositor refresh rate here is still a bug. I will attach "xrandr" and "qdbus org.kde.KWin /KWin supportInformation" logs shortly.
Created attachment 113451 [details] xrandr output
Created attachment 113452 [details] kwin support information The kwin support information seems to list my screen as 60Hz? This is strange since I am clearly running at 144 according to xrandr.
According to the support information KWin thinks the output has 60 Hz.
The monitor most definitely supports 144Hz. It's a Acer Predator XB271HU bmiprz 27" WQHD (2560x1440) NVIDIA G-SYNC IPS Display. xrandr also shows that I am on 144Hz as well. How come KWin doesn't just check xrandr for refresh rate and then match that?
Created attachment 113524 [details] kwin wayland support info Funny enough, if I run KDE with Wayland, it gets the correct refresh rate from the monitor. I've attached the support info logs for comparison. Screen 0: --------- Name: ACR DP-1-XB271HU/#ASNFeULjO7/ Geometry: 0,0,2560x1440 Scale: 1 Refresh Rate: 143.998
(In reply to Benjamin Xiao from comment #4) > The monitor most definitely supports 144Hz. It's a Acer Predator XB271HU > bmiprz 27" WQHD (2560x1440) NVIDIA G-SYNC IPS Display. > > xrandr also shows that I am on 144Hz as well. How come KWin doesn't just > check xrandr for refresh rate and then match that? Well we do exactly that. We use the xrandr API. It's btw. not that surprising that it works on Wayland. There we interact more directly with the API.
(In reply to Martin Flöser from comment #6) > > Well we do exactly that. We use the xrandr API. > > It's btw. not that surprising that it works on Wayland. There we interact > more directly with the API. Thanks for the clarification Martin. Hmm so why is the xrandr command output showing that its at 144Hz, but the xrandr API is returning 60Hz to KDE? That seems very strange. I tested with Gnome and it is able to correctly grab the refresh rate. It's compositor runs at 144 FPS automatically. I realize it's probably hard to debug this without the exact hardware configuration that I have, but I'd love to help test if you or anyone else is willing to help fix the bug.
Our calculation is here: https://cgit.kde.org/kwin.git/tree/plugins/platforms/x11/standalone/screens_xrandr.cpp#n79 I can only assume that your output is doing something we don't cover yet. But as you say: without the output it will be difficult.
I have noticed that on my Xserver compile from master branch games run in the X session locked at 60 fps, while they run unlocked through Xwayland. This might be connected to this issue.
(In reply to Roman Gilg from comment #9) > I have noticed that on my Xserver compile from master branch games run in > the X session locked at 60 fps, while they run unlocked through Xwayland. > This might be connected to this issue. I've noticed the opposite. When I run games in Xwayland and I have vsync on in-game, the game gets capped at 60 fps. In Xorg, with vsync on I get over 60.
(In reply to Martin Flöser from comment #8) > Our calculation is here: > https://cgit.kde.org/kwin.git/tree/plugins/platforms/x11/standalone/ > screens_xrandr.cpp#n79 > > I can only assume that your output is doing something we don't cover yet. > But as you say: without the output it will be difficult. Hey Martin, so I've setup my build environment and I am able to compile and replace kwin on my Fedora system. I was planning on placing some logging statements into screens_xrandr.cpp to print out the different modes and refresh rates. As I am completely new to KDE code, do you have any suggestions as to how and what I should be logging? What additional information do you need to debug this? Happy to chuck in whatever logging code you desire.
Are you using X.org 1.20? If not, you probably see https://bugs.freedesktop.org/show_bug.cgi?id=103282
(In reply to Benjamin Xiao from comment #11) > (In reply to Martin Flöser from comment #8) > > Our calculation is here: > > https://cgit.kde.org/kwin.git/tree/plugins/platforms/x11/standalone/ > > screens_xrandr.cpp#n79 > > > > I can only assume that your output is doing something we don't cover yet. > > But as you say: without the output it will be difficult. > > Hey Martin, so I've setup my build environment and I am able to compile and > replace kwin on my Fedora system. I was planning on placing some logging > statements into screens_xrandr.cpp to print out the different modes and > refresh rates. As I am completely new to KDE code, do you have any > suggestions as to how and what I should be logging? What additional > information do you need to debug this? Happy to chuck in whatever logging > code you desire. First of all I would like to know whether KWin finds the refresh rate at all. And what the refresh rate is which KWin calculates.
(In reply to Christoph Feck from comment #12) > Are you using X.org 1.20? If not, you probably see > https://bugs.freedesktop.org/show_bug.cgi?id=103282 I am using 1.19. However that bug is related to Xwayland. This bug is for the Kwin compositor being locked at 60fps running in full Xorg.
(In reply to Martin Flöser from comment #13) > First of all I would like to know whether KWin finds the refresh rate at > all. And what the refresh rate is which KWin calculates. At line 90, I logged the refresh rate to a file and it correctly gives me a refresh rate of 143.998. So according to the logic, it found the mode and calculated the correct refresh rate. What else should I check?
Okay, this problem gets weirder. I am using the "Show FPS" desktop effect, which I know isn't a totally accurate benchmark, but for some reason every time I restart my machine and login, the FPS is capped at 60. The moment I do a "kwin --replace", the cap instead becomes 75... I then decided to do a test with vsynctester.com in Chrome. On a fresh boot, Chrome will report 60FPS in vsynctester. After a "kwin --replace", Chrome will report 143Hz, even though Kwin itself is running at 75. I should note that each time I launch kwin, my logs at line 90 are showing that the calculated refresh rate is 143.998.
The fps effect is capped, so will never get the 140 fps. So it looks like on startup the resolution is misdetected. Could it be that kscreen changes the resolution?
(In reply to Martin Flöser from comment #17) > The fps effect is capped, so will never get the 140 fps. So it looks like on > startup the resolution is misdetected. Could it be that kscreen changes the > resolution? Right its capped at 100. When I force Kwin's fps to 144, that's what I get. When I don't force it, I'll get either 60 or 75 depending on whether I've done "kwin --replace" or not. The resolution is the same. It's 2560x1440 all the way from Plymouth to login. I do notice that SDDM does run at 60Hz though and then after logging in KDE will switch the monitor Hz rate to 144. Except there's no corresponding change in refresh rate in the compositor.
Let's ignore the Chrome issue for now. There's probably just something screwy with Chrome itself, because on boot it will get stuck @60Hz on vsynctester.com but then the moment I launch Steam, it will go to 144Hz. The facts are: - Monitor refresh rate is correctly set to 144Hz. - Xrandr returns 144Hz to KDE. - First boot, Kwin refresh rate is set to 60. - Doing a kwin --replace, Kwin refresh rate is set to 75. Just out of curiosity, does Kwin cap refresh rate to half of monitor rate?
I am also having this issue with an RX 580 with an Acer Predator XG270HU at 144Hz. Forcing KWin to 144 fps only goes to 100 fps. I'm on Fedora 28 as well with KDE Plasma 5.12.6. xrandr reports that I'm running at 144Hz as well. [chris@GT40-Fedora ~]$ xrandr Screen 0: minimum 320 x 200, current 2560 x 1440, maximum 16384 x 16384 DisplayPort-0 disconnected (normal left inverted right x axis y axis) DisplayPort-1 disconnected (normal left inverted right x axis y axis) DisplayPort-2 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 597mm x 336mm 2560x1440 59.95 + 143.86* 119.88 99.95 I'm not sure how to get the kwin support information but I'd love to attach it if I can get that info.
(In reply to Christian Martinez from comment #20) > Forcing KWin to 144 fps only goes to 100 fps. Btw the Kwin "Show FPS" effect is capped at 100fps. It won't go higher than that even if Kwin is running at 144. If you don't force Kwin to run at 144, Kwin should show 60fps if you're experiencing this bug.
Created attachment 113957 [details] New kwin support information with Xorg 1.20 and Plasma 5.13.3 So I switched to Arch Linux just to see if the issue still occurs with the latest Xorg and Plasma. Now KDE correctly sees my monitor as a 144Hz monitor according to "qdbus org.kde.KWin /KWin supportInformation". HOWEVER, Kwin still seems to be running only at 75 FPS instead of 144.
(In reply to Benjamin Xiao from comment #22) > HOWEVER, Kwin still seems to be running only at 75 FPS instead of 144. How do you measure this?
The Show FPS desktop effect shows 75. Also dragging windows around is significantly more laggy than if I forced 144Hz.
Please ignore the showfps effect. It is not a Benchmark. It cannot handle 144 Hz. Using it with such a monitor is undefined behavior.
(In reply to Martin Flöser from comment #25) > Please ignore the showfps effect. It is not a Benchmark. It cannot handle > 144 Hz. Using it with such a monitor is undefined behavior. Which way would you recommend I find out? I definitely feel that kwin renders at a slower fps when I don't force 144 in kwinrc. I know the Show FPS effect is capped at 100. But seems accurate to me for values under that. I definitely feel a difference in fps just dragging the mouse around though. When I force 144 in kwinrc, it gives me 100. If I don't, it shows me 75.
> I definitely feel a difference in fps just dragging the > mouse around though. Sorry I meant dragging windows around. Mouse itself is fine.
If KWin correctly detects the refresh rate the maxfps setting has no influence at all. It's the same code.
(In reply to Martin Flöser from comment #28) > If KWin correctly detects the refresh rate the maxfps setting has no > influence at all. It's the same code. If I set MaxFPS=144, there's definitely a difference. I can feel it in webpage scrolling and when moving windows around. I wish there was another way for me to prove it to you besides the ShowFPS plugin. The difference is very visible. Also doesn't the fact that ShowFPS shows different values prove that there's something going on? Yes I get that it isn't accurate, but the MaxFPS setting is doing something because when I have it set to 144, Show FPS effect gives me 100. If I don't have it set, it gives me 75. If the code there is exactly the same, there must be a different section of the code that's influencing this. If you don't think that Show FPS is accurate, could you please let me know of an alternative way to prove it? This is NOT placebo. Many people on Reddit are also experiencing this same issue and have had to use MaxFPS=144. You've already posted several times there saying that it isn't a valid solution and that we should file bug reports, but currently that remains the only valid solution to fully taking advantage of our high refresh rate monitors.
Again, I am willing to rebuild kwin on my system with any additional code to prove it, but I don't think simply printing out the refresh rate variable is going to cut it. There's something else in play here.
Ok, I just re-read the relevant code section. If you have: Painting blocks for vertical retrace: no then the refresh rate is ignored and the maxFps setting is honored, which is by default 60. So the true problem is that you don't have vsync.
According to the debug output you have vsync set to "Only when cheap", please try the default "automatic".
(In reply to Martin Flöser from comment #32) > According to the debug output you have vsync set to "Only when cheap", > please try the default "automatic". I've never set vsync to anything else besides Automatic. I've always kept it at the default setting. I double checked my setting and it is indeed still on Automatic. I then tried switching to all the other vsync options and then rerunning the debug output. However, no matter what I try, "Painting blocks for vertical retrace" is always no. Is there some vsync option I need to enable in the amd driver?
I even tried enabling TearFree in Xorg. It didn't make a difference.
Oh interesting! So when I try disabling KWIN_TRIPLE_BUFFER, Painting blocks for vertical retrace becomes yes. Kwin then correctly runs at 144 FPS!!! But why do I have to disable KWIN_TRIPLE_BUFFER? Should this be enabled or not?
(In reply to Benjamin Xiao from comment #35) > Oh interesting! So when I try disabling KWIN_TRIPLE_BUFFER, Painting blocks > for vertical retrace becomes yes. Kwin then correctly runs at 144 FPS!!! > > But why do I have to disable KWIN_TRIPLE_BUFFER? Should this be enabled or > not? What do you mean by disable? Removing the environment variable or setting it to 0?
(In reply to Martin Flöser from comment #36) > (In reply to Benjamin Xiao from comment #35) > > Oh interesting! So when I try disabling KWIN_TRIPLE_BUFFER, Painting blocks > > for vertical retrace becomes yes. Kwin then correctly runs at 144 FPS!!! > > > > But why do I have to disable KWIN_TRIPLE_BUFFER? Should this be enabled or > > not? > > What do you mean by disable? Removing the environment variable or setting it > to 0? Sorry I should have clarified. Before I did not have the environment variable set. Now I have it set to 0.
So it seems like if Kwin thinks that triple buffering is available then it causes "Painting blocks for vertical retrace" to be no. ------------------------------------------------------------- | KWIN_TRIPLE_BUFFER | Painting blocks for vertical retrace | |------------------------------------------------------------ | not set | no | |------------------------------------------------------------ | 1 | no | |------------------------------------------------------------ | 0 | yes | |------------------------------------------------------------ I am assuming that when it isn't set, the heuristics are detecting that triple buffering is available. After all, it is DRI3.
After a brief period of using KWIN_TRIPLE_BUFFER=0 to get proper FPS in Kwin, I've noticed increased micro stuttering in a lot of apps particularly scrolling in web browsers, which I guess makes sense since we're only double buffering. So unfortunately it isn't a valid workaround compared to setting MaxFPS=144 in kwinrc. Do we know why KWIN_TRIPLE_BUFFER would cause "Painting blocks for vertical retrace" to be no? My vsync setting in System Settings -> Display and Monitor -> Compositor is for sure set to Automatic.
Still running into this issue on Plasma 5.14.5 and Frameworks 5.55. Has there been any progress on this? It's really ruining the out of the box KDE experience on gaming displays. Been doing some more research into this and there seems to be multiple issues at work here. 1. First is the KWIN_TRIPLE_BUFFER issue as noted in comment 38. Having it not set or set to a value of 1 causes "Painting blocks for vertical retrace" to be no, which apparently causes Kwin to ignore the active refresh rate of the monitor. 2. Second, I just discovered today that Kwin doesn't seem to be updating its refresh rate when I change it via xrandr or System Settings. The monitor itself runs at the new refresh rate but "qdbus org.kde.KWin /KWin supportInformation" continues to return whatever refresh rate was active at the time Kwin is started. So for example, if I boot up my computer and my refresh rate was 60 at the time, and then I go into System Settings and change it to 144, "qdbus org.kde.KWin /KWin supportInformation" still gives me 60Hz, even though the monitor is at 144. It doesn't refresh until I do a "kwin_x11 --replace". This isn't just the information not changing. It appears that certain apps are actually getting told the old refresh rate instead of the new one. Apps like Chrome will run at the old refresh rate until I "kwin_x11 --replace". You can certainly see how this causes poor frame timing and frame jitter. My monitor is running at 144, but Chrome and Kwin are running at 60. To work around these issues: 1. I set KWIN_TRIPLE_BUFFER=0 so that Kwin doesn't just ignore the refresh rate. 2. I've also added "xrandr --output DisplayPort-0 --mode 2560x1440 --rate 144" to /usr/share/sddm/scripts/Xsetup so that SDDM runs at 144Hz instead of 60Hz. That way, when Kwin starts, it will run at 144hz right off the bat. If I don't do this, Kwin will be stuck at 60hz according to "qdbus org.kde.KWin /KWin supportInformation". Chrome and other apps will also be running at 60hz until I restart Kwin. I get pretty good performance with those two steps but honestly, its a pretty hacky workaround. Kwin should be respecting what I set in System Settings and I shouldn't have to disable triple buffering.
I have this exact same issue... Is there a proper fix yet?
Created attachment 121974 [details] KWin info on Intel graphics Has there been any progress on this, Martin? This issue isn't RX Vega 64 specific it seems. On my laptop with Intel graphics, Painting blocks on vertical retrace is also returning No. Log attached. Basically KWin is broken on all monitors not running at 60Hz.
(In reply to Benjamin Xiao from comment #42) > Created attachment 121974 [details] > KWin info on Intel graphics > > Has there been any progress on this, Martin? > > This issue isn't RX Vega 64 specific it seems. On my laptop with Intel > graphics, Painting blocks on vertical retrace is also returning No. Log > attached. > > Basically KWin is broken on all monitors not running at 60Hz. Apparently not for everyone
(In reply to Martin Flöser from comment #6) > (In reply to Benjamin Xiao from comment #4) > > The monitor most definitely supports 144Hz. It's a Acer Predator XB271HU > > bmiprz 27" WQHD (2560x1440) NVIDIA G-SYNC IPS Display. > > > > xrandr also shows that I am on 144Hz as well. How come KWin doesn't just > > check xrandr for refresh rate and then match that? > > Well we do exactly that. We use the xrandr API. > > It's btw. not that surprising that it works on Wayland. There we interact > more directly with the API. What determines the value of "Painting blocks for vertical retrace"?
I'm currently working on the compositing. There have been already several patches landed as preparations: https://phabricator.kde.org/T11071 What would help me is if you guys would be on KWin master branch (for example via KDE Neon dev unstable) to test upcoming patches. I have here an AMD RX470 and a 75Hz display but the monitor is probably not enough. I'm gonna look for some 144Hz display to buy. You are using AMD graphics cards right? > This issue isn't RX Vega 64 specific it seems. On my laptop with Intel graphics, Painting blocks on vertical retrace is also returning No. Does this mean you noticed low refresh rates on a laptop with high refresh rate display and Intel graphics as well?
> > This issue isn't RX Vega 64 specific it seems. On my laptop with Intel graphics, Painting blocks on vertical retrace is also returning No. > > Does this mean you noticed low refresh rates on a laptop with high refresh > rate display and Intel graphics as well? I can confirm my laptop has this issue (Inspiron 7559) as well, framerate doesn't change with refresh rate changes.
And yes, I am ready to do whatever I can to help you, testing wise :)
(In reply to Roman Gilg from comment #45) > What would help me is if you guys would be on KWin master branch (for > example via KDE Neon dev unstable) to test upcoming patches. > > I have here an AMD RX470 and a 75Hz display but the monitor is probably not > enough. I'm gonna look for some 144Hz display to buy. You are using AMD > graphics cards right? > > Does this mean you noticed low refresh rates on a laptop with high refresh > rate display and Intel graphics as well? I don't have a spare machine to put KDE Neon on, how possible would it be to apply patches to Kwin 5.16.4? I can definitely apply patches onto that version of KDE. Maybe try with the 75Hz display first and see if the issue exists there too? I think the issue will happen for anything above 60, but I could be wrong. Martin Floser was saying that if Painting blocks with vertical retrace is no then refresh rate is ignored, so I figured the issue would happen on Intel as well. I haven't done extensive testing on that yet. I've only done testing on AMD cards.
(In reply to Benjamin Xiao from comment #48) > (In reply to Roman Gilg from comment #45) > > What would help me is if you guys would be on KWin master branch (for > > example via KDE Neon dev unstable) to test upcoming patches. > > > > I have here an AMD RX470 and a 75Hz display but the monitor is probably not > > enough. I'm gonna look for some 144Hz display to buy. You are using AMD > > graphics cards right? > > > > Does this mean you noticed low refresh rates on a laptop with high refresh > > rate display and Intel graphics as well? > > I don't have a spare machine to put KDE Neon on, how possible would it be to > apply patches to Kwin 5.16.4? I can definitely apply patches onto that > version of KDE. It's difficult because I rewrote larger parts. I would not recommend it. If you have some space on the HDD you can re-partition the disk and do a dual boot on the same machine. In GRUB then your default boot entry could still be Fedora. > Maybe try with the 75Hz display first and see if the issue exists there too? > I think the issue will happen for anything above 60, but I could be wrong. Oh most likely it will happen. I assume it will just be less obvious to spot with a 15Hz difference. And since the internal perf tools of KWin seem not to be reliable just visual analysis could be needed. > Martin Floser was saying that if Painting blocks with vertical retrace is no > then refresh rate is ignored, so I figured the issue would happen on Intel > as well. I haven't done extensive testing on that yet. I've only done > testing on AMD cards. Alright, if you could test it out would be great just to limit the problem scope.
(In reply to Roman Gilg from comment #49) > (In reply to Benjamin Xiao from comment #48) > > (In reply to Roman Gilg from comment #45) > > > What would help me is if you guys would be on KWin master branch (for > > > example via KDE Neon dev unstable) to test upcoming patches. > > > > > > I have here an AMD RX470 and a 75Hz display but the monitor is probably not > > > enough. I'm gonna look for some 144Hz display to buy. You are using AMD > > > graphics cards right? > > > > > > Does this mean you noticed low refresh rates on a laptop with high refresh > > > rate display and Intel graphics as well? > > > > I don't have a spare machine to put KDE Neon on, how possible would it be to > > apply patches to Kwin 5.16.4? I can definitely apply patches onto that > > version of KDE. > > It's difficult because I rewrote larger parts. I would not recommend it. If > you have some space on the HDD you can re-partition the disk and do a dual > boot on the same machine. In GRUB then your default boot entry could still > be Fedora. > > > Maybe try with the 75Hz display first and see if the issue exists there too? > > I think the issue will happen for anything above 60, but I could be wrong. > > Oh most likely it will happen. I assume it will just be less obvious to spot > with a 15Hz difference. And since the internal perf tools of KWin seem not > to be reliable just visual analysis could be needed. > > > Martin Floser was saying that if Painting blocks with vertical retrace is no > > then refresh rate is ignored, so I figured the issue would happen on Intel > > as well. I haven't done extensive testing on that yet. I've only done > > testing on AMD cards. > > Alright, if you could test it out would be great just to limit the problem > scope. I am on Arch Linux and can apply patches on top of kwin-git, I face this same issue on a Intel HD 530, what exactly do I need to do?
There is https://phabricator.kde.org/D23105 (as branch https://cgit.kde.org/clones/kwin/romangilg/kwin.git/log/?h=glxCleanup) which is my WIP experimental branch for complete overhaul of compositing. In the comments to the Phabricator diff you can get some idea on what feedback would help me there. And now there is an additional fix for refresh rates in: https://phabricator.kde.org/D23265 But this should be independent of the bug here since it fixes an issue with some commit I did after 5.16 branched off (so people on 5.16 or older should not be affected by that issue). Still it might be good to test master together with this fix. Maybe it also solves previous issues as well.
(In reply to Roman Gilg from comment #51) > There is > > https://phabricator.kde.org/D23105 > > (as branch > https://cgit.kde.org/clones/kwin/romangilg/kwin.git/log/?h=glxCleanup) > > which is my WIP experimental branch for complete overhaul of compositing. In > the comments to the Phabricator diff you can get some idea on what feedback > would help me there. > > And now there is an additional fix for refresh rates in: > https://phabricator.kde.org/D23265 > But this should be independent of the bug here since it fixes an issue with > some commit I did after 5.16 branched off (so people on 5.16 or older should > not be affected by that issue). Still it might be good to test master > together with this fix. Maybe it also solves previous issues as well. I will try testing this out today
Tested those patches on top of 5.16 with and without exporting that flag, still running at a solid 60, support info seems to report refresh rate as 0 for some reason.
https://pastebin.com/Mn9Bxgxs Attached support information here.
Also, window transitions are smoother with KWIN_USE_INTEL_SWAP_EVENT set to 0.
(In reply to Kailash from comment #54) > https://pastebin.com/Mn9Bxgxs > > Attached support information here. At least in the Screen 0 section, its reporting 100 for refresh rate. Is that what your display is currently set to? (In reply to Kailash from comment #53) > Tested those patches on top of 5.16 with and without exporting that flag, > still running at a solid 60, support info seems to report refresh rate as 0 > for some reason. Was Chrome running at 60 in vsynctester.com as well?
(In reply to Benjamin Xiao from comment #56) > (In reply to Kailash from comment #54) > > https://pastebin.com/Mn9Bxgxs > > > > Attached support information here. > > At least in the Screen 0 section, its reporting 100 for refresh rate. Is > that what your display is currently set to? > > (In reply to Kailash from comment #53) > > Tested those patches on top of 5.16 with and without exporting that flag, > > still running at a solid 60, support info seems to report refresh rate as 0 > > for some reason. > > Was Chrome running at 60 in vsynctester.com as well? Now that I remember, vsynctester reported 120fps for some reason (I set the refresh rate to 100), I simply can't get my head around this.
Did the session start at 120fps and you turned it down to 100? That's one of the bugs I am experiencing, where Chrome seems to use the refresh rate value that was set at the beginning of the X session.
(In reply to Benjamin Xiao from comment #58) > Did the session start at 120fps and you turned it down to 100? That's one of > the bugs I am experiencing, where Chrome seems to use the refresh rate value > that was set at the beginning of the X session. The session started at 60 fps and stays at 60 even if I switch to 100, but chromium shows 120 fps with vsync. I have no idea why or how to debug this :(
(In reply to Kailash from comment #59) > (In reply to Benjamin Xiao from comment #58) > > Did the session start at 120fps and you turned it down to 100? That's one of > > the bugs I am experiencing, where Chrome seems to use the refresh rate value > > that was set at the beginning of the X session. > > The session started at 60 fps and stays at 60 even if I switch to 100, but > chromium shows 120 fps with vsync. I have no idea why or how to debug this :( How do you check "real fps" that it supposedly "stays at" ? I've forced T11071 patches into my build of kwin-5.16.5 release and get: maxFpsInterval: 16666666 refreshRate: 0 vBlankTime: 6000000 glStrictBinding: false glStrictBindingFollowsDriver: true glCoreProfile: true glPreferBufferSwap: 99 glPlatformInterface: 2 windowsBlockCompositing: false … Screen 0: --------- Name: DVI-D-0 Geometry: 0,0,1920x1080 Scale: 1 Refresh Rate: 72.9249 Screen 1: --------- Name: HDMI-A-0 Geometry: 1920,0,1920x1080 Scale: 1 Refresh Rate: 71.8263 With my 2 OC'ed native 60fps displays. vsynctester.com in FF and all native apps show exact frame-time of what ~73 fps would get, as does the monitor itself. But kwin says "maxFpsInterval: 1(6), refreshRate: 0 and vBlankTime: 6*10^6" which is suspicious. All feels nice and snappy even though current kernel amdgpu has a bug that prevents me from enabling PageFlip. But how to be sure that kwin does not limit actual framerate between it and GPU by increasing frame-time after getting frames from the apps or something like that ? I also use these envvars, "just to be sure": KWIN_OPENGL_INTERFACE=egl KWIN_TRIPLE_BUFFER=0 KWIN_USE_BUFFER_AGE=1 KWIN_USE_INTEL_SWAP_EVENT=1 KWIN_PERSISTENT_VBO=1 (In reply to Roman Gilg from comment #45) > I'm currently working on the compositing. There have been already several > patches landed as preparations: https://phabricator.kde.org/T11071 > > What would help me is if you guys would be on KWin master branch (for > example via KDE Neon dev unstable) to test upcoming patches. > > I have here an AMD RX470 and a 75Hz display but the monitor is probably not > enough. I'm gonna look for some 144Hz display to buy. You are using AMD > graphics cards right? > > > This issue isn't RX Vega 64 specific it seems. On my laptop with Intel graphics, Painting blocks on vertical retrace is also returning No. > > Does this mean you noticed low refresh rates on a laptop with high refresh > rate display and Intel graphics as well? Please, don't allow your changes to bit-rot like what happened with fredrik's 'linux-dmabuf', 'vulkan' and 'swap-event-wip2' branches. kwin is pretty much #1 feature of all KDE, especially after deaths and stagnation of many core apps such as kde-telepathy, gwenview, akregator, etc.
on KDE neon/nvidia I get 120fps reported from display settings for my primary display, 60fps on the secondary. The mouse moves significantly smoother on the primary display. However vkcube and glxgears syncs to 60fps only.
Created attachment 132786 [details] kde neon +nviodia supportinfo if I disable vsync in ezquake fullscreen I can get the desired fps
I no longer get this issue with both my AMD and Nvidia GPUs. Closing.