SSAO causes full-screen red washout on some machines

Anyone recognize this problem?

We’ve encountered two machines now out of several, which when SSAO is enabled get a defective heavy red tint across the screen. Shown here with and without (we have a toggle to disable SSAO.)

Upgraded to latest BJS 5.15.1. Dont know when the problem appeared.

On machines where this occurs, appears in all browsers - latest Chrome & Edge & Firefox.
One machine has an Nvidia RTX 3080 with latest Win10 and latest Nvidia drivers, so the problem isnt limited to obsolete drivers with inadequate WebGL/GPU support.

Here’s my SSAO pipeline setup:

// add SSAO
    const ssaoRatio = {
        ssaoRatio: 0.5, // Ratio of the SSAO post-process, in a lower resolution
        blurRatio: 0.5// Ratio of the combine post-process (combines the SSAO and the scene)

    if( !lowQuality ) {
        const ssao = new SSAO2RenderingPipeline("ssao", scene, ssaoRatio, [camera], false);
        ssao.radius = 15.5;
        ssao.totalStrength = 1.3;
        ssao.expensiveBlur = false;
        ssao.samples = 16;
        scene.prePassRenderer!.samples = 16;    // MSAA disabled by default (==1) with SSAO, so enable

Can you double check the Chrome version and share a repro ?

It seems to be displaying the wrong render target.

cc @CraigFeldspar

also are there any warnings/errors in the console ?

Chrome is confirmed latest, v103.0.5060 64bit. Same with Brave and Firefox. Latest BJS too, 5.15.1

There are no related warnings/errors in the console.

I dont do anything with render targets explicitly. Just set the engine up with SSAO and MSAA, point it at the one Canvas element in React, and go.

The weird thing is this only happens on 2 known machines so far, everywhere else is looks fine including mine. I cant reproduce this on my machine at all.

Unfortunately the full app is too large for sharing (and company proprietary anyway, you know how that goes). I wish I could reproduce the problem locally.

We’ve discovered the problem is specific to MSAA. If I set the MSAA sample rate to 1, the problem goes away on the problem machines (but so does the MSAA, of course).

Why would random PCs have an apparent failure to support MSAA? Particularly a young machine with the latest Nvidia RTX, latest drivers, and all Windows 10 updates.

can you repro in the playground with just a cube ssao and msaa ?

this would already be a nice starting point ?

I cant even repro the problem on my own machine with the same code that is failing elsewhere. That’s why Im forced to ask if anyone recognizes the problem via screenshot and description.

It really sounds like a driver bug cause all browsers are doing the same but only on some machines. Those are the hardest to track :frowning:

Is there by any chance more than 1 gpu on those machines ?

Is there by any chance more than 1 gpu on those machines ?

There is, the Nvidia RTX card is the primary GPU but it’s merely a replacement for whatever lesser GPU comes integrated with the mobo.

yup but you would use the RTX as long as your screen is plugged in this one except if you were on a laptop ?

Looking at different ways to obtain SSAO, with the SSAO2RenderPipeline we’ve had to re-enable MSAA with scene.prePassRenderer.samples =16. This works fine for roughly only 4 machines out of 5, with the minority suffering the red wash bug.

Revisiting the older SSAORenderPipeline, how does one enable MSAA or FXAA?
The scene.prePassRenderer seems no longer valid.
The SSAO instance appears to lack a member “samples” or “textureSamples”.

To enable MSAA you would need to try renderPipeline._originalColorPostProcess.samples = 4; if that works ok, I can open a property for it ?

FXAA will be hard to include without forking the code

Playground example!

Modified the existing SSAO demo replacing SSAORenderPipeline with SSAO2RenderPipeline and our config. Consistently incurs the “red bug” on machines where this bug is known to happen. The only changes here are in the SSAO/2 setup.

Screenshots are from my boss’s laptop (Win10, Nvidia 3080 Mobile), since mine doesnt suffer the problem.

2nd screenshot is just a sanity check, same laptop using the unmodified version of the SSAO demo.

So the question remains, is my SSAO2 setup wrong? Or does the SSAO2 shader have a bug that only affects certain machines?

For SSAO, _originalColorPostProcess.samples = 4 does work to restore anti-aliasing, yes. Thank you.

Although SSAORenderingPipeline has a separate, more subtle problem I didnt spot earlier. This happens on all machines.

Hard to describe. It looks like slightly-muddied screen-space layer is detached from the camera and overlaying on top of the screen. Maybe I can capture it in video. You have to look closely, mostly at the ground plane as the camera rotates. Look for the subtle ground layer that doesnt rotate. It’s like SSAO is stuck on an old color frame instead of using most recent.

Great so we are one step further !!!

Can you check on your boss laptop what this is saying in the log

{“vendor”:“Google Inc. (Intel)”,“renderer”:“ANGLE (Intel, Intel(R) UHD Graphics Direct3D11 vs_5_0 ps_5_0, D3D11)”,“version”:“WebGL 2.0 (OpenGL ES 3.0 Chromium)”}

Oh hey, well there’s one interesting point. It’s using the onboard Intel UHD GPU, not the Nvidia 3080 Mobile. Which BTW that is a laptop so the Nvidia is not an add-on card.

Some enumerator is taking the 1st GPU found, instead of taking the best. With both GPUs being integrated, you’d think the Intel one would be de-prioritized if not entirely disabled.

And SSAO2RenderingPipeline manages to tickle an MSAA bug in the Intel UHD driver I guess?

Just for reference, here’s my info as well - and the red bug never happens here.
{“vendor”:“Google Inc. (NVIDIA)”,“renderer”:“ANGLE (NVIDIA, NVIDIA GeForce RTX 3080 Direct3D11 vs_5_0 ps_5_0, D3D11)”,“version”:“WebGL 2.0 (OpenGL ES 3.0 Chromium)”}

Yes exactly my thinking :slight_smile:

Could you open an issue on the chromium bug tracker ?

I also just found this as a likely contributing factor:

What is Nvidia Optimus?

Nvidia Optimus is a technology where a notebook with two graphics cards (integrated Intel GPU and discrete Nvidia GPU) can dynamically switch between them during regular use based on the needs of the applications.

The goal of Optimus is to save battery life while still giving a chance for high-performance graphics.

Applications needing high performance should use faster discrete Nvidia GPU, applications needing longer battery life should use slower but less-energy-consuming integrated Intel GPU.

You think the red bug is a fault in Chromium then? Seems like an Intel flaw.

The “Optimus” GPU switching business is doing it’s intended job of favoring the lower-powered GPU when deemed adequate, it’s just the Intel GPU/driver then happens to fail on MSAA support.

yup I guess it is an intel driver issue but they might be able to connect with the right ppl.

Discovering it’s also limited to Windows, as the Linux Mesa HD driver doesnt suffer from this MSAA red bug either.