Using the viewport stretch mode and resizing the window (or using "shrink" value other than 1) results in black screen if MSAA is forced on in Nvidia settings

[Calinou]

Godot version: Git 7d6f210

OS/device including version: Fedora 27, NVIDIA 390.48

Issue description: When the window scaling mode is set to 2d or viewport, setting the display/window/stretch/shrink project setting to a value other than 1 will cause the running project's rendering to break (it will appear to be frozen at the splash screen). If the window is resized by the user, it will turn into a black screen. No errors can be seen in the Debugger dock of the editor.

This also occurs when using the viewport stretch mode after resizing the window, even if display/window/stretch/shrink is set to 1.

Steps to reproduce: After making sure the window scaling mode is set to 2d or viewport, set display/window/stretch/shrink to a value other than 1 in the Project Settings then run the project.

Minimal reproduction project: shrink_bug.zip

---

Update: I can still reproduce this as of 6110bde (Fedora 30, NVIDIA 418.74). When the bug occurs, this appears in the console when Godot is started with --verbose:

ERROR: _gl_debug_print: GL ERROR: Source: OpenGL        Type: Error     ID: 1282        Severity: High  Message: GL_INVALID_OPERATION error generated. Source and destination dimensions must be identical with the current filtering modes.
   At: drivers/gles3/rasterizer_gles3.cpp:123.

[flashyincceo]

I am unable to replicate this bug on macOS 10.12.6 with the latest development version of Godot.

I've tried setting the mode to 2d and viewport, and tried a couple of different display/window/stretch/shrink values, but the issues you are describing never popped up for me.

[akien-mga]

Works fine for me on 3.1.1-stable and 9643b2b on Mageia 7 with both my graphic cards, KDE Plasma:
OpenGL ES 3.0 Renderer: Mesa DRI Intel(R) HD Graphics 630 (Kaby Lake GT2)
OpenGL ES 3.0 Renderer: AMD VEGAM (DRM 3.30.0, 5.1.3-desktop-4.mga7, LLVM 8.0.0)

[daniel-abbott]

I've also been unable to replicate this behavior, using Windows 10 Pro, version 10.0.17134, neither in Godot 3.1.1-stable nor in 7d42ca8 and the GLES3 renderer:
OpenGL ES 3.0 Renderer: GeForce GTX 980M/PCIe/SSE2
OpenGL ES 3.0 Renderer: Intel(R) HD Graphics 530

[Calinou]

I just found out why this is occurring (and why nobody else has been able to reproduce it 😛).

This is caused by enabling a setting in the NVIDIA driver that tries to force MSAA in all applications:

(It generally isn't effective on newer applications, including Godot. However, it helps when running some old games or niche applications that don't feature MSAA settings. For those looking to disable forced MSAA on a per-application basis, this can be done using application profiles.)

The Godot project setting that enables MSAA works fine with the viewport stretch mode otherwise:

I'm not sure if we can fix this issue on our end. Someone with a NVIDIA graphics card on Windows should try to enable the equivalent setting in their driver settings, and see if it causes the same bug.

[clayjohn]

Confirmed! :) Windows 10 NVidia GTX 1050 graphics card. When override MSAA is set it hangs on the splashscreen indefinitely and when resized turns black.

[RicardRC]

Windows 10 Nvidia GTX 1070 confirmed. Exact same sympthoms as clayjohn.

[Calinou]

Are there any resources on fixing this (from the developer's side)? I'm not sure if reporting this issue to NVIDIA would be useful, as forcing MSAA is generally considered to be a legacy feature since it only impacts old applications.

[softgripper]

I just stumbled upon this bug too.

Disabling Antaliasing - Mode inside NVidia inspector "hid" the problem.

So the question is - is this a bug that won't get addressed (too hard to fix), or something that can't be fixed because of NVidia setting.

[clayjohn]

@softgripper It is an NVidia bug. :) If you want something done about it, you can report it to them. We can't fix NVidia software.

Please do file a bug report with them though, the more people that report it, the more likely they are to fix the problem.

[softgripper]

I would, but I'm not clear on what the bug is.

Is it that MSAA is broken for all, or is it that Godot can't use NVidia's MSAA?

[clayjohn]

@softgripper NVidias MSAA override setting (in the driver menu) breaks window resizing in Windows 10.

[Calinou]

Interestingly, I ran into the same issue in Quake3e while testing a suggestion in this issue. So it seems Godot isn't the only software impacted by this bug.

