Lower max_color_attachments limit for GL to 4

[adrian17]

Connections
#6986

Description
Wgpu 23 broke support for older devices that only supported GLES and max_color_attachments == 4 (which is the minimum mandated by 3.1 spec). The limit technically used to be 8 for much longer, but according to @cwfitzgerald it wasn't enforced before. This change aims to revert this regression.
Only downlevel limits are changed, not default limits.

Note that I can't prove that this is the only thing that needs changing to make wgpu work on such old devices again, because I'm only relying on user reports and can't check it myself.

Testing
Ran cargo test --doc only.

Only tested manually with a hack, since I don't have access to such a device:

        let max_color_attachments = unsafe {
            gl.get_parameter_i32(glow::MAX_COLOR_ATTACHMENTS)
                .min(gl.get_parameter_i32(glow::MAX_DRAW_BUFFERS))
                .min(crate::MAX_COLOR_ATTACHMENTS as i32) as u32
        };
+       let max_color_attachments = 4;

Checklist

• Run cargo fmt.
• Run taplo format.
• Run cargo clippy. If applicable, add:
  • --target wasm32-unknown-unknown
  • --target wasm32-unknown-emscripten
• Run cargo xtask test to run tests.
• Add change to CHANGELOG.md. See simple instructions inside file.

[Wumpf]

For reference: https://registry.khronos.org/OpenGL-Refpages/es3.0/html/glGet.xhtml also says the minimum value is 4 for GLES 3.0, so this change makes sense in any case! 👍

[Wumpf]

@adrian17 Please add a line to the changelog under bugfixes

[colin-i]

I tested this on a device that had this problem (Raspberry Pi 4). The error is gone and the program (ruffle) is starting with no more errors.

[adrian17]

Added changelog.

Should I assume that the wasm CI failures are expected? Looking at logs, they didn't seem related to my changes.

[cwfitzgerald]

So Wasm is failing, but apparently the logging config we're using casues there to be 41MB of logs...

I'll take a look at this on monday

[adrian17]

It's still failing somehow on wasm :c

Here's the first relevant part of the CI logs, I think?

    info output:
        Testing using adapter: AdapterInfo {
            name: \"ANGLE (Google, Vulkan 1.3.0 (SwiftShader Device (Subzero) (0x0000C0DE)), SwiftShader driver)\",
            vendor: 0,
            device: 0,
            device_type: Cpu,
            driver: \"\",
            driver_info: \"WebGL 2.0 (OpenGL ES 3.0 Chromium)\",
            backend: Gl,
        }
        TEST: srgb-blend-linear
    
    error output:
        Validation Error: *no message*
        panicked at /home/runner/work/wgpu/wgpu/tests/src/run.rs:120:9:
        examples/features/src/framework.rs:507:9: test \"srgb-blend-linear\" did not behave as expected

[cwfitzgerald]

Yeah this means gl.GetError is returning something - you unfortunately need to run the tests in the browser to get the full error. I can do this if it's a bother.

[adrian17]

I just ran the suite locally and they passed :(

test srgb_blend::test_linear_webgl ... ok
test srgb_blend::test_srgb_webgl ... ok

I also tried with again pretending that gl.getParameter(MAX_COLOR_ATTACHMENTS) returns 4, and they still work.

I don't understand how this test can be failing now; if the entire CI environment had max_color_attachments==4, then the test would have been failing before too, for a different reason, right?

My best guess is that this has something to do with this hardcoded constant, which I didn't know whether I should have updated or not:

https://github.com/gfx-rs/wgpu/blob/trunk/wgpu-hal/src/lib.rs#L298