Add WebAssembly as a first-class target language.

[Kangz]

Currently, applications using OpenGL that are compiled for the Web have to go through emscriptem's OpenGL ES to WebGL shim layer that adds some overhead in addition to the overhead of going through Javascript for every call. For example emscriptem has to emulate the bind-to-create behavior of OpenGL and probably does a map lookup everytime an OpenGL id is used.

In WebGL the shim overhead might be lost in the CPU overhead of WebGL itself, but with a faster API it will become more apparent. WebAssembly is a huge use case for the API, if only for porting game engines to the Web. We should strive to make the emscriptem shim as small as possible.

How about making WebAssembly a first-class target language in the "Goals" section, for example with this wording?

Interoperates well with web runtimes for multiple languages, such as WebAssembly.

[AdamRobertsEF]

Sounds good. How about making it Native by default by using WebAssembly's JIT compiler for all of GPUWeb's modules?

JIT compiled modules once compiled, could be held in a cache. Client sends hardware build specs, after requesting a GPUWeb content, and server could send back links to pre-compiled modules; if they exist. Server could join a global caching service (CDN), once a module is compiled for particular hardware, it's placed in the CDN and doesn't have to be compiled again for a client.

Depends what's faster, can the client do JIT compilation quicker than downloading a cached module from the CDN? Tests could be done to prove this. — Can the server do JIT for the client quicker than the client, could a global CDN offer a build service, that's results in quicker load times for the client vs the client doing JIT.

[jfbastien]

I'd like to understand what you're proposing.

The blog post mentioned WebAssembly:

Its design should fit with established patterns of the Web, to make it easy for developers to adopt the technology. It needs to be able to work well with other critical emerging web standards like WebAssembly and WebVR.

That seems in line with your suggestion, so there's agreement. Maybe you're asking for the charter's text to be clarified? The goals / scope of work could be a good place to add this.

Or are you trying to understand how WebAssembly could interface with a GPU API? WebAssembly has some documentation on future plans which could fit (e.g. WebIDL could generate WebGPU and JavaScript bindings) but nothing super concrete at this point in time.

Either way, both question make a lot of sense.

[othermaciej]

On the one hand, I agree this would be desirable. On the other hand, WebAssembly doesn't yet have a defined way to expose APIs to it specifically. It will be hard to know how a requirement around this could be met until WebAssembly has such a feature.

I think probably the right middle ground for the charter is to list WebAssembly as a desired feature, and list WebAssembly CG as a cross-functional dependency to enable this.

[Kangz]

@AdamRobertsEF that might be an interesting idea to think about later down the line, but the question here was simply about the bindings exposed to WebAssembly. Adding heterogeneous compute to WebAssembly would be a whole different effort.

@jfbastien, @othermaciej: My question was mainly about clarifying the charter language to explicitly mention WebAssembly. In particular this would mean the CG would look at what IDL structure would help make the WebAssembly bindings efficient when going through Javascript. If the future plans for WASM bindings are clarified, the "GPU on the Web" CG would also make such bindings available.

I'm not sure what the process is, but I agree that we should involve the WASM CG in the discussion.

[grorg]

@Kangz

In particular this would mean the CG would look at what IDL structure would help make the WebAssembly bindings efficient when going through Javascript. If the future plans for WASM bindings are clarified, the "GPU on the Web" CG would also make such bindings available.

Agreed. I'll amend the charter.

[Kangz]

Thank you!

[taymills1212]

Currently, applications using OpenGL that are compiled for the Web have to go through emscriptem's OpenGL ES to WebGL shim layer that adds some overhead in addition to the overhead of going through Javascript for every call. For example emscriptem has to emulate the bind-to-create behavior of OpenGL and probably does a map lookup everytime an OpenGL id is used.

In WebGL the shim overhead might be lost in the CPU overhead of WebGL itself, but with a faster API it will become more apparent. WebAssembly is a huge use case for the API, if only for porting game engines to the Web. We should strive to make the emscriptem shim as small as possible.

How about making WebAssembly a first-class target language in the "Goals" section, for example with this wording?

Interoperates well with web runtimes for multiple languages, such as WebAssembly.