Lower FPS than expected through WSLg

[happy2046]

the gui apps seems to be at fixed 30fps(or 32fps like windows rdp default ).
is there something like DWMFRAMEINTERVAL on windows rdp server to change the fps?

[f1amy]

For me, GUI apps locked at 60 fps instead (I have 144hz and 72hz monitors).

[spronovo]

@happy2046 could share your /mnt/wslg/weston.log.

[Raymonf]

For me, my weston.log states Output repaint window is 7 ms maximum. and my screen refresh rate is 165hz, so it's close but not quite (should be closer to 6 ms). gedit still seems to be rendering at 60fps or a similar rate.

I'm not the issue creator, but this is my weston.log.

[Peredery]

@happy2046 could share your /mnt/wslg/weston.log.

also my log: #131 (comment)

[happy2046]

@spronovo
here is my log.
After reading other issues about gui I tried again but I still cant get 60fps(my monitor).

https://www.testufo.com/refreshrate reports my wslg chrome is at 60hz but thre real fps is not,its about 45fps from PresentMon.
(If I move other wslg gui app window,the max fps reported by PresentMon is also about 45fps and its not smooth)

I have tried both gtx750(wddm 3.0 driver from windows update) and rx470 on my computer(only enable one card when testing).

user@DESKTOP-RJGF24Q:~$ glxinfo -B
name of display: :0
display: :0 screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Microsoft Corporation (0xffffffff)
Device: D3D12 (Radeon (TM) RX 470 Graphics) (0xffffffff)
Version: 21.0.1
Accelerated: yes
Video memory: 36800MB
Unified memory: no
Preferred profile: core (0x1)
Max core profile version: 3.3
Max compat profile version: 3.1
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.0
OpenGL vendor string: Microsoft Corporation
OpenGL renderer string: D3D12 (Radeon (TM) RX 470 Graphics)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 21.0.1
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 3.1 Mesa 21.0.1
OpenGL shading language version string: 1.40
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.0 Mesa 21.0.1
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00

