| 10 Feb 2026 |
 K900 | @Puna so uh, Debian has llvm-spirv-translator on ppc64be | 05:35:44 |
| K900 | Can we look at what they're doing maybe | 05:35:53 |
 Puna | debian doesn't build any of the OpenCL-based drivers on ppc64 I think | 05:42:15 |
| Puna | * debian doesn't build any of the OpenCL-based drivers on ppc64 I think? | 05:42:44 |
| K900 | I mean I guess it's possible that they have the package and it just like | 05:43:37 |
| K900 | Doesn't work at all | 05:43:39 |
| K900 | But that would be sus | 05:43:42 |
| K900 | But like it's definitely there: https://packages.debian.org/sid/llvm-spirv-21 | 05:45:18 |
| K900 | And they don't patch it or anything :https://sources.debian.org/patches/spirv-llvm-translator-21/21.1.3-1/ | 05:45:42 |
| K900 | * And they don't patch it or anything: https://sources.debian.org/patches/spirv-llvm-translator-21/21.1.3-1/ | 05:45:46 |
| Puna | the thing is that glslang, spirv-tools and spirv-llvm-translator all just have parsing bugs on big-endian AFAICT. both in their test suites (most of which we don't run) and when you try to translate existing stuff with them. i just picked spirv-llvm-translator as the scapegoat here (and we likely won't be able to run its test suite, cus it wants LLVM's lit and that seems annoying to set up).
https://catfox.life/2024/11/29/the-complexities-of-enabling-opencl-support/ | 05:46:49 |
| K900 | Running the test suite should be possible I think | 05:47:33 |
| Puna | * the thing is that glslang, spirv-tools and spirv-llvm-translator all just have parsing bugs on big-endian AFAICT. both in their test suites (most of which we don't run) and when you try to translate existing stuff with them. i just picked spirv-llvm-translator as the scapegoat here (and we likely won't be able to run its test suite, cus it wants LLVM's lit and that seems annoying to set up outside of LLVM).
https://catfox.life/2024/11/29/the-complexities-of-enabling-opencl-support/ | 05:47:39 |
| K900 | Conceptually | 05:47:48 |
| Puna | gallium: softpipe nouveau r300 r600 virgl
vulkan: nouveau gfxstream
nouveau uses OpenCL in current mesa, but mesa on ppc64 debian is held back at 25.0.7-2… | 05:50:57 |
| K900 | Mostly what I'm thinking is, it would be very nice for future reference to have an actual record of what is failing | 05:51:03 |
| K900 | And ideally once it's all fixed, we can reenable everything and then keep testing so it doesn't regress | 05:51:33 |
| K900 | Instead of just having a blanket "oh yeah this is broken forever" | 05:51:50 |
| K900 | I don't want to block on this | 05:52:46 |
| K900 | But the whole thing also feels so icky | 05:52:58 |
| K900 | Like we're disabling shit based on blog posts from three years ago | 05:53:08 |
| K900 | And vibes | 05:53:12 |
| Puna | nouveau in 25.0.7 did not yet use OpenCL, so they likely just don't run into usage of this stuff… don't know how to browse debian's stuff to figure out why the package is held back on ppc64, if they've documented their reason somewhere… | 05:54:31 |
| Puna | the failures still happen, i can add the mesa build error to the comment in spirv-llvm-translator if that helps. | 05:58:09 |
| K900 | Maybe not the error but like, a guideline on how to reproduce it | 05:59:00 |
| 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 |
