View live demo of these examples at https://wgsl.dev/
Provide clear and consistent examples that:
- Are composed of a single .html file, which includes all JS and shader code inline.
- Are able to run directly without referencing TypeScript or other framework code.
- Do not rely on external dependencies (glMatrix is the one exception).
This project was created during my process of learning WebGPU. As a result this project became a reconstruction and representation of the official webgpu samples from webgpu-samples, with a few additions and expansions added.
Some of the changes here have been added back to the official webgpu samples. (Such as PR 227)
Also a compute example was recreated from this web.dev article, as well as a light example that was built based on the teapot setup from webgpu-test.
The library glMatrix is used as the only loaded dependency, which is included via a script tag inside each example.
For ongoing changes the main reference is the Official WebGPU Explainer.
Open to contributions and/or suggestions for improvements.
Latest version of Chrome now has WebGPU support built in!
For additional browsers, see caniuse.com/webgpu.
Live at: https://www.wgsl.dev/editor
When viewing examples with the online editor, there are a few special considerations that are accounted for before the edited script is injected into the viewing frame.
Until a updated WGSL language package is widely available, the following workflow for syntax highlighting was enacted.
Each example has a including <!-- wgsl --> after the opening script tag.
This flags the editor to replace this line.
For example, the following: <script id="shader-wgsl" ><!-- wgsl --> ,
is replaced with: <script id="shader-wgsl" type="x-shader-wgsl"> .
Using <script> tags allow us to include the shader code inline without needing to define them as multiline strings with quotes.
By defining the type as some form of x-shader - a popular naming convention is being followed.
This is simply just a way to stop the compiler from attempting to read the script content as JavaScript.
Frames per second and error detection is displayed.
This is possible because the editor looks for and attaches extra logic to the requestAnimationFrame function calls.
As a result, in order for the error status and frames per second data to be correctly displayed, each example will need to contain a requestAnimationFrame loop. This is true even for examples that might not need to render visual changes each frame.