ZDoom / Raze

Build engine port backed by GZDoom tech. Currently supports Duke Nukem 3D, Blood, Shadow Warrior, Redneck Rampage and Powerslave/Exhumed.
668 stars 59 forks source link

[BUG] [General] Graphical corruption on Windows with latest drivers #92

Closed mjr4077au closed 3 years ago

mjr4077au commented 3 years ago

Lodging here from Discord. Below is what a user gets. He's using a GTX 1060 and I can corroborate this with the latest drivers on my GTX 970.

image

coelckers commented 3 years ago

Oh my, NVidia has surely dropped the ball this time. Is this only for palette emulation mode or general?

mjr4077au commented 3 years ago

I've seen it on both modes. Basically just shake the mouse around and the corruption goes away. It's only on the initial viewport of a fresh load.

Phredreeke commented 3 years ago

Interesting. Someone in the BuildGDX Discord said they had similar issues with palette emulation in that port on latest NVidia drivers.

coelckers commented 3 years ago

What does GZDoom say? I am surely not installing such a broken driver.

sinisterseed commented 3 years ago

I've been experiencing this for quite a while now, mentioned this before but I couldn't get Graf to reproduce it as well, so it still exists as a result.

No idea if it's a driver issue, I've not had this nonsense happening in 0.6.0, not to this extent anyway - I could sometimes notice this randomly when pausing the game in SW, but it was never this bad. Now it's somewhat of a common occurrence. It goes away by simply moving around, but it seems to trigger randomly. Sometimes I see it, sometimes I don't.

It's unrelated to palette emulation and other graphical settings I think, I can see it on various configurations. Never had this happen in GZDoom though, or EDuke derivatives or GDX for that matter.

I'm on driver version 446.16.

mjr4077au commented 3 years ago

Sounds like this will be a wild goose chase. I won't be at home for ~36 hours but will test GZDoom out properly then and might go between a few driver releases to find out where the issues started. Perhaps then NVIDIA's release notes might give an indicaton.

mjr4077au commented 3 years ago

FWIW, on Linux with NVIDIA's binary blob propietary driver, I wasn't able to replicate this.

coelckers commented 3 years ago

I'm on 445.75, never had any problems with it.

mjr4077au commented 3 years ago

~446 like sinisterseed has said is probably around the time it started. I'm into the 45x.xx versions now and it's no better.

sinisterseed commented 3 years ago

This is gonna be a bitch to troubleshoot I think, as I said, it also seems to vary in intensity between our builds. In 0.6.0 I've never seen it so aggressive, so I wonder if it isn't a change we made somewhere that makes the render explode.

coelckers commented 3 years ago

Yes, it's gonna be a bitch. I just tried the latest driver anyway, after making sure I have the old one for rolling back - and it works fine. I wouldn't be surprised if this is some Windows 10 fuckup by Microsoft.

sinisterseed commented 3 years ago

Wouldn't be too sure about that. I would expect other GL based apps to exhibit similar issues unless it's something very specific, and Raze is the only one to exhibit this corruption.

mjr4077au commented 3 years ago

I'm on Windows 10 Enterprise 2004 (thanks, work!). Not sure what build everyone else is on.

coelckers commented 3 years ago

The corruption suggests to me that something's going wrong in postprocessing of the 3D scene, not normal rendering. However, not being able to reproduce it I'd need a higher resolution screenshot - this one's too small to make out any potential hints.

sinisterseed commented 3 years ago

Version 1909, build 18363.1082. Haven't updated to 2004 yet.

sinisterseed commented 3 years ago

Here's SW, now in glorious 1080p corruption:

ShadowWarrior_0000

coelckers commented 3 years ago

That looks really - interesting, especially how the corruption aligns with the sword sprite. And since the area below the sword is not corrupted it's a clear indicator that it's not happening in the scene renderer but the postprocessor or the rendering of the weapon sprite itself.

sinisterseed commented 3 years ago

That looks really - interesting, especially how the corruption aligns with the sword sprite. And since the area below the sword is not corrupted it's a clear indicator that it's not happening in the scene renderer but the postprocessor or the rendering of the weapon sprite itself.

The whole screen was actually corrupted, but the movement of the sword's draw animation erased a part of it, which is why that portion is clean but the bottom right corner still exhibits some corruption.

As I said, the movement of the player's view port erases it, but in the instances where the corruption is observed when starting a game, some random, tiny white dots may also appear on the screen when the player stops moving, after playing for a bit, despite cleaning the initial corruption, which go away with more movement.