user@DESKTOP-RJGF24Q:~$ dmesg |grep dxg
[ 0.323970] hv_vmbus: registering driver dxgkrnl
[ 0.323975] (NULL device *): dxgk: dxg_drv_init Version: 2103
[ 0.325799] (NULL device *): dxgk: mmio allocated c00000000 200000000 c00000000 dffffffff
[ 12.020627] dxgk:err: is_handle_valid Entry is freed 40000080 2
[ 12.020629] dxgk:err: hmgrtable_get_object_by_type invalid handle 40000080
[ 12.020632] dxgk:err: adapter_by_handle failed 40000080
[ 12.020778] dxgk:err: is_handle_valid Entry is freed 40000080 2
[ 12.020779] dxgk:err: hmgrtable_get_object_by_type invalid handle 40000080
[ 12.020779] dxgk:err: adapter_by_handle failed 40000080
[ 12.031652] dxgk:err: is_handle_valid Entry is freed 40000080 2
[ 12.031654] dxgk:err: hmgrtable_get_object_by_type invalid handle 40000080
[ 12.031654] dxgk:err: adapter_by_handle failed 40000080
[ 12.073519] dxgk:err: is_handle_valid Entry is freed 40000080 2
[ 12.073521] dxgk:err: hmgrtable_get_object_by_type invalid handle 40000080
[ 12.073522] dxgk:err: adapter_by_handle failed 40000080
[ 12.197446] dxgk:err: is_handle_valid Entry is freed 40000080 2
[ 12.197449] dxgk:err: hmgrtable_get_object_by_type invalid handle 40000080
[ 12.197450] dxgk:err: adapter_by_handle failed 40000080
[ 13.623607] dxgk:err: is_handle_valid Entry is freed 40000080 2
[ 13.623609] dxgk:err: hmgrtable_get_object_by_type invalid handle 40000080
[ 13.623610] dxgk:err: adapter_by_handle failed 40000080
[ 14.423753] dxgk:err: is_handle_valid Entry is freed 40000080 2
[ 14.423755] dxgk:err: hmgrtable_get_object_by_type invalid handle 40000080
[ 14.423756] dxgk:err: adapter_by_handle failed 40000080
[ 14.425942] dxgk:err: is_handle_valid Entry is freed 40000080 2
[ 14.425943] dxgk:err: hmgrtable_get_object_by_type invalid handle 40000080
[ 14.425943] dxgk:err: adapter_by_handle failed 40000080
[ 59.745885] dxgk:err: is_handle_valid Entry is freed 40000080 2
[ 59.745887] dxgk:err: hmgrtable_get_object_by_type invalid handle 40000080
[ 59.745888] dxgk:err: adapter_by_handle failed 40000080
[ 59.746053] dxgk:err: is_handle_valid Entry is freed 40000080 2
[ 59.746054] dxgk:err: hmgrtable_get_object_by_type invalid handle 40000080
[ 59.746055] dxgk:err: adapter_by_handle failed 40000080
[ 59.756300] dxgk:err: is_handle_valid Entry is freed 40000080 2
[ 59.756302] dxgk:err: hmgrtable_get_object_by_type invalid handle 40000080
[ 59.756302] dxgk:err: adapter_by_handle failed 40000080
[ 59.791364] dxgk:err: is_handle_valid Entry is freed 40000080 2
[ 59.791365] dxgk:err: hmgrtable_get_object_by_type invalid handle 40000080
[ 59.791366] dxgk:err: adapter_by_handle failed 40000080
[ 59.894272] dxgk:err: is_handle_valid Entry is freed 40000080 2
[ 59.894273] dxgk:err: hmgrtable_get_object_by_type invalid handle 40000080
[ 59.894274] dxgk:err: adapter_by_handle failed 40000080
[ 60.580914] dxgk:err: is_handle_valid Entry is freed 40000080 2
[ 60.580916] dxgk:err: hmgrtable_get_object_by_type invalid handle 40000080
[ 60.580917] dxgk:err: adapter_by_handle failed 40000080
[ 60.958591] dxgk:err: is_handle_valid Entry is freed 40000080 2
[ 60.958593] dxgk:err: hmgrtable_get_object_by_type invalid handle 40000080
[ 60.958594] dxgk:err: adapter_by_handle failed 40000080
[ 60.961083] dxgk:err: is_handle_valid Entry is freed 40000080 2
[ 60.961085] dxgk:err: hmgrtable_get_object_by_type invalid handle 40000080
[ 60.961085] dxgk:err: adapter_by_handle failed 40000080
[ 135.455779] dxgk:err: is_handle_valid Entry is freed 40000080 2
[ 135.455781] dxgk:err: hmgrtable_get_object_by_type invalid handle 40000080
[ 135.455782] dxgk:err: adapter_by_handle failed 40000080
[ 135.455918] dxgk:err: is_handle_valid Entry is freed 40000080 2
[ 135.455919] dxgk:err: hmgrtable_get_object_by_type invalid handle 40000080
[ 135.455920] dxgk:err: adapter_by_handle failed 40000080
[ 135.465304] dxgk:err: is_handle_valid Entry is freed 40000080 2
[ 135.465305] dxgk:err: hmgrtable_get_object_by_type invalid handle 40000080
[ 135.465306] dxgk:err: adapter_by_handle failed 40000080
[ 135.484290] dxgk:err: is_handle_valid Entry is freed 40000080 2
[ 135.484291] dxgk:err: hmgrtable_get_object_by_type invalid handle 40000080
[ 135.484292] dxgk:err: adapter_by_handle failed 40000080
[ 135.560747] dxgk:err: is_handle_valid Entry is freed 40000080 2
[ 135.560748] dxgk:err: hmgrtable_get_object_by_type invalid handle 40000080
[ 135.560749] dxgk:err: adapter_by_handle failed 40000080
[ 135.988167] dxgk:err: is_handle_valid Entry is freed 40000080 2
[ 135.988169] dxgk:err: hmgrtable_get_object_by_type invalid handle 40000080
[ 135.988170] dxgk:err: adapter_by_handle failed 40000080

weston.txt

[spronovo]

Thanks @happy2046. We investigated these reports further, understand the problem and are working on a fix.

The way to think about frame rate for WSLg is that applications in Linux present to the Weston/Wayland compositor at a rate which is decoupled from the rate that Weston present to the Windows compositor. You essentially have two compositors chained, so things will look a little funky when you use a tools like PresentMon to observe it... GPUView will give you a much better picture (but a lot trickier to use). An application inside of WSL for example can render at 400fps, but the Weston compositor will only notify the Windows compositor of the frame it can effectively consume. There is no point for Weston sending each of those 400 application frames over to Windows if the Windows compositor is only going to be consuming and displaying 60 of them... we would be wasting precious resources without changing the outcome visible on the screen. A tool like gperfmon will only be able to show you the frame that actually reaches the Windows compositor, GPUView will show you both. We want to ensure that Weston sends enough frame to max out your monitor refresh. There is an issue currently where there is an unfortunate 9ms delay that gets added in (complicated story :-)), so effectively you're getting about 1/25ms ~= 40 fps instead of the target 60 to the Windows side as you have noted and has can be seen in PresentMon.

