17:31fdobridge: <gfxstrand> `mme_loop` cannot be nested. `mme_while` is fine currently because it's implemented using a simple conditional branch.
17:32fdobridge: <gfxstrand> What I've done in most of the MMEs I've written is to use `mme_loop` only for very tight inner loops and use `mme_while` for everything else.
17:49fdobridge: <nanokatze> time to make a compiler for mme and write macros in glsl or something of that kind 🐸
20:50fdobridge: <karolherbst🐧🦀> just write an llvm backend....
20:51HdkR: Yea, easy peasy. :sweat:
21:39fdobridge: <gfxstrand> I did half-seriously consider making a NIR back-end
21:39fdobridge: <🌺 ¿butterflies? 🌸> Uh oh
21:40fdobridge: <🌺 ¿butterflies? 🌸> hot take: llvm-spirv -> SPIR-V -> NIR is perhaps enough
21:40fdobridge: <gfxstrand> I wasn't suggesting getting LLVM involved at all.
21:43fdobridge: <🌺 ¿butterflies? 🌸> Oh, did you mean NIR backend for what?
22:00fdobridge: <gfxstrand> I mean a NIR back-end for the MME.
22:01fdobridge: <gfxstrand> Depending on how many MMEs we end up with and how much difference there is between the Kepler MME and the Turing MME, having a real compiler may be the best way to resolve those differences.
22:01fdobridge: <gfxstrand> I don't really want to do that if we don't have to because it certainly seems like overkill.
22:10fdobridge: <🌺 ¿butterflies? 🌸> Oh