[NoodleSushi]

I'm having the same issue for Godot v3.2.2.rc1.official GLES3. Whenever shrink != 1, Godot gets stuck on the splash screen. I changed my preferred graphics processor from "High-performance NVIDIA processor" to "Auto-select", and it doesn't get stuck anymore.

[amedley]

I know this is not ideal, but I just tried setting it to GLES2, and it works great! For my game, this is perfectly fine (we don't explicitly need GLES3), and I'm pretty sure for most devs using shrink != 1 this is probably true. However in the case that someone really does need GLES3 and they are using shrink != 1, this is a huge issue, even just some way to detect on the client that this happens would help, because instructing the user that they need to modify their NVidia settings is virtually impossible (unless you bundle a windows specific executable that runs as a child process to check this ahead of time).

[Calinou]

clayjohn may have found the cause of this bug, props to him 🙂

When blitting a framebuffer the source and destination need to have the same MSAA setting. As far as I recall, the system_fbo always has an MSAA of 0. Therefore this will break whenever a user uses MSAA on their render target.
—#35517 (comment)

[clayjohn]

@Calinou that comment only applies to the PR I commented on.

[Calinou]

that comment only applies to the PR I commented on.

I know, but I have a feeling this omission is the cause of this bug. When forcing MSAA in the graphics driver, it will be forced on the "root" viewport/FBO instead of forcing it on individual viewports within the application. This is why it often doesn't work in modern engines.

At the top of this issue thread, there are reports from people who haven't been able to reproduce this on AMD and Intel graphics cards. However, this was before the MSAA discovery. It would be interesting to have people try again with MSAA forced in the respective graphics driver.

[HeartoLazor]

I can't reproduce this issue with amd (7990 + 21.4.1 drivers).
Our internal QA has issues with a black screen + nvidia and I found this topic. There is a way to fix it from gdscript or editor settings?
I already had MSAA disabled in Godot editor.
We noticed with our team that the editor runs fine, but when you press play the game is not rendered. This doesn't make sense because the editor uses the same video driver as a godot game.
Here is a image of the issue happening running a game from editor in a nvidia 1050, drivers 446.27, godot 3.3, GLES 3.0:

Sound and input works, video not. Stay stuck at first frame (the splash screen). If the app is exported, same behavior but with black screen.
Notice the editor is fine at the background, so why we can't apply the same editor behavior to games as a fix?.

[Listwon]

Official Godot 3.3 build, Windows 10 Nvidia GTX 1080, the same issue with forced MSAA and Stretch mode: viewport. One thing I noticed is that as long as viewport size and window size are the same it renders without issues. Resizing the window triggers black screen.

[Calinou]

There is a way to fix it from gdscript or editor settings?

There's no way to control driver-forced MSAA from the application. Detecting a MSAA override to warn the user about potential issues might be possible, but I'm not sure.

We noticed with our team that the editor runs fine, but when you press play the game is not rendered. This doesn't make sense because the editor uses the same video driver as a godot game.

The editor uses the disabled stretch mode whereas your project may be configured to use the viewport stretch mode instead.

[Miziziziz]

There's no way to control driver-forced MSAA from the application. Detecting a MSAA override to warn the user about potential issues might be possible, but I'm not sure.

Do you know if this is possible yet?

[Calinou]

Do you know if this is possible yet?

Not that I know of. Ideally, we should fix whatever we're doing to be compliant with OpenGL specification, so that forced MSAA behaves correctly (or at the very least, do nothing instead of resulting in a black screen).

As I understand it, Godot is doing something that is not allowed per the OpenGL specification when the viewport stretch mode is used and the window size differs from the window size. That said, it still happens to work correctly on all GPU drivers unless you are forcing MSAA externally. Notice how this issue doesn't occur in GLES2, for reference.

It might be worth checking whether the issue occurs with forced MSAA on AMD drivers on Windows (if it works on OpenGL applications).

[MagicHead333]

I was experiencing the same problem with the game Endoparacitic. I had the same exact symptoms as Calinou did and I seemed to have found a solution at least for my case. In the Nvidia Control Panel after turning off "Antialiasing - mode" that was previously set to "Override any application settings" It seemed to work for me. Windows 10, Nvidia RTX 3060. Sorry I'm new to this type of stuff

[Darenn]

Hey everyone!

I don't have the exact same issue but the solution given by @MagicHead333 solved mine.

2 out of the 5000 players who played my game reported this black screen issue (so it's rare). After some tests, turned out the culprit was the viewport stretch mode. Game ran ok with 2D mode or disabled. I wanted to post a proper issue but for some reason a minimal project with viewport mode worked great on these players computers.

I started looking what parameters in conjunction with the viewport mode could cause the issue. I did not find out, but using @MagicHead333 solution solved the problems for both players.

It seems that this parameter is set right by default, hence why so few players had the problem.

Thank you @MagicHead333 !

[ashtonmeuser]

@Calinou Is any work being done to investigate this issue? It's nice having the features of GLES3 e.g. GPU particles, OpenGL textureSize() but this issue prevents a subset of users from even getting past the splash screen. It's not ideal to choose between supporting users and a modern dev experience.

[Calinou]

Is any work being done to investigate this issue?

While the issue is theoretically fixable, we don't know how to resolve it. This is ultimately something triggered by the NVIDIA driver. NVIDIA is unlikely to fix the issue on their end, considering forcing MSAA is a legacy measure nowadays (the new NVIDIA app doesn't even expose this option anymore).

I suggest you keep a troubleshooting page somewhere on your store page so users are aware of this issue. Also, Godot 4.x doesn't run into this issue with the Forward+/Mobile rendering methods as forcing MSAA doesn't affect Vulkan/Direct3D 12 applications.

In general, forcing a driver setting globally is a bad idea, regardless of what it is. It's really something that should be done on a per-game basis when you need it. At best, you're leaving performance on the table - at worst, you're causing rendering bugs in games that would otherwise render fine.

[ashtonmeuser]

@Calinou Appreciate the extra info. Sounds like it's not a high priority considering it only affects 3.x.

When blitting a framebuffer the source and destination need to have the same MSAA setting. As far as I recall, the system_fbo always has an MSAA of 0. Therefore this will break whenever a user uses MSAA on their render target.

When forcing MSAA in the graphics driver, it will be forced on the "root" viewport/FBO instead of forcing it on individual viewports within the application.

Perhaps I'm oversimplifying here, but do you think the following could be a viable stopgap solution?

1. Detect root viewport MSAA setting (possibly forced by Nvidia control center).
2. Apply the same setting to all child viewports.

This would ensure all viewports use the same MSAA setting thereby the discrepancy in source and destination mentioned by @clayjohn.

[Calinou]

1. Detect root viewport MSAA setting (possibly forced by Nvidia control center).

I don't know if it's technically feasible to read the value forced by the graphics driver from the application. Otherwise, this would probably be the best way to address the issue as it'll also ensure the override works as expected. Right now, if the MSAA override happens to work, it won't affect the project's 3D rendering because everything is always rendered in a secondary framebuffer (and not directly to the window like old games do).

[ashtonmeuser]

I see. So the forced value may not be reflected by get_tree().root.get_viewport().msaa. Can we confirm this? I don't have the hardware to test otherwise I'd be more helpful.

[Calinou]

So the forced value may not be reflected by get_tree().root.get_viewport().msaa. Can we confirm this? I don't have the hardware to test otherwise I'd be more helpful.

Indeed, the engine has no idea that the driver is overriding the root viewport's MSAA level (which in fact is not really the root viewport, as Godot always uses an intermediate framebuffer).

[KeyboardDanni]

Godot is already disabling nVidia's OpenGL "threaded optimization" through nvapi, essentially by reading/writing the application profile in the driver settings. Couldn't we do something similar with driver-level MSAA?

[Calinou]

Godot is already disabling nVidia's OpenGL "threaded optimization" through nvapi, essentially by reading/writing the application profile in the driver settings. Couldn't we do something similar with driver-level MSAA?

We could do that as a workaround, but if possible, this should only apply when the viewport size doesn't match the window size (i.e. what happens with the viewport stretch mode or shrink != 1.0).

That said, for advanced users, this is nothing NVIDIA Profile Inspector can't override anyway 🙂

[KeyboardDanni]

We could do that as a workaround, but if possible, this should only apply when the viewport size doesn't match the window size (i.e. what happens with the viewport stretch mode or shrink != 1.0).

I don't think changing the application profile after the context is created would have any effect. Best bet is probably to have it as a project setting like with threaded optimization.

That said, for advanced users, this is nothing NVIDIA Profile Inspector can't override anyway 🙂

Correct me if I'm wrong, but isn't that tool just editing the same data that's already exposed by nvapi? And my understanding is that an application-specific profile will always override the global driver profile for any values changed from the defaults.