We also recently added config options that will allow you to unlock the frame rate from 60 to run at higher rate on higher refresh monitor (e.g. 144hz). This won't be auto-magically setup based on your monitor quite just yet and will require manual config for the time being, but will allow users to better match their monitor... but to fully achieve these rate we have to fix the bug above first. Once this reaches a public WSLg update we'll publish some more instructions for folks on how to try this out.

[Peredery]

@spronovo Hi! Could you please tell me how soon the fix will be in the new build? As I see, you fixed the performance issue of the rdp backend in your working repository

[spronovo]

WSLg 1.0.22 was just released externally. You can pick it up by doing the following from an elevated command prompt:

wsl --shutdown
wsl --update

By default WSLG will now emit 60fps to the Windows host... but if you are running on a higher rate monitor you can adjust that by adding an entry like below in c:\ProgramData\Microsoft\WSL\.wslgconfig (for example below i'm running on a 100hz monitor). In the future we'll automatically adjust to the composition rate of your desktop, but that information isn't available today through the RDP protocol and thus will have to wait until we get a chance to rev it. It's fine to run WSLg at a higher rate than your monitor, but if you run say 144 on a 60hz monitor... you'll end up with lots of wasted frames that never end up being seen but wasted CPU/GPU resources... so generally you don't want to put it much higher than what you need :-).

[system-distro-env]
WESTON_RDP_MONITOR_REFRESH_RATE=100

[spronovo]

I also wrote a small wiki entry to give a bit more background on this.

https://github.com/microsoft/wslg/wiki/Controlling-WSLg-frame-rate

[Hoffs]

Is the update available now for everyone? I ran --update and also got latest insider windows 21387.1, but /mnt/wslg/versions.txt is still saying that wslg is WSLg ( x86_64 ): 1.0.17+3.Branch.master.Sha.a526dfd5ad03d126bb2d8c528f6c3563e86a40da.

EDIT: Managed to get it updated using msi installer.

[Peredery]

@spronovo
seems like doesn't work for browsers (edge/chrome). Is it problem with browsers or WSLG?

https://www.testufo.com/refreshrate still saying it's 60hz

dwm.exe[1652]:     
000002A749085990 (DXGI): SyncInterval=1 Flags=0 12.75 ms/frame (78.4 fps, 78.2 fps displayed, 4.54 ms latency) Hardware: Legacy Flip                             

My config in "c:\ProgramData\Microsoft\WSL.wslgconfig"

[system-distro-env]
WESTON_RDP_MONITOR_REFRESH_RATE=144

[spronovo]

@Peredery i'm not entirely sure. I've tried both Chrome and Edge, I'm not sure what they use for vsync source. I do get an error in the page indicating they can't get vsync on Linux... so my suspicion is that they emulate vsync with a timer, but i'm not sure. Unfortunately i don't have a lot of time to dig into this one at the moment, i'll dig more when i get a chance. Are you getting the same error as below? Are you seeing this working on a native Linux system?

Are you seeing 144hz for other applications? For example using Geek3D and PresentMon to measure FPS from DWM on the host you should see something like below. I'm running on a 100hz monitor. The application is rendering and presenting ~600fps inside of WSL... and 100fps is forwarded to Windows so they can be made visible on the screen (effectively saturating what the monitor can display). On older build you would have seen ~40fps being forwarded to Windows.

[spronovo]

Is the update available now for everyone? I ran --update and also got latest insider windows 21387.1, but /mnt/wslg/versions.txt is still saying that wslg is WSLg ( x86_64 ): 1.0.17+3.Branch.master.Sha.a526dfd5ad03d126bb2d8c528f6c3563e86a40da.

EDIT: Managed to get it updated using msi installer.

This is very odd. 1.0.22 should indeed be pushed to everyone on the Insider pool... even weirder is that before 1.0.22 we had been pushing 1.0.19 for weeks... yet your system is still on 1.0.17. I'm not sure what happened there. Did you get some error from wsl --update?

It looks like manually installing the msi fixed it for you. Could you try going to add or remove a program and remove Windows Subsystem for Linux WSLg Preview and try wsl --shutdown and wsl --update again and see if you are getting any error? If you are getting an error, could you set this registry key (see this article):

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer\Logging
Reg_SZ == voicewarmupx

Try wsl --update again, then look inside dir /Od %temp%\msi*.log... there should be a file name MSI__somenumber__.log with a timestamp of now. Share that log file back.

[Hoffs]

Is the update available now for everyone? I ran --update and also got latest insider windows 21387.1, but /mnt/wslg/versions.txt is still saying that wslg is WSLg ( x86_64 ): 1.0.17+3.Branch.master.Sha.a526dfd5ad03d126bb2d8c528f6c3563e86a40da.
EDIT: Managed to get it updated using msi installer.

