ppenenko

I commiserate with your frustration with developers writing things suboptimally all too often. However, I disagree with the assumption that it's a JS/Python vs C issue.

Example: when VS Code came out, it was much, much faster, more responsive and stable than Visual Studio at the time. Despite being based on Electron, it apparently was much better on architecture, algorithms and multithreading than VS with its C++ and .NET legacy codebase. That really impressed me, as a C++ programmer.

Overall, it feels like folks who idealize bygone eras of computing didn't witness or have forgotten how slow Windows, VS, Office etc. used to feel in the 90s.

I got to speak about my Python-based GPU EDSL https://github.com/ppenenko/metashade at the Academy Software Foundation Open Source Days 2024 (https://opensourcedays2024.sched.com/event/1e2Gx), and here's the video: https://youtu.be/yC8VMLXYs5U?si=rXnEeCxmBym7bwaq Hope it's easier to digest than the slides I shared before: https://news.ycombinator.com/item?id=40110072

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

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.

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.

Cheers Thomas!