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

Fix remaining tests for WebAssembly #3282

Closed
haraldreingruber opened this issue Dec 10, 2022 · 4 comments
Closed

Fix remaining tests for WebAssembly #3282

haraldreingruber opened this issue Dec 10, 2022 · 4 comments
Labels
api: gles Issues with GLES or WebGL area: correctness We're behaving incorrectly

Comments

@haraldreingruber
Copy link
Contributor

haraldreingruber commented Dec 10, 2022

After adding support for running the current tests via WebAssembly in the browser (#3238), there were 2 tests that were not easily fixable for the WebAssembly target.

  1. clear_texture.rs pass, but there are texSubImage2D: invalid format warnings in the browser dev-console. Which probably means that there are some false-positives.
  2. buffer_copy.rs is executing code that is expected to panic. As catching an unwinding panic is not working for WASM, a workaround needs to be used. For this test, the workaround doesn't work because apparently the panic is not getting redirected to the error scope of the device.

In order to make tests to be executed by the WASM browser test, the #[wasm_bindgen_test] attribute needs to be added (next to the usual #[test])

@cwfitzgerald
Copy link
Member

cwfitzgerald commented Dec 11, 2022

For issue one, we should be calling getError on the gl context after the test runs to make sure there were no errors (and if there were, hit the validation canary) so this turns into a true failure

@haraldreingruber
Copy link
Contributor Author

haraldreingruber commented Dec 11, 2022

That's also kind of what I had in mind. Would you add a wasm specific part to the test code that directly queries the webgl getError fn? Or do other backends (except opengl) have a similar API so that it might be interesting to add to wgpu itself?

@cwfitzgerald
Copy link
Member

I think it would end up as wasm specific code which accesses the webgl2 context directly. All other apis have callback systems (including native gl https://github.com/gfx-rs/wgpu/blob/master/wgpu-hal/src/gles/egl.rs#L232) which we already hook.

@teoxoy teoxoy added area: correctness We're behaving incorrectly api: gles Issues with GLES or WebGL labels Feb 21, 2023
@cwfitzgerald
Copy link
Member

Closing as old, see #3678 for more info about current state

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api: gles Issues with GLES or WebGL area: correctness We're behaving incorrectly
Projects
None yet
Development

No branches or pull requests

3 participants