This is very odd. 1.0.22 should indeed be pushed to everyone on the Insider pool... even weirder is that before 1.0.22 we had been pushing 1.0.19 for weeks... yet your system is still on 1.0.17. I'm not sure what happened there. Did you get some error from wsl --update?

It looks like manually installing the msi fixed it for you. Could you try going to add or remove a program and remove Windows Subsystem for Linux WSLg Preview and try wsl --shutdown and wsl --update again and see if you are getting any error? If you are getting an error, could you set this registry key (see this article):

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer\Logging
Reg_SZ == voicewarmupx

Try wsl --update again, then look inside dir /Od %temp%\msi*.log... there should be a file name MSI__somenumber__.log with a timestamp of now. Share that log file back.

TLDR: If wsl --update is run while distro is running a full reboot is required and not just wsl --shutdown.

I didn't get any error and I believe it did download some update when I first tried wsl --update, but the version remained the same. And running wsl --update afterwards multiple times just returned the there are no updates message even though I was still seeing the 1.0.17 version. Afterwards I tried using msi installer and it didn't work at first, then I removed existing WSLg "app" through add or remove, double checked that all distros were shutdown (wsl --shutdown) and only then the msi installer seemed to update correctly. I am pretty sure I did wsl --shutdown at least once between all the attempts, so I don't think I just missed the update. I would guess that it had something to do with running update/installer while wsl is running.

I just tried to remove wslg again (add or remove) and do wsl --update and this time it updated to latest version correctly.

I also tried to use 1.0.17 installer, then keep wsl running, run 1.0.22 installer, after it finishes do wsl --shutdown. After this I ended up with a situation I explained above, wslg is still showing 1.0.17, but the windows app is showing 1.0.22:

wsl --update is also not doing anything here and shows the no updates found message.

So since that "broke" I also just tried my idea, installed 1.0.17 using msi, kept distro running, ran wsl --update, update was received and installed, wsl --shutdown. Result is same as above, windows is saying 1.0.22, but wslg versions is still on 1.0.17. This looks similar to what happened to me in the first place.

Confusing part is that windows thinks 1.0.22 is installed but its not actually.

I tried doing the msi installer log thing and it does write in the log Product: Windows Subsystem for Linux WSLg Preview. Restart required. The installation or update for the product required a restart for all changes to take effect. The restart was deferred to a later time. but this is not mentioned in the wsl --update output. After doing full restart the update does finish and it shows version 1.0.22 in versions.txt, just that windows/installer defers and wsl --shutdown is not enough.

I still think that something else happened initially and it didn't update after full reboot when I first tried it (maybe windows update conflicted since I ran the windows update after the first wsl --update didn't actually update wslg version) or I ended up with hard crash. And I also am unsure why I never got 1.0.19.

[psndna88]

Thanks @happy2046. We investigated these reports further, understand the problem and are working on a fix.

The way to think about frame rate for WSLg is that applications in Linux present to the Weston/Wayland compositor at a rate which is decoupled from the rate that Weston present to the Windows compositor. You essentially have two compositors chained, so things will look a little funky when you use a tools like PresentMon to observe it... GPUView will give you a much better picture (but a lot trickier to use). An application inside of WSL for example can render at 400fps, but the Weston compositor will only notify the Windows compositor of the frame it can effectively consume. There is no point for Weston sending each of those 400 application frames over to Windows if the Windows compositor is only going to be consuming and displaying 60 of them... we would be wasting precious resources without changing the outcome visible on the screen. A tool like gperfmon will only be able to show you the frame that actually reaches the Windows compositor, GPUView will show you both. We want to ensure that Weston sends enough frame to max out your monitor refresh. There is an issue currently where there is an unfortunate 9ms delay that gets added in (complicated story :-)), so effectively you're getting about 1/25ms ~= 40 fps instead of the target 60 to the Windows side as you have noted and has can be seen in PresentMon.

We also recently added config options that will allow you to unlock the frame rate from 60 to run at higher rate on higher refresh monitor (e.g. 144hz). This won't be auto-magically setup based on your monitor quite just yet and will require manual config for the time being, but will allow users to better match their monitor... but to fully achieve these rate we have to fix the bug above first. Once this reaches a public WSLg update we'll publish some more instructions for folks on how to try this out.

I had a problem using smartgit that its right click context windows used to stop appearing & then no more gui windows opened unless i had to shutdown wsl...
I have forked latest WSL kernel, upstreamed it, added ntfs3, some config changes, and added this commit(psndna88/WSL2-Linux-Kernel@29a5099) after which its been many hours i havent faced the problem.
Maybe it will help official WSL kernel developement and other people too. I have also provided pre-compiled kernel bzImage.