iiinova — where your digital self keeps evolving

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 💛

010

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...

130

But in easl you actually can define this operator for real! Here's what the code for that looks like.

A screenshot of easl code implementing an operator for twisting a signed distance function

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 Inigo Quilez's website, showing the code for an operation for twisting signed distance functions

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!

A screenshot of an Easl program implementing a raymarcher

130

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.

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.

A screenshot of a window displaying a red triangle on a blackground

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 - Ella-Hoeppner/easl: Enhanced Abstraction Shader Language, a functional shader language written in Rust

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

github.com

Enhanced Abstraction Shader Language, a functional shader language written in Rust - Ella-Hoeppner/easl