My team started looking at subgroup support for #WebGPU again. We pushed it out of the initial #WGSL feature set due to our staffing load and suspected non portability. Revisiting it now.
Sadly, and frustratingly, implementations don't do what programmers think should happen. We are seeing very very nonportable behavior.
Still collecting data across devices and platforms that we will share soon enough.
Nice to see use of Google's Tint library to translate SPIR-V to #wgsl
File bugs if you find deficiencies
If you work in Rust, look to Mozilla's Naga to provide similar functionality.
Not that I prefer #glsl over #wgsl ... In fact, I feel now more familiar/fluent with the latter, but I am curious to know what WGSL offers that GLSL lacks, or perhaps what GLSL offers that is deemed inadequate for the Web. Any security or portability or similar concerns that ruled GLSL out? Or is it just a matter of decoupling Web standards from native standards?
My impression is that there's a consensus that #webgpu is appreciated as a simpler/more approachable API than #vulkan but also more modern, flexible and closer to the metal than #webgl / #opengl ... But I think opinions are far more mixed/varied when it comes to WGSL. Would this become a hurdle in the path of adoption?
Not sure why I am pondering these questions 😅 I guess just curiosity. For my personal modest needs, I doubt I will ever write WebGL/OpenGL code again, unless WebGPU adoption falters, which would be very unfortunate. Adoption seems healthy to me so far.
#glsl #WGSL #webgpu #vulkan #webgl #opengl
Current status: writing conformance tests for #WGSL bitcast.
Both positive and negative cases.
The float cases are tricky because of the permitted runtime behaviours for inf and nan. But for const-evaluation, inf and nan must be rejected.
I've updated the #WGSL to use WGSL-specific syntax highlighting. Previously we were faking it with Rust highlighting, which was a decent approximation.
One tell-tale sign: in the code samples 'var' is now red like other keywords.
Backstory: I added WGSL syntax highlighting rules to Pygments 2.15, and that rolled into Bikeshed at the end of April.
If you have ever struggled when starting to learn shaders, give #wgsl a try.
It is not as industry standard as GLSL or HLSL, but the modern rust-style syntax makes it easy to learn and you will be applying the same math and techniques that you can then take back to the classic languages.
Combine it with Rust+wgpu+winit for a good introduction to rendering.
Was putting in the work with Typescript today. Some things still baffle me.
Waiting for the review, figure I'll learn something from it.
PR adds conformance tests for bitcast from f32. Annoying because of #wgsl permitted behaviours for non normal numbers.
Speaking of recursive noise, I wish #wgsl supported tail recursive functions. But I suppose a shading language is not meant to be too complicated to implement.
Vous pourrez parler pendant des heures : #Mastodon ne vaut pas #Twitter avec #TweetDeck et il en est TRÈS TRÈS LOIN.
Exemple : je viens de créer un deck spécial avec des colonnes de recherches en lien avec #WebGPU et #WGSL : ça pête des résultats excellents et très intéressants pour produire des supports de QUALITÉ dans mon MediaWiki.
#mastodon #Twitter #tweetdeck #webgpu #WGSL #cqfd
Now that WebGPU is out, I’m thinking about forking my live coding system Facet to do its computation in WGSL. I’m assuming it would be able to generate and modify Float32Arrays way faster than on the GPU than in the CPU in Node, where it’s currently running the computations.
I know it’s a pretty new development in the web tech space, but curious if anyone might had used WGSL for generating 1D Float32Arrays might have any advice for a noob like me that has never worked with shaders.
A word of caution. The #WGSL spec is structured and written to primarily be precise and concise.
It can be obtuse and dense. It's the legalese meant for implementors and developers on both sides of the API contract.
It is *not* meant as a tutorial, and it doesn't put the language in full context. Other folks will write those, and the best will take hold in the collective mindshare.
@mcc
Depending on your use case, consider using the SPIR-V to #WGSL conversions in Tint and Naga, the Google and Mozilla WGSL compilers.
Highly useful but not officially production state.
Meant if you still want to stay with your original Shader authoring flow to SPIR-V
Unity is using Tint, and have been gracious enough to publish samples for testing.
#WGSL syntax highlighting will be coming to VS Code soon.
I landed the support in monaco-editor a few days ago, and it's now in the 0.37.0 release.
Woohoo!
As it turns out, I didn't need yarn2. Yarn1 (classic yarn?) Was just fine.
This is for #WGSL syntax highlighting in Monaco, the VSCode editor.
Took a while, but after staring hard at the sample sites I was able to piece together a workable flow. Then fought a few things that Monaco-editor does differently from the others. Had two puzzling bugs on my part, and found what I think is a Monaco bug. (Unicode patterns don't work?!)
By end of day I was mostly there.
I made a pygments lexer for #wgsl
It was way easier than I expected.
Hopefully this will let us get *good* syntax highlighting for WGSL. (As opposed to kind of faking it by pretending it's rust or groovy)
The work resulted in bugfixes to WebGPU and the memory model tests in the WebGPU conformance test suite.
We also would like to unify almost all attribute parsing so it's one regular rule where all parameters are expressions. Similar goal: regularized parsing and independent analysis.
#wgsl