07:08 <lina> alyssa: Is there some way of compiling GLSL for an internal shader in mesa, and some reasonable way of adding intrinsics to it?

07:09 <lina> For the compute context save/restore/misc blob, the logic is complicated enough I don't want to be messing around with assembly/binary (or building it in raw NIR), but I need some way of inserting at the very least some special register loads and some still-mysterious instructions...

11:54 <karolherbst> lina: sooo... intel is using OpenCL C to implement ray traycing. They compile it to spir-v/nir and use that at runtime

11:56 <karolherbst> You can, in theory, use whatever language you want to compile to llvm and then to spir-v, but we have some internal tooling around for CL C and GLSL specifically

11:59 <cwabbott> radv uses glslang to compile GLSL to SPIR-V, Intel uses OpenCL C because that's what the Windows driver is using and the kernels are shared between drivers

12:00 <cwabbott> glslang is a lighter weight dependency and might be better for intrinsics because there's a SPIR-V intrinsics thing that allows you to insert SPIR-V more or less directly

12:01 <cwabbott> however you'd still have to define your own SPIR-V extension somehow, not sure what the process for that is

15:57 <alyssa> NIR builder is probably still the sane way to go.

15:58 <alyssa> I don't remember the blob being that big

15:59 <alyssa> Also, I would just straight up use the blob first, and then once it's properly working look into reverse-engineering the fine details and replacing it.

16:00 <alyssa> dougall: mentioned he was interested in r/e'ing that

16:12 <lina> alyssa: I already looked through some of it, I'll probably cover it during tomorrow's stream ^^

16:12 <lina> dougall might want to look at the mystery instructions though

16:12 <lina> I'm more interested in what it's doing at a higher level and how to replace it

16:13 <lina> The main reason I wanted a higher level actual language is that it has to deal with data structures to some extent, and a big outer switch statement inside a loop, and it just feels pretty painful to write all that in NIR...

16:14 <lina> It's funky, I think one of the special registers is actually a FIFO? The outer loop and the way it reads one register twice and adds together the values makes no sense otherwise.

16:15 <alyssa> what register #?

16:18 <lina> 146/147 is the save/restore context descriptor pointer, but then 144 seems to be a command FIFO, and after reading that it reads 146 again and (for some commands) treats it as an offset into a pointer which only makes any sense if reading 144 pops the FIFO and 146/147 are a data payload.

16:19 <lina> I only ever saw command 0xf, which is the one that runs some mystery instructions and terminates, and never saw 146/147 changing, but that would make sense if there is only one item in the FIFO here

16:19 <lina> Also I'm pretty sure 20 is core ID

16:20 <alyssa> plausible

16:22 <lina> Those are the only SRs it reads

16:22 <lina> Also this is all assuming I'm reading the shader asm correctly... I'm not exactly used to it ^^;;