Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WebGL2: panicked at 'Tex storage 2D multisample is not supported' #2149

Closed
superdump opened this issue Nov 2, 2021 · 16 comments · Fixed by #2307
Closed

WebGL2: panicked at 'Tex storage 2D multisample is not supported' #2149

superdump opened this issue Nov 2, 2021 · 16 comments · Fixed by #2307
Labels
area: correctness We're behaving incorrectly type: bug Something isn't working

Comments

@superdump
Copy link
Contributor

Description
When using wgpu master with WebGL2 and MSAA I'm getting: panicked at 'Tex storage 2D multisample is not supported', C:\Users\super\.cargo\registry\src\git.luolix.top-1ecc6299db9ec823\glow-0.11.0\src\web_sys.rs:2168:9

Repro steps

See the attached zip of a wasm WebGL2 demo. Unpack, serve, browse, see panic.

Expected vs observed behavior
Expected: no panic. Observed: panic in both Chrome and Firefox. :)

Extra materials
webgl2-multisample-panic.zip

Platform
wgpu master @ ca7ca74, WebGL2, Windows 10

@mrk-its
Copy link
Contributor

mrk-its commented Nov 2, 2021

I have the same for texture_pipelined bevy example, it doesn't panic after disabling msaa

@kvark
Copy link
Member

kvark commented Nov 3, 2021

Problem is very similar to #2137. We want to enable COPY_DST usage for all textures because that's how we zero-initialize them. But on WebGL specifically, we can't create a multi-sampled texture with COPY_DST and COLOR_TARGET.

The solution I tentatively propose is to split the texture initialization into 2 paths:

  1. the current path, which initializes via copies
  2. for MSAA textures, surface textures, and depth/stencil - initialize via render pass clears. I believe this is also faster on desktop, and it doesn't require any new usages, thus has WebGL2 compatibility.

cc @Wumpf

@kvark kvark added area: correctness We're behaving incorrectly type: bug Something isn't working labels Nov 3, 2021
@superdump
Copy link
Contributor Author

In case it impacts any prioritisation, I just wanted to note that bevy will need this for WebGL2 support for its upcoming 0.6 release, so there is interest and significant value for bevy there. No expectations of course, and if I could figure out all the needed changes and how to choose one or the other path then I could probably implement it myself.

@kvark
Copy link
Member

kvark commented Nov 9, 2021

There is a quick thing that we could do, and a real fix that we could do. Both much depend on @Wumpf guidance.
The quick thing is having some option to disable zero-initialization completely. This will be unsafe and native-only. Could be exposed as a device feature. @superdump you could try to prototype this, if you feel motivated.
The real fix is splitting the texture initialization paths in 2, like I described above: via copies and via render target clears.

Finally, Bevy has an option to not do MSAA at start of 0.6, at least not on WebGL target.

@Wumpf
Copy link
Member

Wumpf commented Nov 9, 2021

started to take a stab at this, don't know how long it will take and if I can do something partial to unblock the particular issue
We should add a zero-init disable extension regardless I think. At least right now the impl isn't exactly geared towards performance so it can cause issues regardless.

@superdump
Copy link
Contributor Author

Is the zero initialisation stuff a WebGPU requirement or a debug nice to have? If not the former then shouldn’t it be up to users to initialise buffers or not? If the former then maybe it’s still desirable for native anyway to have control over initialisation as well as having an easy way to enable it for debugging. :)

@Wumpf
Copy link
Member

Wumpf commented Nov 9, 2021

it is a WebGPU requirement. And a surprisingly nasty one 😄

@maxammann
Copy link
Contributor

I just upgarded to 0.12 and encountered this issue. As far as I understand this block multisampling when using WebGL. This is not a huge blocker for me as WebGL is not my primary target. For the time being I can just disable multisampling on WebGL.

@superdump
Copy link
Contributor Author

@kvark I see this was fixed - fantastic! What's the plan for the next release? Any chance of a 'quick' 0.12.1 with this in it?

@kvark
Copy link
Member

kvark commented Dec 29, 2021

I'll get something rolling...

@kvark
Copy link
Member

kvark commented Dec 29, 2021

Actually, there is a bit of a problem. #2307 is breaking API (feature name changed, some errors as well).
@Wumpf how feasible would it be to port it to 0.12 in a non-breaking way?

@maxammann
Copy link
Contributor

The fix works 🎉

@Wumpf
Copy link
Member

Wumpf commented Dec 29, 2021

should be possible, feature name and errors are arguably rather cosmetic and can be reverted. Would be mostly worried about introducing new bugs to an old release

@Wumpf
Copy link
Member

Wumpf commented Dec 29, 2021

I think that would do #2327

@gilescope
Copy link

Alas having studied the existing examples and the PR it's not clear how to get around this error (I'm on latest release v14). Would be great to have a webgl example with texture aliasing as well as just the line one. Is there any project out there I can look at to see what I should be doing?

@maxammann
Copy link
Contributor

You should not get this error when enabling multisampling. I'm using multisampling with webgl successfully here: https://github.com/maplibre/maplibre-rs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: correctness We're behaving incorrectly type: bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants