That said, it's definitely at a stage where it's worth trying out if you're interested in shader programming! If you run into any bugs while using it, feel free to reach out to me in DMs or raise an issue on the github 💛
I wouldn't call easl "production ready" quite yet. The CPU runtime especially is early-stages and needs a lot of work, and while the shader compiler is comparatively robust, it has a few missing features (see the README for details), and also surely has many undiscovered bugs.
Crucially, there's no performance cost for writing your shaders this way!
Easl compiles to normal wgsl, and the compiler inlines all higher-order arguments at compile-time. So higher-order functions in easl are a "zero-cost abstraction", just like all of easl's other features.
And here's an example program that uses the above function with a raymarcher. The full code show in the video is available here, if you wanna run it for yourself: github.com/Ella-Hoeppne...
A screenshot of easl code implementing an operator for twisting a signed distance function
But in easl you actually can define this operator for real! Here's what the code for that looks like.
A screenshot of Inigo Quilez's website, showing the code for an operation for twisting signed distance functions
As another example, consider this screenshot from @iquilezles.bsky.social's page on SDF operations. The "sdf3d" type here doesn't really exist, so this code won't actually compile - it's just for explanatory purposes, a helpful mental model to imagine "passing" an SDF to this "operator".
A screenshot of an Easl program implementing a raymarcher
Even purely on the GPU side, higher-order functions are extremely useful. For example, here's a raymarching implementation that takes an SDF as an argument. In other languages you have to just hard-code the SDF in, but this one lets you plug one in any SDF as an argument!
And since the GPU and CPU are sharing one language here, the type system can do compile-time validation of your program in ways that traditional frameworks have to defer to run-time, like checking that your fragment and vertex shaders have compatible input/output types.
An image of a short Easl program
A screenshot of a window displaying a red triangle on a blackground
Here's a simple "hello world" program showing how that can look in practice. This just render a solid-color triangle to the screen, but it only takes a few lines of easl to accomplish that, compared to the hundreds it usually takes in traditional graphics frameworks.
Easl also has a CPU runtime that can seamlessly interface with the GPU. To run your shaders from the CPU, you just call the `dispatch-render-shaders` function, which takes two functions as inputs, representing a vertex shader and fragment shader.
github.com/Ella-Hoeppne...
Some of the main features that easl has to offer over traditional shader languages:
- Expression-based syntax
- Higher-order functions
- Closures
- Sum types and match blocks
- Function overloading
- Generics
I've been working on a new shader language called "easl". The goal is to bring the conveniences you'd expect from a high-level language to the GPU. It's still got some rough edges, but if you're into shaders or creative coding you should check it out! More info in the thread 👇
SIDEREAL CONTACT IMMINENT
Join us, and very special guest Celeste (/Parafactual) for a very special Flight (/Bsky meetup),
at The National Arboretum, from noon-five today.
We’re meeting at ‘the columns’, and picnicking under an adjacent tree.
