How do people test #WebGPU programs/shaders in CI? Can Chrome or Firefox run headless on a server in a closet? Is there a #WGSL implementation that does not need a physical GPU?
I'm happy to announce I will be speaking at #RustFestZurich this year. My talk is about Linon, a graphical #RustLang application I began writing during my MSc studies at @uniheidelberg for interactively exploring the visual effects of continuous refraction or distortion of light rays. The application is based on #wgpu, making heavy use of #WGSL compute shaders.
Downloading Google Dawn on Windows10 fails due to filename too long.. here is the filename ImageSampleProjDrefExplicitLod_CheckForLod0_SpvParserHandleTest_ImageCoordsTest_MakeCoordinateOperandsForImageAccess_0.spvasm.expected.ir.msl
@ypujante
(And, those would be one of the unit tests of the SPIR-V to WGSL translator, converted to an end-to-end test so we can check the right thing will be emitted on all the backend languages.)
I'm finally at the point where I have to start working on perhaps the main feature of my programming language Squarepants: the ability to compile to GPU Shaders.
The most attractive target would be #SpirV which is an intermediate representation that works almost everywhere... Except on browsers, and only because #Apple didn't want to give control of the standard to the group that develops SpirV.
Instead, Apple imposed #WGSL , which is a language instead than an intermediate representation, so it's a pain in the ass to target and will end up with the same problem as #javascript .
At some point there will be translators from SpirV to WGSL, but I can't rely on those now.
So, what am I going to target?
Right now Squarepants compiles to javascript, so can run easily in both browsers and #nodejs.
There is a project to run SpirV (via Vulkan) on node, but has been dead for years, which means that if I want to compile to a native application, I need Squarepants to compile to C or LLVM first.
OTOH if I go through the square-peg-in-round-hole and target WGSL, then I can target browsers.
I've been working a lot with #glsl for a while now, writing complex code. Overall, I feel like the single improvement that would make the most difference for the language would be support for pass-by-reference instead of copy in/copy out syntax, as suggested here https://github.com/KhronosGroup/GLSL/issues/84
This would make it possible to do a lot of things that are either not possible or ridiculously inefficient to compile, including object oriented programming.
And it also has a no aliasing restriction; you can't have two names for the same variable memory and have a RW, WR, or WW hazard in the same function. https://www.w3.org/TR/WGSL/#alias-analysis
And with all that our compiler does call site specialization until it boils those pointer params away. It's convenient for the programmer but can bloat code size (hopefully no more than hand rolling it yourself)
My version of a kishimisu (instagram.com/kishimisu/) style shader, after following his YouTube tutorial but in #webgpu. Mostly all things are translatable from #glsl to #wgsl
A warm welcome to all the #GIS, #GeoViz & #RemoteSensing people who started following me over the past few days (not 100% sure why, though!)
😉👋
I'm nothing more than an enthusiast in this field, but do a have strong interest (and prior experience) in mapping/visualization and also would like to work more again in that field. So here's a short thread about a few related tools and artistic projects I've been working on over the past couple of years (all work-in-progress)...
This web-based shader graph editor started in 2020 and is in urgent need to be developed further (i.e. to support loading & saving of projects, #GLSL & #WGSL export). The tool is really more about visual algebra and prototyping in general and so isn't specifically aimed at DEM visualizations, but it provides several useful operators to facilitate such (at least for pre-viz purposes and/or to create custom aesthetics). For example, there're generators for ambient occlusion maps, normal maps, bump mapping, elevation-based color gradients etc. Altogether, there're 36 customizable generators & operators, some also animated. Images (up to 4K res) can be imported via drag & drop. Currently only supports JPG/PNG, GeoTIFF will have to be pre-converted for now. If there's interest, I can record a quick video walkthrough of the tool...
The attached screenshots show some of the graphs/workflows I've used to produce visualizations & artwork for prints. You can (maybe, who can say these days?) also find more examples (incl. videos) on my old Twitter:
As I discuss in the post, in the long term I'm hopeful for a future with robust GPU compute infrastructure, based on well-documented standards and rigorous testing so that we can be confident that GPU hardware will actually run our code (including sophisticated lock-free algorithms). We have a long way to go, and I think #WGSL is a better path toward that future than proprietary GPU languages.