Discussion in 'Videocards - NVIDIA GeForce Drivers Section' started by Hilbert Hagedoorn, Sep 28, 2020.
Hrm, just screenshots taken through GFE right? its fine with printscreen?
If you mean native print screen then I don't think it's supposed to capture it, at least in FSE mode (or can it even capture game screenshots in FSE mode in Windows 10?) but it does capture it properly when game runs in windowed/borderless.
Steam Overlay was never able to capture Freestyle'd or sharpened picture anyway so it's not relevant here, but ShareX captures sharpening effects properly even in FSE mode.
So this only affects GFE screenshots, Shadowplay recordings have no issues with capturing post-processed frame.
Oh and I remembered that Dota 2 also has OpenGL render, so I tested that and GFE screenshot properly captures sharpened frame. So it's only DX9 that seems broken. Well, maybe DX10 too but I don't think I have any games that use it to test it properly.
im thinking what the issue is, being that Sharpening is actually just a reshade filter and applied after others - is that GFE's hook and thus capture is of a layer before the sharpen filter is applied.
thanks for updating the drivers, but why do we have to install GFE... Shadoplay...
You don't, unless its already installed in which the first radio dial screen is skipped.
Could be. I'm think this wasn't the case on 442 drivers and only started after sharpening was fixed in 452 drivers (after 445 broke it with optimus) so it's probably related to those changes.
Obviously it's nothing gamebreaking and at least sharpening kinda works in all games now but it's a bit annoying when screenshots differ from what you actually see on screen. Of course I can use ShareX as a fallback but I already have GFE installed so I'd rather use that.
Although I wonder why there's such a big difference in sharpen quality depending on the API used between control panel sharpening (especially in DX9 mode) and Freestyle sharpening (which is consistent between the APIs), and whether it's relevant to tracing this particular bug. Also quite weird to not have consistency between Freestyle and Control Panel in this regard, is it just because of different injection methods? Not sure if this difference was present in 442 branch.
Very odd. I don't have any problems with any Unreal Engine 4 games whatsoever, including the ones you mentioned. I did have some problems with Arkham Knight stuttering with PhysX enabled (PhysX set to the GPU via control panel) a couple of drivers back, but since that was fixed in the drivers I haven't had any problems. I do have a different system configuration than you, though, the differences from what you've posted is that I'm running an Intel CPU still, a 2080 Ti with 64GB RAM on a 3840x2160 VRR panel with G-Sync compatible enabled. I'm on Windows 10 2004 with all the latest Updates installed.
If you haven't done so already, try running DDU in Safe Mode to clean your Nvidia drivers and reinstall the 456.55 drivers, in case any leftovers from previous, buggy drivers are causing your issues.
Here is a funny thing, yesterday I got like 3 Broccoli CTD crashes in Destiny2, in end I downclocked 1 boost step.
Today I raised voltage for 1 step, so it boosted 1 step higher >> 1404 to 1418mhz, but it frequently dropped back to 1404mhz and vram for 200MHz offset and surprisingly no crashes as of yet.. I played 3hrs straight with few alt+tabs to desktop and back.
In both cases I used this driver, I upgraded to this driver since 451.85 started to crash too few times and it pissed me off.
So, what gives?
This set is way smoother and faster than 456.38, playing Witcher 3 atm.
Honestly this video deserves its own thread, but I'm sure most people that need to see it will see it here anyway. Otherwise regularly active members like @Astyanax can link it when needed. This is for all the misinformation that has been going on for over a week about the RTX 3080's. This driver fixed those issues.
fs working with vertical sync turned off
The "[G-SYNC]: With G-SYNC enabled on some Freesync displays, half of the screen goes black. " bug, is this the same as my display showing half a screen garbled (or white), rarely, when it wakes up from monitor sleep if Gsync Compatible is enabled? Curious.
I get 3d clocks and 125w idle on my EVGA 3080 XC3 w/latest firmware in Windows 10 Desktop with 0-1% gpu usage reported. Changing the windows power setting to balanced or the nvidia control panel power setting to Adaptive vs Prefer Maximum performance and rebooting has no bearing on this behavior. I am running at single 3440x1440@100hz DP display w/Windows 10 2004 build.
I only see this issue on the 3080; a driver clean install and going back to my 2080 card restores proper idle behavior. I have mitigated for now with a custom fan curve with a minimum of 60%, but it would be awesome if this could be fixed in the next driver.
threads from evga forums:
I am experiencing a very similar issue with my 1080ti.
Last night my card was operating normally, idling at 139mhz on the desktop. Played Breakpoint for a couple of hours without issue then called it a night for gaming. 10 minutes after quitting noticed my card was running at 1556mhz idling on the desktop. Checked task manager for the usual suspects but nothing amis.
Tried via AB to return the card to stock clocks, nope, restarted and tried again, nope, restarted in safe and DDU nuked the driver and profiles. Restarted and clean installed the driver (including GFE) also enabled experimental features.
Prior to clean driver installation I uninstalled AB + Rtss and cleaned all traces, reinstalled AB + Rtss.
AB reveals my 1080ti is still idling at 1556mhz on desktop. What the hell is going on?
I have not touched OC scanner in any capacity due to documented incompatibility with my Gpu.
How do I get my gpu back to 139mhz idle or is this a driver bug?
The elevated clock causes no heat concerns as its cooled by an NZXT X52 240mm rad AIO (139mhz idle @ 22 deg C, 1556mhz idle @ 29 deg C). It just doesn't sit right with me, if you get what I mean.
*** Update ***
Tried the 'Revert' button (AB OC Scanner) but it had no effect on the idle clock...
*** Stock ***
*** Update 2 ***
Ok, 5 minutes ago my card just decides to laugh in my face & downclock itself to its correct stock speeds with AB profiles in place as is the norm. I was just sitting on the desktop in a world of my own (you know!) when I saw the downclock out the corner of my eye on my second monitor.
Is this some kind of AI assisted clock monitoring/voltage control implemented in this driver? I make a wild guess based on what @Unwinder has written with regard to the way NVidia's new OC Scanner API is implemented.
Given that the new API makes semi-permanent changes to the stable reference clocks for both GPU + Mem for that particular GPU when stable clocks are acertained by the driver not user, changes that persist through both driver uninstallation, DDU uninstallation & AB Removal & cleaning. The only way to revert is to use the 'Revert' button within the OC Scanner window or reinstall a driver that is pre 455.xx.
My card however seems to have done this of its own accord given the screens I have provided.
Is this intentional behaviour from the NVidia driver or is it a bug with the new API running on my 10 series card?
Something is definitely off with these that's been bugging me since using them. I'm getting noticeable framerate dips, and occasional split second pauses in AC Odyssey and GTA V. Went back to 452.06 and tested out the same scenes and its back to normal. I also noticed these were causing my idle GPU speeds to randomly spike for no reason. These definitely don't like my card.
I'll link it for people on 455.38 who can't believe a driver updte might fix it, but won't for those on 455.55 where crashes persist
Not sure if it will help but back last year when I was trying to get NR2003 to run on win 10, I had to download a modified d3d9.dll file from a website. I can't remember which one in particular but it functioned perfectly for my needs. Not sure if you would want to try it and I can't remember what site it was on but googling modified d3d9.dll for NR2003 should get you pointed in the right direction.
Hey. I noticed this "green bug". Everything is fine in other browsers. Is this a problem in Chrome or in the drivers?