| 10 Feb 2026 |
 Puna | i enabled glslang tests recently and added links to upstream issues (happens on all non-LE targets): https://github.com/NixOS/nixpkgs/pull/479398#issuecomment-3745287964
i really don't have the time nor energy to fix this myself though, so I don't expect it to get fixed soon. the packages still build, but their functionality is not quite right. | 06:00:07 |
| Puna | build mesa for BE i guess? | 06:00:21 |
| Puna | i don't know what else uses this translation stuff | 06:00:31 |
 K900 | Yeah | 06:01:59 |
| Puna | ah no, cross to BE uses the mesa_clc from the build platform, so it doesn't run into this misparsing situation. you'd have to build mesa on BE then… | 06:15:38 |
| Puna | bigger ask i think, with no cache around to help | 06:16:36 |
| K900 | Wait, how does that even work | 06:16:46 |
| K900 | Like does mesa_clc even handle mixed endianness | 06:16:58 |
| K900 | Because SPIR-V is host endian | 06:17:03 |
| K900 | For some utterly idiotic reason | 06:17:08 |
| Puna | couldn't tell you, but the message that it prints when it falls on its face is from SPIRV-Tools i think
(file=input,line=0,column=0,index=7): Invalid extended instruction import 'nepOs.LC'
https://github.com/KhronosGroup/SPIRV-Tools/blob/f139c64525c7c449c83d299a9fda4e1657bf37ab/source/binary.cpp#L629 | 06:20:54 |
| K900 | No but like, it works on cross, right? | 06:21:24 |
| K900 | Well, "works" | 06:21:26 |
| Puna | got to 2118/5415, then it failed on another format error that i'll need to submit a fix for… | 06:22:37 |
| Puna | mesa-powerpc64-unknown-linux-gnuabielfv> [2012/5415] Compiling C object src/nouveau/headers/libnvidia_headers_c.a.p/nv_push.c.o
mesa-powerpc64-unknown-linux-gnuabielfv> [2013/5415] Generating src/nouveau/vulkan/nvkcl.spv with a custom command
mesa-powerpc64-unknown-linux-gnuabielfv> [2014/5415] Compiling C object src/asahi/compiler/libasahi_compiler.a.p/agx_liveness.c.o
| 06:26:34 |
| Puna | * [213/5415] Compiling C object src/compiler/nir/libnir.a.p/nir_functions.c.o
[214/5415] Generating src/asahi/libagx/libagx.spv with a custom command
[215/5415] Compiling C object src/compiler/nir/libnir.a.p/nir_gather_info.c.o
| 06:27:37 |
| Puna | that's the .spv file that fails to generate on BE hardware | 06:27:48 |
| Puna | ¯\_(ツ)_/¯ | 06:27:57 |
| Puna | * that's the first .spv file that fails to generate on BE hardware | 06:28:14 |
| K900 | I wonder if literally anyone is expecting literally any of this shit to work tbh | 06:28:21 |
| K900 | Because like | 06:28:26 |
 Lotte (it/its)/Cinny (she/her) θΔ& | do apple silicon chips even support big endian mode? | 06:28:25 |
| K900 | You don't write "the IR is host endian" into your spec if you have EVER used a BE system | 06:28:45 |
| Puna | we build all drivers on all platforms | 06:29:03 |
| K900 | And more specifically Asahi we build on all platforms because it also outputs the standalone shader compiler for the build platform | 06:29:39 |
| Puna | # We enable as many drivers as possible here, to build cross tools
# and support emulation use cases (emulated x86_64 on aarch64, etc)
| 06:29:41 |
| K900 | Which we need to use for cross | 06:29:43 |
| Lotte (it/its)/Cinny (she/her) θΔ& | ah | 06:29:57 |
| Puna | i doubt anyone's doing asahi dev on 20yo PowerMacs, but y'know | 06:30:52 |
| Lotte (it/its)/Cinny (she/her) θΔ& | probably because the predominant architectures over the past two decades or so have just been little endian
but also like it costs very little to go “the ir is little endian”, loading/storing little endian data is cheap on ppc
| 06:31:49 |
