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

[Wumpf]

tried for a bit to figure out what's up as well.
Running tests locally with firefox works fine, but getting 404 with chrome (tried on Windows & WSL). Is there any trick to that @cwfitzgerald ? Didn't see anything special in the CI setup either
otherwise did a lot of poking around how the change could affect tests and checked what exact tests failed and what they have in common (it's at the end of that huge test log. To no avail so far
Changing the max_color_attachments default to 4 everywhere else also doesn't cause test failures on native gl either

[colin-i]

Changing the max_color_attachments default to 4 everywhere else also doesn't cause test failures on native gl either

https://github.com/colin-i/wgpu/blob/v24.0test/wgpu-hal/src/lib.rs#L296 to 4 will succeed Test WebAssembly.
If also setting to 4 at https://github.com/colin-i/wgpu/blob/v24.0test/wgpu-types/src/lib.rs#L1282 will succeed everything.

[teoxoy]

One thing I noticed is that we use crate::MAX_COLOR_ATTACHMENTS (which is 8) in the code below:

wgpu/wgpu-hal/src/gles/queue.rs

Lines 1081 to 1092 in 5af9e30

	for i in 0..crate::MAX_COLOR_ATTACHMENTS {
	let target = glow::COLOR_ATTACHMENT0 + i as u32;
	unsafe {
	gl.framebuffer_texture_2d(
	glow::DRAW_FRAMEBUFFER,
	target,
	glow::TEXTURE_2D,
	None,
	0,
	)
	};
	}

[cwfitzgerald]

HA! It verked! Thanks @teoxoy for spotting that :)

(also auto-merge didn't turn off 😅)

[adrian17]

To be sure, what are the semantics of crate::MAX_COLOR_ATTACHMENTS? As in, if it’s currently higher than the allowed limit, then when can it be used instead of the limit? Without knowing the codebase, it kinda felt like it should be lowered too, or not used at all.

[Wumpf]

MAX_COLOR_ATTACHMENTS in hal for the maximum number that is ever supported. If an implementation reports more (shouldn't happen ;-)), it's still capped to that value. It is primarily used to allocate fixed size arrays for bookkeeping