Skip to content
New issue

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

#

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

Already on GitHub? # to your account

Jump to bottom

Emscripten compatibility #641

Closed
kvark opened this issue Mar 10, 2015 · 10 comments
Closed

Emscripten compatibility #641

kvark opened this issue Mar 10, 2015 · 10 comments
Labels
api: pre-ll old abstraction layer (pre-ll branch) difficulty: hard module: hal status: ready for work type: feature value: strategic

Comments

@kvark
Copy link
Member

kvark commented Mar 10, 2015

The way is clear now: http://bl.ocks.org/AerialX/26f81381b0b47c506959
This was referenced Mar 12, 2015
Closed
Closed
@kvark
Copy link
Member Author

kvark commented Mar 12, 2015

@AerialX Please let us know if there is anything else that you found not functioning. Current issues should be resolved now with #642 and #643

@AerialX
Copy link

AerialX commented Mar 13, 2015

Besides those, I just ran into few minor WebGL compatibility things.

  • GL_DRAW_FRAMEBUFFER and GL_READ_FRAMEBUFFER aren't valid framebuffer targets. Only GL_FRAMEBUFFER is allowed.
  • glPolygonMode doesn't exist.
  • info::parse() chokes on "WebGL 1.0". Version numbers also aren't namespaced. So, while WebGL 1.0 is similar to GLES 2.0 which is similar to OpenGL 3.1... They do differ, and the version numbers are meaningless when mixed into the same context. Also fun is how WebGL 2.0 is kind of like GLES 3.0 which is in line with OpenGL 4.ish, but at least we're still a ways away from seeing that supported by most browsers.
    • A similar issue exists for GLSL version numbers. GLSL ES 1.0 is kind of like GLSL 1.2 but not, and the version numbers aren't that comparable.
  • Capability detection doesn't quite work since GLES/WebGL use different names. For example OES_vertex_array_object

@kvark
Copy link
Member Author

kvark commented Mar 13, 2015

Thanks @AerialX ! We\ll work on it.

@AerialX
Copy link

AerialX commented Mar 16, 2015

@kvark Here's a few more...

  • glTexImage2D's format and internalFormat parameters must be the same. Firefox seems okay without enforcing this, but Chromium doesn't like it.
  • Fancy texture things like GL_TEXTURE_WRAP_R, GL_TEXTURE_LOD_BIAS, GL_TEXTURE_COMPARE_MODE (and >2D textures in general) don't exist. I believe they're in GLES3/WebGL2 though, and some features may be available as extensions.
  • This nasty issue. Unrelated to gfx-rs, but it came up a lot because gfx-rs tends to use best-fit types for values and thus has a lot of unaligned struct members with enums following them. Easiest ugly workaround was to replace all u8 types with u32 in most of the rendering-state-related data structs.

Also, a mini progress demo!

@kvark
Copy link
Member Author

kvark commented Mar 17, 2015

@AerialX Thanks for the update, this is awesome!

@kvark kvark mentioned this issue May 17, 2015
Closed
@jeffparsons
Copy link

Relevant update on Rust's Emscripten support in general: https://users.rust-lang.org/t/compiling-to-the-web-with-rust-and-emscripten/7627

@icefoxen icefoxen mentioned this issue Apr 19, 2017
Closed
@bwasty bwasty mentioned this issue May 14, 2017
Closed
@grtlr
Copy link
Contributor

grtlr commented Aug 12, 2017 •
edited
Loading

Since quite some time has passed since the last comment in this issue, I was wondering what is the current situation regarding Emscripten support? Even though it looks like WebGPU is on the horizon, it probably still requires quite some time to be actually ready.

It would be awesome to be able to run gfx-rs programs in the browser as well. Setting up SDL2 with Rust and Emscripten in the browser is straightforward, following this guide. However, I do not know what the limitations of this approach are, mainly is there full access to the OpenGL/WebGL capabilities this way?

@kvark
Copy link
Member Author

kvark commented Dec 15, 2017 •
edited
Loading