coelckers commented 3 years ago

The whole screen was actually corrupted, but the movement of the sword's draw animation erased a part of it, which is why that portion is clean but the bottom right corner still exhibits some corruption.

That makes even less sense, unless it accessed some uninitialized backbuffer and doing 2D stuff clears that buffer.

sinisterseed commented 3 years ago

It is what it is 😉 , I can only tell what you're seeing.

coelckers commented 3 years ago

Do you by any chance have gl_ssao enabled?

sinisterseed commented 3 years ago

Doubt it, I never touch AO since I know it doesn't work right currently.

Regardless, I'll check this in the morning, but if the default is off, it should be off.

EDIT: Yeah, it's always off - "gl_ssao is set to "0" ".

sinisterseed commented 3 years ago

The number of users experiencing this is slowly increasing, Jarolf of DW brought this up recently too: https://www.doomworld.com/forum/topic/111839-source-port-introducing-raze-thats-one-duked-up-space-marine/?do=findComment&comment=2195884

https://static.doomworld.com/monthly_2020_09/1097432821_03-FSCorr.png.3effb74296e87333e879ac9916b9f922.png

coelckers commented 3 years ago

This looks more and more that some postprocessing buffer is not getting cleared before reuse. Unfortunately it only seems to happen on Windows 10 and not on Windows 8, so I cannot get it reproduced on my own setup.

sinisterseed commented 3 years ago

It's all the more curious insofar as it didn't happen in 0.6 either, which makes me think it's a change we made somewhere that now no longer plays too well.

And also never happening in GZDoom.

mjr4077au commented 3 years ago

I'll be doing a significant amount of backtracing for #98 tonight to see whether we've ever had this working with the rebase so if I notice a demarcation point I'll be sure to advise.

sinisterseed commented 3 years ago

Any ideas where to start? Because if we take that route, this is going to be a real bitch to troubleshoot.

We essentially have to go back some three months, and even there, who knows where to start looking.

mjr4077au commented 3 years ago

For #98 I'll be going back to the first usable commits and will see what the go is. If it works fine, I'll go half way between then and now. If it works from there, go half forward again otherwise half back and just keep working it until I get to the issue.

For something like this issue, I don't recall it happening before the main loop cutover so I'd probably be starting there.

sinisterseed commented 3 years ago

Yeah, same here, after the main loop transition it became rather frequent.

Some level of corruption existed even before though, but never in such intensity, which makes me think the main loop just made a core issue more noticeable rather than introducing it.

mjr4077au commented 3 years ago

Some level of corruption existed even before though, but never in such intensity, which makes me think the main loop just made a core issue more noticeable rather than introducing it.

Agreed. During some testing, I couldn't get these issues to happen on the old main loop, however I can't reliably make it happen on demand to 100% conclusively validate that something is wrong there. Happens on fresh or old configs, happens when I'm not trying to make it happen and never when I am.

I've already mentioned it but it also doesn't happen under Linux using NVIDIA's 455.23.04 driver which aside from the OS interface should be near 1:1 with the Windows NVIDIA driver.

I'm wondering whether it's some Windows Update issue that's caused the problem perhaps? I get we're on different versions (1909 vs. 2004 like I am) however they're both still within their support period by Microsoft and both get updates. I still need to try an older NVIDIA driver and see if that helps.

Unfortunately it only seems to happen on Windows 10 and not on Windows 8, so I cannot get it reproduced on my own setup.

Windows 8? C'mon bruv! :laughing:. Genuinely like it or CBF'd to reformat?

coelckers commented 3 years ago

Hey, I bought a good system in 2012, it's still working well enough so I have no need to pay $$$ for Windows 10. This is running on a MSDN version from my former employer which I cannot upgrade.

sinisterseed commented 3 years ago

Hey, I bought a good system in 2012, it's still working well enough so I have no need to pay $$$ for Windows 10. This is running on a MSDN version from my former employer which I cannot upgrade.

You know you didn't have to, and actually still don't, if you know-how, right 😉 . Between W10 from version 1909 onwards and 8/8.1 I would never go back honestly. 10 is just so much better and a lot of the hatred it received is totally unwarranted.

BTW more goodness:

ShadowWarrior_0000

coelckers commented 3 years ago

You know you didn't have to, and actually still don't, if you know-how, right 😉 . Between W10 from version 1909 onwards and 8/8.1 I would never go back honestly. 10 is just so much better and a lot of the hatred it received is totally unwarranted.

