3 ms·

There is (surprisingly) no high level commentary on what this actually is, but people banging on about how nice it would be to have a high level cross platform

There is (surprisingly) no high level commentary on what this actually is, but people banging on about how nice it would be to have a high level cross platform GPU accelerated library. ...but this..? > Graphics data and code can be developed together in the same environment, packaged together into a WebAssembly module called a renderlet, and rendered onto any canvas. With WebAssembly, we compile graphics code to portable bytecode that allows it to safely run on any processor and GPU So what is a renderlet? > The renderlet compiler is currently in closed preview - please contact us for more information. Hm... what this seems to be is a C++ library that lets you take compiled WASM and run it to generate and render graphics. Which, I think it is fair to say, it's surprising, because you can already render graphics using C++. Only here, you can render graphics using an external WASM binary. So, why? Specifically, if you're already using C++: 1) Why use WASM? 2) Why use renderlet instead of webGPU, which is already a high level cross platform abstraction including shader definitions? What is this even for? > wander is designed to be a rendering engine for any high-performance application. It primarily is designed as the runtime to run renderlet bundles ...but, why would I use a renderlet, if I already need to be writing C++? I. Get. It. A cross platform GPU accelerated rendering library you can use from any platform / browser / app would be great. ...but that is not what this is. This is a C++ library runtime that you can use to run graphics in any circumstance where you you can currently use C++. ...but, in circumstances where I can use C++, I have many other options for rendering graphics. Look at the workflow: Rendering code -> Renderlet compiler -> renderlet binary App -> load renderlet binary -> start renderlet runtime -> execute binary on runtime -> rendered vs. App -> rendering code (WebGPU) -> rendered or, if you writing a new cross platform API over the top of webGPU App -> Fancy api -> WebGPU -> rendered I had a good read of the docs, but I honestly fail to see how this is more useful than just having a C++ library that renders graphics cross platform like SDL. Shaders? Well, we also already have a good cross platform rendering library in webGPU; it already runs on desktop and browsers (maybe even some mobile devices); it already has a cross platform shader pipeline; it's already usable from C++. I'm not going to deny the webGPU API is kind of frustrating to use, and the tooling for building WASM binaries is too, but... it does actually exist. Is this like a 'alternative to webGPU' with a different API / easy mode tooling? ...or, have I missed it completely and there's something more to this?

seanisom 3y ago
Keeping it high level - No, the goal is not to create a C++ API to give you GPU functions. The C++ API for wander is used to embed the WebAssembly module of graphics code into the application. The API footprint is very small - load a file, pass parameters to it, iterate through the tree it produces. This could be viewed as logically equivalent to programmatically loading a flash/swf file. Or similar to what Rive has built with a .riv, although this is static content, not code. > 1) Why use WASM? You're loading arbitrary, third-party code into an app - that is the renderlet. The benefit is to have a sandboxed environment to run code to put data on the GPU. 2) Why use renderlet instead of webGPU, which is already a high level cross platform abstraction including shader definitions? WebGPU is a low-level API. If you are a graphics programmer, and want to build an app around WebGPU, go for it! A renderlet is more of a graphics plugin system than an entire first-party app. > The renderlet compiler is currently in closed preview - please contact us for more information. This is the system to build the renderlet. This is not writing raw C++ code to talk to WebGPU, this can be higher-level functions (build a grid, perform a geometric extrusion, generate a gradient) - you can see in the video it is a yaml specification. The compiler generate the necessary commands, vertex buffers, textures, etc, and soon, shaders to do this, and builds a Wasm module out of it. > Is this like a 'alternative to webGPU' with a different API / easy mode tooling? I certainly wouldn't describe it as an alternative to WebGPU, but easy(er) tooling to build graphics, yes. > What is the use-case for 'I've compiled a part of my application only into a cross platform binary renderlet and I can now run that cross platform ... after I've compiled the rest of my application into a platform specific binary for the platform I'm running it on?' Let's take an example - Temporal Anti-Aliasing. There are libraries that exist to implement this, or you can implement it through raw code. This requires changes structural changes to your pipeline - to your render targets, additional outputs to your shaders, running additional shaders, etc. Wouldn't it be nice to easy connect a module to your graphics pipeline that contains the code for this, and the shader stages, and works across platforms and graphics APIs, with data-driven configuration? That is the vision. > ... rest of your application into WASM/platform native code... is that not strange? It seems strange to me There is not really such a thing as a standalone Wasm application. It has seen great success as a data-driven plugin model. In a browser, it is hosted with / interacts with JavaScript. Even built for pure WASI, as a standalone app where everything is compiled into a single module, there is stil a runtime/host environment. Does that help clarify?

seanisom 3y ago

Keeping it high level - No, the goal is not to create a C++ API to give you GPU functions. The C++ API for wander is used to embed the WebAssembly module of graphics code into the application. The API footprint is very small - load a file, pass parameters to it, iterate through the tree it produces. This could be viewed as logically equivalent to programmatically loading a flash/swf file. Or similar to what Rive has built with a .riv, although this is static content, not code. > 1) Why use WASM? You're loading arbitrary, third-party code into an app - that is the renderlet. The benefit is to have a sandboxed environment to run code to put data on the GPU. 2) Why use renderlet instead of webGPU, which is already a high level cross platform abstraction including shader definitions? WebGPU is a low-level API. If you are a graphics programmer, and want to build an app around WebGPU, go for it! A renderlet is more of a graphics plugin system than an entire first-party app. > The renderlet compiler is currently in closed preview - please contact us for more information. This is the system to build the renderlet. This is not writing raw C++ code to talk to WebGPU, this can be higher-level functions (build a grid, perform a geometric extrusion, generate a gradient) - you can see in the video it is a yaml specification. The compiler generate the necessary commands, vertex buffers, textures, etc, and soon, shaders to do this, and builds a Wasm module out of it. > Is this like a 'alternative to webGPU' with a different API / easy mode tooling? I certainly wouldn't describe it as an alternative to WebGPU, but easy(er) tooling to build graphics, yes. > What is the use-case for 'I've compiled a part of my application only into a cross platform binary renderlet and I can now run that cross platform ... after I've compiled the rest of my application into a platform specific binary for the platform I'm running it on?' Let's take an example - Temporal Anti-Aliasing. There are libraries that exist to implement this, or you can implement it through raw code. This requires changes structural changes to your pipeline - to your render targets, additional outputs to your shaders, running additional shaders, etc. Wouldn't it be nice to easy connect a module to your graphics pipeline that contains the code for this, and the shader stages, and works across platforms and graphics APIs, with data-driven configuration? That is the vision. > ... rest of your application into WASM/platform native code... is that not strange? It seems strange to me There is not really such a thing as a standalone Wasm application. It has seen great success as a data-driven plugin model. In a browser, it is hosted with / interacts with JavaScript. Even built for pure WASI, as a standalone app where everything is compiled into a single module, there is stil a runtime/host environment. Does that help clarify?