Show HN: Metashade – a Pythonic GPU shading/compute EDSL | Hacker News Reader

Show HN: Metashade – a Pythonic GPU shading/compute EDSL

github.com

47 pointsppenenko8 comments

Superficially, it may look similar to Nvidia's Warp or OpenAI's Triton, but instead of transpiling a subset of Python to the target language, it implements dynamic codegen in pure Python.

These slides discuss the existing GPU programming solutions and make a case for Metashade's approach: https://docs.google.com/presentation/d/e/2PACX-1vQtYIwXIkMnV...

Open articleView on HN

I was using Taichi recently to prototype some fragment shaders (I just mocked out texelFetch, texture, etc and wrote a for loop over each pixel). I found it convenient to be able to run on the CPU and also not have to deal with any OpenGL or Vulkan setup.

One thing that was frustrating was that I couldn't template a function with another function (as far as I know). That lead to some copied and pasted code when I had multiple implementations that I wanted to compare. Can Metashade do that?

Agreed that the ability to just run on the CPU is valuable. Metashade doesn't support that yet and its codegen syntax doesn't look like regular Python code (everything codegen-related is prefixed with `sh.` etc.) but it's certainly possible to write a generator that would just execute the code "in the immediate mode" or generate C/C++ code for the CPU.

Regarding templating functions with functions - in Metashade you can just specialize the generated code however you see fit, with Python as the meta language. E.g. Python's `if` statements can act like `#ifdef`s or `if constexpr`, and you can certainly pass around callables to parameterize behavior.

Super interesting project. Been looking into template generation and uber shaders to make coding shaders easier for the game engine Ursina. I'm going to bring this to their attention.

Would it be easy to add another target like glsl?

Thanks!

Multiple targets is definitely the plan, and GLSL is my next priority. Metashade can currently generate HLSL for the DX12 version of https://github.com/ppenenko/glTFSample/tree/metashade_demo, and there's also a Vulkan version of that demo using GLSL. So implementing GLSL generation for that would be a great proof of concept and a test bed: HLSL and GLSL generated from single source and producing identical rendering results.

The diagram on slide 31 of my presentation shows how implementation is currently inherited between the Metashade packages. The future GLSL generators should inherit common functionality from the "rtsl" package, just like the existing HLSL generators. However, I expect heavy refactoring to be necessary because I was initially targeting just one language and so not all code is implemented at the appropriate level.

BTW, here's a poll where you can vote for a target language you'd like to see prioritized: https://github.com/ppenenko/metashade/discussions/17

Wouldn't jinja templates would have sufficed for this? I'm not sure it's a good idea to create a whole new language just for getting templating capabilities to shaders.

No, I don't believe Jinja would suffice. For starters, how would you abstract out the syntax differences between, say, HLSL and WGSL? Jinja's approach seems to be taking the syntax of the target language and embedding templating into it. But with Metashade, we're replacing the different syntaxes of individual target languages with that of Python. Since this approach is largely agnostic of the target language syntax, new targets can be added in the future without rewriting target-independent, polymorphic code implementing rendering or compute techniques.

Hi Pavlo, nice to see you here and thanks for the presentation at Maxon :)

Cheers Thomas!

Reply on news.ycombinator.com