To make it abundantly clear: I won't install a pirated Windows version on my system. I am working in a company with close ties to Microsoft and I use the computer for professsional work, so I think you can do the math what might happen if it ever came out if I used something not 100% kosher.

sinisterseed commented 3 years ago

You know you didn't have to, and actually still don't, if you know-how, right 😉 . Between W10 from version 1909 onwards and 8/8.1 I would never go back honestly. 10 is just so much better and a lot of the hatred it received is totally unwarranted.

To make it abundantly clear: I won't install a pirated Windows version on my system. I am working in a company with close ties to Microsoft and I use the computer for professsional work, so I think you can do the math what might happen if it ever came out if I used something not 100% kosher.

And what makes you think I was suggesting that? I said there's still a way to get it free, and I meant just that when I said it, it had no piracy undertones. The method I was talking about is completely legitimate.

You're reading into something that does not exist. For reference, I actually paid for mine when I got my current PC, I purposefully missed the free upgrade period because I would've ended up with a 32-bit copy, and 32-bit is useless nowadays.

coelckers commented 3 years ago

No, I cannot get a free upgrade. My Windows comes from an old, expired MSDN account and any upgrade is blocked.

sinisterseed commented 3 years ago

Well that's a shame then.

markanini commented 3 years ago

Does it go away when disabling Anisotropic filtering in Nvidia control panel?

coelckers commented 3 years ago

What prompted you to make that suggestion? Personal experience or do you have a link for an explanation?

markanini commented 3 years ago

Because BuildGDX users are experiencing a similar corruption that's solved that way, according to Discord. No promises, I don't own a Nvidia GPU so I cant test it out.

coelckers commented 3 years ago

That's really interesting. The renderers are totally different so it's a bit puzzling that both engines are showing problems with recent NVidia drivers.

Too bad that Vulkan currently does not work. It'd be an interesting case to test otherwise.

sinisterseed commented 3 years ago

Because BuildGDX users are experiencing a similar corruption that's solved that way, according to Discord. No promises, I don't own a Nvidia GPU so I cant test it out.

Most curious, I've never experienced any corruption in GDX.

markanini commented 3 years ago

Here's what it looks like in GDX: https://i.imgur.com/dyzwWXT.png

coelckers commented 3 years ago

That's interesting. I witnessed a similar corruption like can be seen on the weapon and HUD once when drawing a palette emulated 2D sprite but wrote it off as a shader bug that needs to be investigated. So, does the corruption here and in GDX only happen in palette emulated mode or also in true color mode? The one on the 2D elements looks like a texture sampling error for sure and all Raze screenshots only have corruption on the 3D scene but not the 2D elements that are drawn in true color.

markanini commented 3 years ago

So, does the corruption here and in GDX only happen in palette emulated mode or also in true color mode? Only in palette emulated mode.

coelckers commented 3 years ago

NVidia declaring war on retro gamers...? 👿

sinisterseed commented 3 years ago

Not palette emulation specific for us. I saw it well before PE became functional again.

Mark did mention anisotropic filtering too. I wonder if that plays some role in this.

mjr4077au commented 3 years ago

Same as sinisterseed, happens on either for me. Still perplexed by it not happening on Linux with the NVIDIA driver as well.

sinisterseed commented 3 years ago

And apparently not on 8.1 either - not the GDX corruption, ours.

This is starting to make me wonder whether something changed in 10 behind the scenes, but I can't even begin to guess what. I don't recall any major update bringing changes to the APIs. Only the WDM went through some version bumps and revision to enable new features and add support for RTX, HDR, and that sort of thing, but nothing else.

coelckers commented 3 years ago

I got the same effect as on the 2D elements in the GDX screenshot on 8.1 as well. It also makes sense that anisotropic filtering may make a difference. With the new info I can day that this thing is most definitely a sampling error from the palette textures. It at least gives some hints at where to look for a solution. Since EDuke32 does not appear to be affected - at least it was never mentioned - it may give some hints.

sinisterseed commented 3 years ago

And also, the corruption is truly on the entire screen for us when it happens, but having elements drawn on top of it prevent its cleanup.

Case on point: Last time I had it in SW I figured I would scroll through the HUDs, and the more you know, after I cleaned the corruption on my screen and switched to the no HUD display mode, there was corruption behind the status bar too, which I had to clean manually.