00:04mareko: DavidHeidelberg: new version: https://gitlab.freedesktop.org/mareko/mesa/-/commit/6bbbee93608f235bc372a380afb901934cbb2ae4
00:06DavidHeidelberg: mareko: no longer crashes (thou the test fails, but that's likely on the Nine side)
00:06DavidHeidelberg: thank you! mareko should I open MR with your change or do u want to?
00:10DavidHeidelberg: btw. the line "[TGSI_OPCODE_TG4] = 0," is duplicit
00:27mareko: DavidHeidelberg: I'd like some evidence that it works
00:38DavidHeidelberg: mareko: ./NineTests/NineTests --gtest_filter="Xnine.fetch4" latest code is pushed into https://github.com/iXit/nine-tests/tree/visual.h
00:39DavidHeidelberg: cmake . -D BUILD_TESTS=ON && make -j7
00:54DavidHeidelberg: beware for this test you need branch named visual.h
01:05mareko: DavidHeidelberg: I believe you, but it would be better to have a TG4 test that passes
02:23mareko: DavidHeidelberg: also it will fail with llvmpipe, but should work with other drivers
08:47DavidHeidelberg: mareko: idea, I'll test against r300 which is on TGSI, there the test should fail same way (in ideal conditions)
14:12tarhun: The scala carries very deep mathematical science soul in this, and the way bitset is programmed represents their very deep mathematical insights and soul, it has not much to figure out from the programming side, in any of the languages, cause it's about mersenne numbers. carries historical reference and signifficance.
14:18tarhun: the odds are 99:1 that you would not figure it out from the programming standpoint, or computer science, it's rooted into pure maths though instead. Ancient central europes math where euler and mersenne lived etc.
14:19tarhun: you end up doing something that you match against closest mersenne number and count the bits likely.
14:21tarhun: this is a very deep concept but that was 15. century and forward in central europe when they had such thinkers
14:27tarhun: it's a combined art, where outside mathematics computer solves things in certain ways, for an example, the loops can subscale to a refined results, to correct the false positives
14:28tarhun: so it's not pure math either cause computer solves it one of it's kind in unique but not common way
14:31tarhun: so it's a predicate that tests based of the condition that equals zero, how much false positives there will be, and eliminates them inside of the loop
14:32tarhun: that is an iterative algorithm, but today higher modern computers are very good at it
14:34tarhun: it's a second best today cause it's almost as good as the other for only newer computers though, and the method is very big englightnment
14:34tarhun: they are not competing those methods, cause one is already in hardware :)
14:36tarhun: those loops done with opencl kernels would work very well
14:36tarhun: however something different would work even better
14:37tarhun: this how the algorithm recovers from bad match is indeed divide and conquer
17:50DavidHeidelberg: mareko: did u managed to run the test (it's pretty small simple, no extra deps stuff)? It currently runs in our CI for r300, but in older version
18:15DavidHeidelberg: should iris work with LIBGL_DRI3_DISABLE=true?
18:15DavidHeidelberg: (HW TGL)
20:13mareko: DavidHeidelberg: no
20:59mareko: why do some drivers depend on libllvmspirv?
20:59mareko: mainly iris and asahi
21:09kisak: from memory, iris depending on llvmspirv in 24.0 was a false positive. Is your test after https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27663 where that should have been detangled a bit?
21:09karolherbst: mareko: they use OpenCL C to write internal shaders
21:11mareko: kisak: I can't build iris without LLVMSPIRVLib
21:11karolherbst: kisak: nah, they really need that at compile time now
21:11karolherbst: anv as well
21:11mareko: I don't know how to build LLVMSPIRVLib
21:12karolherbst: install a package? otherwise I can throw you my llvm build script
21:12mareko: I use llvm main
21:12karolherbst: okay, then let me pastebin my script in a second
21:16kisak: karolherbst: ah right, intel-clc to support intel-rt. mareko still has a chance of avoiding the dependency with intel raytracing / intel-clc turned off.
21:16karolherbst: mareko: though actually.. if you build llvm+clang in one step, you should be able to simply throw the translator into `llvm-project/llvm/projects/SPIRV-LLVM-Translator` if you build everything independent you need to do something like this: https://gist.githubusercontent.com/karolherbst/55299f6473551e58a16dfa19adc2ca63/raw/270d9ee84e13ab26bfb9af8ff81b95710512aef8/build-all-llvm.sh
21:17karolherbst: translator git url: https://github.com/KhronosGroup/SPIRV-LLVM-Translator.git
21:17karolherbst: kisak: no
21:17karolherbst: it's a hard requirement now
21:18karolherbst: which... now thinking about it, I don't know if debian+ubuntu can handle :D oh well.. not my problem
21:19karolherbst: I think there was something cursed the debian packaging was doing so it wasn't trivial to do?
21:19mareko: do I need the khronos thing as well?
21:19karolherbst: which khronos thing?
21:19mareko: https://github.com/KhronosGroup/SPIRV-LLVM-Translator.git
21:19karolherbst: that's libllvmspirv
21:19karolherbst: ehh or LLVMSPIRVLib
21:20karolherbst: that's how the lib is called, the project just has a different name
21:20karolherbst: it's really just an out of tree llvm component
21:20karolherbst: long term we want to move to the LLVM SPIR-V backend, but that isn't ready yet
21:21mareko: we could also use GLSL compute shaders instead
21:21karolherbst: the idea was to be able to reuse C code
21:22karolherbst: like for intel the genxml stuff is also used there
21:23karolherbst: the translator also has github workflows to built it in-tree and out-of-tree for CI: https://github.com/KhronosGroup/SPIRV-LLVM-Translator/tree/main/.github/workflows
21:24karolherbst: the hard part is only getting the compile flags right, because llvm is cursed there...
21:25mareko: amazing
21:28kisak: Mesa 23.3 on ubuntu wasn't doing intel-clc on the 32 bit build because libllvmspirvlib15 wasn't built for i386 https://packages.ubuntu.com/jammy-updates/libllvmspirvlib15 . mesa 24.0 made that manditory as a false positive in the meson config. tjaalton was nice enough to put in a temporary patch to take care of the false positive
21:28kisak: https://salsa.debian.org/xorg-team/lib/mesa/-/commit/1254f718df1d714e1551ea1dca2231e320fd2ef9 . For the kisak-mesa build, it turned out libllvmspirvlib 15/16/17 have been put on the build farm's i386 whitelist, so I just rebuilt the package this time around to avoid the show stopper. After that !27663 landed to resolve the unintended dependency change.
21:29kisak: Unless something new has come up since 24.0-branchpoint, I don't think the factoid in my head is wrong here.
21:29karolherbst: yeah, it is new for 24.1
21:30kisak: Okay, good to know.
21:30karolherbst: however there is the possitiblity to build intel_clc alone and use that as a dep
21:30karolherbst: but not sure how much sense that makes
21:31enzuru: Hey all. I am working on porting the Rusticl driver to GNU Guix. I have managed to get it to successfully compile and produce a rusticl.icd file. I have set RUSTICL_ENABLE=radeonsi and OCL_ICD_VENDORS=/home/enzuru/src/mesa/builddir/src/gallium/targets/rusticl but clinfo still shows 0 devices... any thoughts on what I should debug?
21:31mareko: I hope I don't need to build clang now: meson.build:1872:23: ERROR: C++ shared or static library 'clangBasic' not found
21:31karolherbst: mareko: you do
21:31mareko: amazing
21:32karolherbst: well.. clang is the OpenCL C frontend we use... I have the random idea to write our own, but.....
21:32karolherbst: enzuru: rusticl is listed as a platform, right?
21:32mareko: I guess I just won't build iris and asahi
21:33karolherbst: well.. my script builds all those things correctly, shared/static whatever you want, but yeah, that's fair, can always let CI tell you when something bad happens
21:34enzuru: karolherbst: nope, clinfo -l shows nothing unfortunately
21:34karolherbst: then rusticl doesn't load
21:35karolherbst: mhh
21:35karolherbst: enzuru: where is the rusticl.icd file installed?
21:35enzuru: it's not installed anywhere, i'm just pointing to the directory in which i compiled it
21:35karolherbst: ahh yeah, that's not supported
21:35enzuru: Guix doesn't install stuff normally so I'm trying to sanity check stuff before I get the packaging right
21:35karolherbst: you need to use `meson devenv` for that
21:36karolherbst: and then it just sets `OCL_ICD_VENDORS` correctly already
21:36karolherbst: and other things
21:36mareko: it just makes changing the gallium interface feel less amazing
21:36enzuru: I tried this "meson devenv -C builddir clinfo -l" and also don't see any devices
21:36karolherbst: sure, but building clang and the translator isn't really that big of a deal honestly
21:36enzuru: or platforms *
21:36karolherbst: at least if you have something point out what flags to set, what my script does
21:37mareko: we should just use zink + dozen for everything ;)
21:38karolherbst: I think that's the long term plan
21:38karolherbst: enzuru: huh.. let me check if something broke. You are having the ocl-icd installed, right?
21:41karolherbst: enzuru: maybe https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28231 broke it...
21:41enzuru: OK, some background. I am using 23.3 because it's a bit more compatible with Guix tooling. I also have mesa-opencl-icd installed through Guix, as opposed to this git repo I am working from.
21:41karolherbst: ohhh
21:41karolherbst: mhhh
21:42mareko: does anybody want to run clang-format on r600
21:42karolherbst: enzuru: what's your `meson configure` output?
21:43karolherbst: and anyway, did you set -Dgallium-rusticl=true?
21:45enzuru: Yes, I do indeed get a rusticl.icd file. Here is the meson configure: https://gist.github.com/enzuru/f30b846fd9c8fc949afbba5def378df3
21:46karolherbst: mhhh
21:46enzuru: I am noticing gallium-opencl is disabled... let me try to fix that
21:46karolherbst: nah
21:46karolherbst: that's alright
21:46karolherbst: should probably rename that flag
21:47karolherbst: enzuru: mind running `LD_DEBUG=libs clinfo`?
21:47karolherbst: within the devenv and stuff
21:50enzuru: Here you go: https://gist.github.com/enzuru/4254eae19aed5f218a581edfba36b848
21:51karolherbst: enzuru: ahh.. that's the khronos loader
21:52karolherbst: enzuru: then you need the MR I linked above
21:52karolherbst: but mhh..
21:52karolherbst: you did point OCL_ICD_VENDORS to the directory, not the file,r ight?
21:52karolherbst: I think you have to end it with a slash...
21:53enzuru: i did to the directory, but i did not end with a slash :) however, i thought none of that mattered if i used meson devenv ?
21:53karolherbst: that MR was opened because it didn't work with the khronos loader
21:55enzuru: Gotcha... let's see if I can "backport" that line to 23.3... should be easy enough
21:55karolherbst: yeah.. though it shouldn't matter after installing anyway
21:55karolherbst: though mhh..
21:56karolherbst: I have no idea how the ocl loader search path stuff would even work? I guess you just install an env file or something?
21:56karolherbst: mhhh...
22:00DemiMarie: Ouch, that is going to be really annoying for distros.
22:00DemiMarie: Does this mean they will need to patch their LLVM?
22:00karolherbst: ?
22:00karolherbst: no
22:00karolherbst: why would they?
22:01DemiMarie: I thought that llvmspirvlib could not be built outside of the LLVM source tree
22:01karolherbst: it can
22:01DemiMarie: Ah
22:01karolherbst: it's how fedora does it at least
22:01karolherbst: it can't if your packaging is broken
22:02enzuru: hmm... no cigar on that line helping with clinfo... hmm
22:02DemiMarie:wishes that glibc was changed to support shared two stage symbol lookup, so that libraries needed by Mesa didn’t cause clashes with libraries needed by applications
22:04clever: DemiMarie: ive had issues (on nixos) due to the version of glibc itself
22:04clever: in my case, steam and glibc are old, but mesa wanted a newer glibc
22:04karolherbst: enunes: enzuruit doens't look like the opencl loader is even trying to load rusticl
22:05karolherbst: enzuru: mind trying with `OCL_ICD_FILENAMES` and pointing to the so file?
22:05enzuru: perhaps this is caused by using the pre-packaged opencl loader ?
22:05karolherbst: it shouldn't be?
22:06enzuru: karolherbst: do you mean to the icd file ? if not, which .so should i be looking for ?
22:07karolherbst: libRusticlOpenCL.so
22:07enzuru: kk
22:07karolherbst: mhh.. though not sure if calls to dlopen appear in that log...
22:12enzuru: here is the output of setting OCL_ICD_FILENAMES to the path to libRuticlOpenCL.so: https://gist.github.com/enzuru/c5b6d41f7d27fcae7a5679d927cffdcc
22:14karolherbst: "/gnu/store/jq6wfyn63iva57b83bmrknafxcsxsn09-profile/lib/libclang-cpp.so.15: error: symbol lookup error: undefined symbol: LLVMInitializeHexagonAsmParser, version LLVM_15 (fatal)"
22:15karolherbst: guess your LLVM is broken
22:16enzuru: Gotcha... interestingly enough, I had to modify Guix's rust-bindgen-cli to be built with Clang 15 in order to avoid this error: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7268
22:16enzuru: so i am wondering if there is some other tomfoolery going on with Clang in Guix
22:17karolherbst: probably
22:20enzuru: understood, thanks for the support. gonna take a break and come back to it later. Guix gets super Inception-y with the profiles (for instance, I am building inside a temporary profile with temporary packages that is different from my home profile) so sometimes it's difficult to reason about
22:28enzuru: maybe i should reach out to whomever packaged Rusticl for Nix :P
22:29enzuru: just bought FF16... that should help me unwind
22:33karolherbst: have fun
22:38DavidHeidelberg: mareko: no was reply to iris on dri2 or nine-tests run?
22:39mareko: nine-tests
22:39DavidHeidelberg: ok