Open MoshiBin opened 5 years ago
In case this might help someone else, these are my settings in the Nvidia Control Panel
Adding
"experimental.rendering.software": true
in settings.json on Windows Terminal Release Candidate v0.11.1333.0 (1.0rc2) resolves this issue for me.I assume I incur some level performance loss but I don't feel it on my machine.
I'm experiencing this issue as well and the G-Sync profile changes didn't fix it, but this did. Thanks.
After working with it for a few more days the profile solution was mostly effective for me but I've had occasional periods where it doesn't apply to Windows Terminal specifically. I haven't seen this problem for any other app that's also in the same no-gsync profile.
In a period where my Windows Store-installed copy of Terminal was currently being ignored by the Nvidia profile I, on a hunch, downloaded the matching msix (1.0.1401.0) from the releases page and extracted the folder for the x64 version directly to my desktop. Launching that copy's WindowsTerminal.exe
has gsync correctly disabled for its window while the Windows Store-installed copy that's still running simultaneously has its gsync enabled. Several consecutive restarts of each produce the same results.
No changes were made to profiles between those launches. In theory I'd expect the same profile to affect both of them equally such that neither uses gsync. I'm wondering if this might be a complication of the permissions and linking through wt.exe
involved in launching the Store-distributed version that causes it to slip by Nvidia's current detection mechanism. I have no idea how to explain my existing profile also seemingly applying correctly to the Store copy most of the time... I purged all other user-defined profiles and tried to correlate other windows in use but haven't spotted any pattern.
I'll probably continue using the extracted version instead of the store version for a while to see if that's reliable. It has the added bonuses of being easy to set the working directory on its shortcut when pinned to the taskbar, and also presumably never being quietly killed while hosting a long-running terminal process when the store forces an update. Only thing apparently missing so far are the profile icons referenced by ms-appx paths.
As an aside I've also been testing with neovide (a gpu-based GUI front-end for neovim) that acts similarly in terms of lazy screen redraws and thus exhibits the same gsync refresh rate drop by default when it has nothing it needs to redraw. The nvidia profile solution applies to neovide with 100% reliability as far as I can tell. From experimenting there it also appears that nvidia profiles are only evaluated at initial app launch so adding/removing neovide.exe
to/from my no-gsync profile while neovide is already running does not change its already-running gsync state but will on next launch. Might be useful to know for anyone else troubleshooting.
So that rules out a problem in DirectX because neovide uses Vulkan.. With more modern games, especially UWP-based games, only offering "Fullscreen Window Mode" instead of "Exclusive Fullscreen Mode" I wonder if G-Sync is even doing anything if we don't enable G-Sync for windowed mode.
This bug seems to grow out of scope of this repository though (and every other project where this happens too) so if no one is noticing this and nobody has any kind of contact to someone at Nvidia will this ever get fixed? It would be cool to use Windows and being able to play games with the hardware and features I bought instead of piling a bunch of workounds on my system.
For those using the Nvidia Control Panel / Manage 3D Settings workaround, could you clarify how you added Windows Terminal to the Program Settings dropdown? It's not appearing in the dropdown for me, and I'm not sure how to browse for the executable given it's installed from the Windows Store.
For those using the Nvidia Control Panel / Manage 3D Settings workaround, could you clarify how you added Windows Terminal to the Program Settings dropdown? It's not appearing in the dropdown for me, and I'm not sure how to browse for the executable given it's installed from the Windows Store.
It's been a while since I set mine up, but I believe I just made sure to have the program running when opening the panel, and it either showed up immediately, or I was able to hit "Add" in that screenshot I posted above and choose "Currently running programs" or something to that effect.
Not sure why the MSBOT closed this and all duplicate issues, because adding the setting "experimental.rendering.software": true
in settings.json
was the only way I could "fix" this issue on my machine
Meaning there is something going on with the rendering?
Not sure why the MSBOT closed this
This issue has not been closed, and it will remain not-closed until we can figure out a solution for people with dysfunctional graphics drivers. For now, software rendering or telling the graphics stack to not treat Terminal like a game is that workaround.
Not sure why the MSBOT closed this
This issue has not been closed, and it will remain not-closed until we can figure out a solution for people with dysfunctional graphics drivers. For now, software rendering or telling the graphics stack to not treat Terminal like a game is that workaround.
Unfortunately I also wasn't able to fix this through my dysfunctional graphics driver settings. It's not appearing in the Nvidia Control Panel/Manage 3D Settings/Program Settings dropdown for me either.
The setting "experimental.rendering.software": true
in settings.json
fixed it for me as well on Nvidia RTX 2080. I feel this is the preferred solution over changing global settings in Nvidia's Control Panel.
UPDATE:
I'll take that back as. If you have two monitors: one with G-Sync high refresh rate and one with basic 60hz, putting the terminal on the 60hz screen will still cause all apps on the high refresh rate screen to run sluggishly.
ANOTHER UPDATE:
Using the setting "experimental.rendering.software": true
, and updating Windows 10 to v 2004 fixed it for me.
It's not appearing in the Nvidia Control Panel/Manage 3D Settings/Program Settings dropdown for me either.
It does not automatically appear in the dropdown, but it should appear in the detected applications list after pressing "Add" next to it.
It's not appearing in the Nvidia Control Panel/Manage 3D Settings/Program Settings dropdown for me either.
It does not automatically appear in the dropdown, but it should appear in the detected applications list after pressing "Add" next to it.
Unfortunately, it does not appear there either.. :/
Having the same issue with version 1.0 and gsync - framerate drops to about 40 fps, and monitor is flickering. makes windows terminal almost unusable
update: "experimental.rendering.software": true
seems to work fine with Windows 2004
@robert-sandor As mentioned above in this thread, some users have had success with the setting "experimental.rendering.software": true
.
@robert-sandor As mentioned above in this thread, some users have had success with the setting
"experimental.rendering.software": true
.
I have two 1070ti's in SLI, driver v446.14, and an Alienware AW3420DW at 120hz on the desktop. I was also experiencing the reduced frame rate issue. Adding this setting to the config resolved it.
Adding
"experimental.rendering.software": true
in settings.json on Windows Terminal Release Candidate v0.11.1333.0 (1.0rc2) resolves this issue for me.I assume I incur some level performance loss but I don't feel it on my machine.
This fixed it for me. When can we expect this to be outside of experimental @zadjii-msft? FYI: 2 monitors, 1 144hz Gsync the other 60hz
My workaround of bypassing the store by extracting the package to my own folder and running WindowsTerminal.exe
directly has been 100% reliable for the past two weeks in terms of allowing an Nvidia profile to force-disable Gsync there. Leaving Gsync globally enabled and force-disabling it in specific apps like this is still my preferred solution. Degrading to software rendering seems undesirable.
I've tried a broad variety of other apps and scenarios on the current Nvidia driver version 446.14
. Windows Terminal specifically installed via Windows Store is the only one I've encountered with this combo of 1) Gsync kicks in, 2) is undesirable, and 3) an app-specific Nvidia driver profile fails to disable it. This is including UWP games (eg. Astroneer - Astro-UWP64-Shipping.exe
) installed via the Windows Store. That seemed a useful point of comparison for the packaging/permissions/delivery situation but Gsync kicks in there, works as I'd expect, and can still be disabled via an app-specific profile.
"experimental.rendering.software": true fixed it for me.
1080Ti with latest nVidia drivers as of this date, and Windows 10 2004.
What is the latest official word on this issue? I would prefer to use my CPU cycles elsewhere.
Thanks for the solution guys.
Software rendering is still fairly performant: we are standing on the shoulders of giants, and we still only render regions of the screen that have changed. While it’s not accelerated, it’s the next best thing.
"experimental.rendering.software": true also fixed it for me.
1080 with the latest NVidia driver on Windows 10 Pro Build 2004.
Does this method have any performance issues? Because as far as i can see i had no issues so far.
"experimental.rendering.software": true also fixed it for me.
1080 with the latest NVidia driver on Windows 10 Pro Build 2004.
Does this method have any performance issues? Because as far as i can see i had no issues so far.
So far so good.
I had turned off gsync windows terminal preview well in before but I can't find windows terminal after driver clean update. And software rendering is not good way to fix because I want GPU accelerated term :(
Is there a way to manually add windows terminal to not use gsync? putting exe doesn't work for uwp I think.
Adding "experimental.rendering.software": true
also helped me. Running Windows Terminal 1.0.1401.0 using GTX 970 (Nvidia driver 432.00).
This issue isn't specific to Windows Terminal. I also had to set an experimental flag for Ableton Live and disable hardware acceleration for Spotify.
I can confirm what @krage is saying about the profile override not working in the case of Windows Terminal installed via the windows store. Something with UWP apps in general doesn't seem to play well with Nvidia profiles. I switched from using the windows store install of terminal to one managed by scoop (essentially mimicking the method @krage is using) and my Nvidia profile is correctly applied.
My Nvidia profile for Windows Terminal uses the following settings:
These settings resolve the issue for me.
I can also confirm that enabling "experimental.rendering.software": true
fixes the issue. But I'd rather use hardware based rendering.
Hardware:
Versions
By the way, I've recently investigated whether this issue can be solved and the short answer is: Yes, but primarily no. Yes, the issue can be alleviated, by doing the following:
DXGI_SWAP_CHAIN_FLAG_ALLOW_TEARING
and DXGI_PRESENT_ALLOW_TEARING
flags as explained hereBUT I'd argue that this would be a bad idea to do, which is why I didn't submit a PR in the end. Because if you do all that, every non-Nvidia user will now also draw at the full frame rate of their display, which is simply unnecessary. In my humble opinion Nvidia must fix this particular issue on their side, because it isn't just present in Windows Terminal, but rather all UWP apps which use DirectX.
And on top of that the "Enable for Windowed and Fullscreen Mode" setting in the Nvidia Control Panel isn't the default setting either and has been known to break a lot of stuff in the past (which - I'm sure of - is why it isn't enabled by default in the first place). 🙈
Basically this all comes down to an nVidia issue/bug regarding DX11?
I recently got a new monitor (LG27850) and there is no more flickering, but I can feel the 60hz vs 144Hz difference when I Alt-tab from the terminal to another program and it feels funny.
@KrunoSaho I can't proof it and I could be wrong, but I'm fairly certain... You can try all the "D2D" (Direct2D), "DWrite" (DirectWrite) and "DX" (DirectX) samples here and you'll notice that all of them show the same issue as Windows Terminal does. The only UWP+DirectX app I ever found that doesn't have the same issue is the App Store version of Minecraft. As such I believe that the underlying issue is Nvidia's heuristic, which decides whether a process should use GSYNC.
Everyone who doesn't strictly need it should disable "Enable for Windowed and Fullscreen Mode":
In my humble opinion this issue can be closed, as this behavior isn't present when using AMD GPUs, sort of ruling out the possibility of a bug in Windows Terminal or Windows in general.
Unfortunately we enabled the "Enable for windowed and full screen mode" setting because we strictly need it. If I don't do that, the windowed mode games won't be using G-SYNC at all. So that option is a must. I also had this issue with Photoshop, but at least my disfunctional nvidia driver let me choose a fixed refresh rate for that app simply by appearing in the list of apps to choose from.
So if nothing else, if you could just make the terminal app appear somehow/magically in the list of apps of nvidia control panel 3d settings I would be more than happy.
I have submitted a bug report to nVidia about this. We will see what happens, if anything.
@electrofloat I haven't been successful yet at reproducing that bug yet... For me it shows up:
...and it properly allows me to change the "Monitor Technology", which fixes the issue. If it doesn't show up for you try to create a shortcut to the Terminal app on your Desktop, by dragging & dropping the app from the start menu onto the Desktop.
I already start the terminal through the desktop shortcut, and that does not make it appear in the list of recently used apps unfortunately. :(
@electrofloat Try restarting your PC. Nvidia caches that list within their driver the first time you open Program Settings.
@lhecker I've read the same thing, but also refused to send in a PR. But the more I think about it the more I change my mind... As far as I know you can detect Nvidia and even query for G-Sync and this is not a workaround according to the docs but the way it is supposed to work. Remember AMD guys would benefit from this as well because G-Sync and FreeSync are interchangeable.
To be fair it's a chicken egg problem. AMD clearly can handle this situation with thier drivers, Nvidia can't. With tight schedules it's easy to say yea screw Nvidia and let them fix the Problem. One can also argue that actually the Nvidia driver is fine the software just doesn't query and provide the functionality that the user wanted.
I just think it's kinda sad that there is a way to fix the issue by implementing something someone at Microsoft already documented. And this problem doesn't only happen with the Windows Terminal but with a lot of UWP and WPF apps as well
@electrofloat You can try searching for the executable using the browser in the add menu. It can be found somewhere under C:\Program Files\WindowsApps
and you may have to tweak the permissions of this folder. I also couldn't make it appear on the list.
Note that this didn't actually help in my case, and my options are to disable G-Sync in windowed mode (no thank you) or use the experimental flag (this helped).
I've also observed that sometimes this issue resolves without any intervention using the default settings.
Can confirm this isn't specific to Windows Terminal on my machine.
@SirJson tl;dr: You got it the wrong way around... Windows Terminal (WT) explicitly shouldn't render at a variable refresh rate (VRR). This isn't about how we can support G-SYNC, but rather about how we can best disable it.
WT doesn't capture mouse input like games do and should properly integrate with the window manager and the rest of the OS (cursor movement, drag & drop, etc.). It should also be energy efficient which means that running at full FPS is quite counterproductive. Chrome for instance will throttle down to not render at all if it doesn't need to. In order for WT to render at 165 FPS on my relatively beefy PC it uses up almost an entire CPU core alone on the other hand.
If your graphics driver decides that a application wants VRR it'll put the entire render pipeline (for the screen the application is visible on) into a VRR-mode. If that one, single application draws at a low FPS, your entire screen will draw at that FPS, including the window manager, your mouse cursor, etc. - everything basically! This is the primary reason why VRR is only enabled for fullscreen application, or applications that capture the mouse cursor like games do. Nvidia's heuristic works for almost all regular applications. Regular .exe like Firefox, Chrome, VS Code are all correctly detected as non-G-SYNC. UWP apps like WT, Slack (yes even Slack!) are incorrectly detected as ones who want G-SYNC. This clearly a bug on Nvidia's side.
Lastly it's not even guaranteed that WT's DirectX renderer is fast enough to provide those >120 FPS you're looking for. If it ever fails to do so, your entire screen will feel sluggish due to the above reason.
In summary, WT shouldn't render with VRR and if anyone has an idea how to make Nvidia's driver detect WT as an application that wants G-SYNC, please let me know and I'll implement it! I know it's possible somehow, because, again, UWP Minecraft is one of the very few UWP applications which are detected correctly as non-G-SYNC.
What puzzles me coming from a game developer background, and sorry if this is a stupid question, why is application loop tied to the renderer? In a game no one would do this even long before we had G-Sync cause if a system can't handle one heavy scene for example the internal logic should continue without even tho the rendering is slow.
When I then think about how it even makes the cursor choppy I wonder what is happening in the background cause with my mental model the OS cursor was a separate thing from the graphics application running. It's almost like G-Sync is slowing the whole compositor down.
But I digress just telling G-Sync to shut up is also a solution, it's not like it would have a place inside a terminal anyways. But how to do that from application code I don't know.
@SirJson I believe there are still quite a few places left for optimization in the renderer. But you need to consider that games aren't designed to be energy efficient, which is why they get away with using, let's say, 10% of your potential CPU power at all times. As a terminal this shouldn't be the case of course, which is why we'd like to to throttle the rendering loop as much as possible. The reason your mouse cursor gets choppy is because WT is recognized as a VRR application and your display frame rate gets synchronized with WT's. Now if WT renders in an energy efficient way (meaning: seldom / if needed) WT's frame rate drops down to around 3-4 FPS, which causes your entire display's frame rate to drop to 3-4 FPS.
Yea I agree, would be stupid to render the same text 144 times just because we can.
Regarding the G-Sync exceptions I assume that's hard coded in the driver. When I open my profiles in the NVIDIA Control Panel I see automatic profiles for Chrome, Firefox.. etc and they are all correctly setup like people are doing it here manually. That would mean until someone over there wakes up and builds a profile into the driver or actually fixes G-Sync there is not much we can do.
I'm curious now what happens with AMD on the same monitor and system. After all there is a reason why I'm running this GPU setup and if Windows insists on installing the AMD drivers again again and again I might as well test this now. I wonder if AMD even allows FreeSync in Windowed Applications..
Did anyone find a way to add it to the list of apps in Nvidia Control panel?
Doesn't come up at all for me :/
Yeah, click Add -> Browse and go to C:\Program Files\WindowsApps\ There should be a folder called something like Microsoft.WindowsTerminal_1.0.1811.0_x64__8wekyb3d8bbwe
.
The exe is inside.
This method is better though: https://github.com/microsoft/terminal/issues/649#issuecomment-647617350
@SirJson: Yea I agree, would be stupid to render the same text 144 times just because we can.
A high frame rate may be required if the same text can suddenly move, I don't know if a modern monitor can instantly change the frame rate to the required frame rate to move text smoothly like in applications like this (use WSL profile to enable mouse tracking) :
ssh vtm@netxs.online
netxs-group/VTM#9 With this application, you can test terminal performance by manipulating text content with your mouse using any frame rate.
Yeah, click Add -> Browse and go to C:\Program Files\WindowsApps\ There should be a folder called something like
Microsoft.WindowsTerminal_1.0.1811.0_x64__8wekyb3d8bbwe
.The exe is inside.
This method is better though: #649 (comment)
Yeah, using that one for now. I tried making a profile via that method, but it doesn't work. So SW rendering it is for now.
I also had trouble with setting an Nvidia profile for my UWP app. I installed Terminal via scoop, and still couldn't get it to apply a profile. In the end I used https://github.com/Orbmu2k/nvidiaProfileInspector as suggsted by @krage and made sure the profile was nice and simple: re-did the association to windowsterminal.exe, and only modified one value, the G-Sync Application State one
Et voila! 155Hz Terminal 😎
@jalada Sorry but that method is also not working for me :(. Looks like using software rendering is the only option. I'm using The preview version of terminal btw.
After a long period and giving nVidia my msinfo32 report they are saying that they are looking into it.
Hello Kruno,
Thank you. We are looking into the issue. No further updates at this time.
Regards, Josh NVCC
Now we play the waiting game.
@o-sdn-o But that's a benchmark if I understand it correctly and not your typical use case. I try to see it from a practical perspective and I use a 144hz monitor daily. And tbh I have yet to find a terminal application requiring 144 FPS that is not a demo or cool effect.
The problem I see is if I want to play a game in windowed mode or new recommended "fullscreen windowed mode" but also use G-Sync without breaking Windows at the same time. Remember this is not only happening with the Windows Terminal but also for example in Microsoft Whiteboard and other UWP apps.
What confused me was the that the cursor of all things gets detected as "variable refresh rate application". To me all of that sounds like something Nvidia should look into.
Worst case, fork it, unlock the frame rate and do what ever you need to do. But it wouldn't solve the system wide issue.
Yeah, I agree entirely with @SirJson, Nvidia needs to fix their drivers by excluding this App. It's not really a problem that originates from Windows Terminal.
I feel like I need to clarify again, that G-Sync is Nvidia's implementation of a "variable refresh rate" (VRR) for your monitor. The important bit here is "your monitor", because the refresh rate is not per application. If any application causes G-Sync to be enabled, that entire monitor will now render at the speed of the G-Sync-causing application. Your cursor doesn't stutters when using UWP apps with G-Sync because the cursor is being detected as a VRR application, but rather because your entire monitors' refresh rate has been dynamically lowered. The reason for this is that desktop applications - like Windows Terminal - almost always only draw when necessary, which results in a low application frame rate, which G-Sync finally turns into a low refresh rate of your monitor.
Well that makes that whole feature pointless doesn't it? I assumed what my monitor is reporting, the constant 144hz, is the refresh rate of the display as a whole and trough maybe tricks with the compositor they implemented this feature.
Lucky if I have time for gaming, that one game I'm playing right now supports true full screen, I didn't touch this option for months now because of "what happens" and had zero issues with it. To be honest originally I stumbled upon this issue because my old display can be also forced to do g-sync @ 60hz (which is even more point less but hey I was curious what would happen)
To anyone having issues and don't want to use software rendering I can only recommend that you do what I and others did more than 130 days ago and hope that NVIDIA will find a solution cause the push away from true full screen is pretty clear.
Thanks @lhecker for clearing things up, for me at least
Adding
"experimental.rendering.software": true
also helped me. Running Windows Terminal 1.0.1401.0 using GTX 970 (Nvidia driver 432.00).This issue isn't specific to Windows Terminal. I also had to set an experimental flag for Ableton Live and disable hardware acceleration for Spotify.
This fixes the issue for me using 2080ti and several 165hz GSynced displays
My main monitor is 144Hz. An easy way of seeing the current FPS is wiggling the mouse - the movement in 144 FPS is much smoother than 60 FPS, and this is very noticeable.
While using Terminal, the FPS constantly drops, and moves between low FPS and full 144 FPS. I can't tell if it drops to 60 FPS or a different amount, but it's way lower than 144 FPS. Wiggling the cursor while typing shows this problem well.
It seems like every interaction with the Terminal can cause the FPS to "flip" between low and high: Focusing on the window, typing, etc. Sometimes waiting ~3 seconds is enough for the FPS to switch back to high.
Graphics card is an
Nvidia GTX 1080 Ti
and monitor is anAsus PG279Q
.