@grtlr

Since quite some time has passed since the last comment in this issue, I was wondering what is the current situation regarding Emscripten support?

I took a bite at Emscripten+WASM the other day - https://github.com/kvark/wasm-triangle
Basically, glutin is ready for some WebGL2 stuff, and nothing is blocking this feature from being implemented. Help is still wanted though :)

Even though it looks like WebGPU is on the horizon, it probably still requires quite some time to be actually ready.

We are working within the WebGPU W3C group, and we have a Servo-based prototype.

@kvark kvark mentioned this issue Dec 19, 2017
Merged
bors bot added a commit that referenced this issue Dec 19, 2017
@bors
Merge #1681
c7caa9a 
1681: [pre-ll] Emscripten support with WebGL 2.0 r=msiglreith a=kvark

Fixes #641. It has more things, so we'll create extra issues as we go forward.

The support is limited, but it works. Unexpected limitations: `constant_buffer_supported` and `clear_buffer_supported` have to be OFF. Emscripten doesn't hook those GL functions, even though they are technically a part of GLES 3.0 standard. Also, the `glutin` dependency is switched to GitHub until the next version is published.

![gfx-wasm-triangle](https://user-images.githubusercontent.com/107301/34141203-af58b9a0-e44d-11e7-926c-933662420689.png)

## Status of the examples
  - `triangle` works 🎉 
  - `flowmap` and `blend` produce ICE in the [fastcomp](https://github.com/kripken/emscripten-fastcomp) code
  - `instancing` fails because it wants to map a buffer
  - `mipmap`, `gamma`, and `performance` I haven't tried
  - others use constant buffers, which are not yet supported (see above)

## How to run and test yourself

You'll need Rust-1.22 or newer as well as Emscripten SDK installed. In Emscripten configuration, set `USE_WEBGL2=1`. I did it by just modifying "emscripten/src/settings.js" directly (from where it's installed). Hopefully, we'll be able to pass the linker parameters to `emcc` via `cargo` one day.

```bash
rustup target add wasm32-unknown-emscripten
cargo build --example triangle --feature wasm32-unknown-emscripten
ls target/wasm32-unknown-emscripten/debug/examples # find the "example-XXX" name
edit emscripten.html # put the example name in
firefox emscripten.html # open in the browser
```
@kvark kvark added the api: pre-ll old abstraction layer (pre-ll branch) label Feb 12, 2019
@kvark
Copy link
Member Author

kvark commented Feb 12, 2019

triaged: leaving open in case someone gets motivated enough to polish the support and get more examples running

@GabrielMajeri
Copy link
Contributor

The quad example seems to work with the native wasm32 target, so I'm guessing this has been solved now. We'll also get direct WebGPU support when #3027 gets implemented.

@kvark kvark closed this as completed Jul 30, 2020
adamnemecek pushed a commit to adamnemecek/gfx that referenced this issue Apr 1, 2021
@bors @GabrielMajeri
Merge gfx-rs#641
da4f900 
641: Add optional SPIR-V shader validation r=kvark a=GabrielMajeri

This PR adds some basic validation for SPIR-V shaders when creating pipelines. Starts work towards gfx-rs#269.

Currently, I'm marking this as a draft because `naga` isn't mature enough to be able to parse shaders from the `wgpu-rs` examples.

For example:
- Trying to run `hello-triangle` from `wgpu-rs` results in the following error:
`Failed to parse shader SPIR-V code: UnsupportedInstruction(Function, Variable)`
- For `hello-compute` it is:
`Failed to parse shader SPIR-V code: UnsupportedInstruction(Type, TypeBool)`

Co-authored-by: Gabriel Majeri <gabriel.majeri6@gmail.com>
# for free to join this conversation on GitHub. Already have an account? # to comment
Assignees
No one assigned
Labels
api: pre-ll old abstraction layer (pre-ll branch) difficulty: hard module: hal status: ready for work type: feature value: strategic
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@kvark @AerialX @jeffparsons @GabrielMajeri @grtlr