12:53 simon-perretta-img: I'm looking at an issue where the NIR tanh emulation results in tanh(+/-inf) -> +/-0.999999... on cores that have RTZ rounding for f32 and accumulate inaccuracy in the emulated ops
12:53 simon-perretta-img: The tanh float_controls2 tests fail as they expect exactly +/-1.0 for the result, so I'd need to special-case inf inputs if the preserve_inf flag is set on said cores
12:53 simon-perretta-img: Since the emulation gets directly emitted during SPIR-V -> NIR, the options I see for this are:
12:53 simon-perretta-img: a) set has_tanh so SPIR-V->NIR emits an op rather than the emulation, then later have a backend pass lower those ops via nir_tanh_emulated and emit the special-casing there, or
12:53 simon-perretta-img: b) modify nir_tanh_emulated to add the special-casing when preserve_inf is set along with a new flag in spirv_to_nir_options/nir_shader_compiler_options (like lower_fminmax_signed_zero)
12:53 simon-perretta-img: a) has the benefit of not touching common code, though b) could be useful for other drivers that may have the same issue on their hardware but haven't enabled float_controls2 yet
12:53 simon-perretta-img: Are there any strong preferences for/against either option (or something else entirely)? Creating a test branch to enable float_controls2 on every Vk driver that doesn't have it and running a single tanh float_controls2 test on each with CI would clearly determine if b) could be needed by anyone else, but I also suspect that's not really possible/doable lol
13:41 coolGi: Heya ^^ (i'm newish to using IRC, so pls tell me if anything i do is unconventional), i'm currently attempting to cross-compile mesa for an aarch64 target (rock 5b) and can't find many docs to learn from. i've currently setup a `cross-file` with `c`, `cpp`, `ar`, and `strip` pointing to gnu-toolchains-for-arm, and am currently getting errors with clang not being happy with the error "Library clang-cpp
13:41 coolGi: found: NO". i'm on nixos, however i have tried the same thing on a fedora distrobox which has the same error. compiling on board itself works just fine
13:41 coolGi: thanks in advance for any help! (also sorry for the long single-line message, is it possible to do newlines on irc?)
13:42 Hazematman: coolGi It would probably help if you could share your full crossfile as well as the build command you're using and the actual logs. You can use pastebin, github gist, or something else to upload them
13:50 coolGi: alright, sorry that completely passed my mind... here are the 2 files https://pastebin.com/WLfXzcyM https://pastebin.com/Sg6BxTvk (note that pastebin is not liking having the full logfile, so i've pasted in only the 100 final lines)
13:58 Hazematman: What drivers are you building? Because its pulling llvm a dependency. If you're building for example llvmpipe/lavapipe you'll need a version of llvm for your target
13:58 Hazematman: Right now its failing since its trying to link against host llvm which isn't the right arch
14:00 coolGi: i did notice that, but i couldnt find any downloads for llvm cross-compiling to aarch64, would you know where i could find it? (scowering the internet didnt help). currently building with gallium-drivers=panfrost and vulkan-drivers=panfrost
14:54 Hazematman: Okay I think llvm is getting pulled in for clc support. I don't know for sure but I think you can do "-Dmesa_clc=system" to avoid the llvm dep. as for getting an llvm cross compiler dep, sorry I don't remember how to do that
15:02 coolGi: thanks, i'll try that! i mainly just need rusticl, so as long as i can get this and get by without llvm, then i don't really need it ;)
15:02 Hazematman: Ah I think rusticl has a hard llvm dep
15:03 Hazematman: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/meson.build?ref_type=heads#L1055
15:03 Hazematman: clc pulls in the dep on llvm
15:04 Hazematman: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/meson.build?ref_type=heads#L1063
15:04 coolGi: oh, that's a bit annoying :/
15:05 coolGi: i guess i can get by just compiling & developing mesa on the board itself, just preffered to see if i could cross-compile
15:06 coolGi: thanks for the help anyways! tho, if you do have any ideas, i'd love to hear them!
15:08 Hazematman: I suspect there is probably a way you can install a cross compiler llvm on nixos and then point the meson cross file at it's llvm-config executable
15:08 Hazematman: I don't use nixos/nix though so idk how that works
15:09 coolGi: i tried to install the llvm cross-compiler through nix, tho it took ages to build so i stopped it after 2 hours
15:10 coolGi: (hence why i'd rather a precompiled binary right now ><)
15:19 Hazematman: you can try the official release packages https://github.com/llvm/llvm-project/releases/
15:21 coolGi: i did take a look at those, though none of them seem to be build for cross compiling (unless this is something enabled by default in llvm, in which case i wonder why meson isnt picking this up...)
15:22 Hazematman: You can take the none cross compiler arm64 version an do something like whats described in the building llvmpipe for android https://docs.mesa3d.org/drivers/llvmpipe.html#building-for-android
15:22 Hazematman: I.E. Create a llvm/meson.build file that points to the prebuilt libraries without relying on llvm-config
15:23 Hazematman: I suspect you could also just pull the libs off your target too, instead of grabing the github release
15:25 coolGi: i see, i'll take a look into this, tysm! (had a breef look in the past, however didnt fully take it in due to wanting to try and avoid figuring out all the android fluff @_@)
15:27 Hazematman: I think the important part is just the script that generates the subprojects/llvm/meson.build . You'll probably have to tweak that a bit as your llvm build on the target might not have the exact same libs. But then meson should use that for the llvm dep, instead of trying to call llvm-config
15:29 coolGi: ty, i'll see how that goes!
15:37 coolGi: i'm heading off for the night & weekend. thank you so much again for all your help, hopefully it'll work out when i get back!
15:43 Hazematman: No problem, enjoy your weekend! Hopefully it works in the end
16:32 coolGi: quit
16:32 coolGi: (sry, was meant to send that as a / command,,,)
21:38 karolherbst: I'm wondering if anybody has any good ideas to optimize type punning on private memory patterns like this: https://gist.githubusercontent.com/karolherbst/97bc1c64507f1e2bccf82ce6017d4b3f/raw/00e4cd8e6e77b37ae07784cb2eaa4b8c3af7c5ac/gistfile1.txt
21:38 karolherbst: scratch store with uint + scratch load with float e.g.
21:39 karolherbst: copy prop should just deal with this, no? Or any other pass, but the deref aliasing thing says no, because the type differs