02:57DavidHeidelberg: karolherbst: btw. why is the llvmpipe rusticl still guarded by the env?
03:16DavidHeidelberg: I briefly looked at skips/fails/flakes it's not that bad? Why am I asking is, that many distros don't built Clover, thou currently even with llvmpipe you could be better than with some fallback?
03:16DavidHeidelberg: s/many/some/
06:07karolherbst: DavidHeidelberg: good question... Maybe because it's a CPU impl and sometimes significantly slower than other CPU impls like pocl. so there isn't really any benefit for users having llvmpipe used over pocl or so
06:07karolherbst: but...
06:07karolherbst: maybe I can also just enable it
06:07karolherbst: I want to enable some drivers by default for 24.2/24.3 anyway
06:07karolherbst: just wondering how I want to go about it without causing too much breakage randomly
06:08karolherbst: it's kinda scary tbh
06:08DavidHeidelberg: karolherbst: can it be the last one in the list?
06:08DavidHeidelberg: because if the list is empty, it could be still good
06:08karolherbst: that's not how it works in CL
06:09karolherbst: normall
06:09karolherbst: y
06:09DavidHeidelberg: oh, then it make sense
06:09karolherbst: but applications might ask for GPU devices only, so llvmpipe won't be used anyway
06:10karolherbst: mostly
06:10karolherbst: you can also ask for all devices, but anyway, device selection is up to the application
06:10DavidHeidelberg: I think I saw some benchs, that for CL workloads it's sometimes more worth it to run it on CPU as CL kernel than real code.. but not sure how often it's true
06:10karolherbst: yeah.. it's kinda hard, because some applications are also simply written in a terrible way
06:11karolherbst: sometimes they bothered to parallize the CL code more, or whatever reasons there might be
06:12DavidHeidelberg: my thinking is: we have a Linux. If we get shipped OCL everywhere, people can start relying on it. If it's sometimes, somewhere, maybe, then everyone thinks "I need to implement fallback anyway, it's not worth it"
06:12karolherbst: anyway, I'm less concerned about performance, but about breaking stuff
06:12karolherbst: yeah...
06:13DavidHeidelberg: for example Linux phones, older doesn't have CL (e.g. PinePhone 1), but if few people stay at PP and still can fallback to something slow, you don't have to invest additional resources
06:13DavidHeidelberg: and we can have accelerated stuff in phone apps
06:13karolherbst: sure, but there is pocl already, so people could already do that
06:14karolherbst: so yeah, I kinda focus more on getting stuff to work on GPUs
06:15DavidHeidelberg:kinda focuses on dependency hell of libclc/clang and all the stuff which arm64 will now need...
06:17DavidHeidelberg: hmm, so for the software part the PoCL could be solution, that's right
06:18karolherbst: for now at least
06:22DavidHeidelberg: that's what you get when you enable llvm+rusticl on arm64 :'( https://gitlab.freedesktop.org/dh/mesa/-/jobs/59135371
06:22DavidHeidelberg:going to cry quietly until he falls asleep
06:23DavidHeidelberg: of course completly unrelated (maybe the llvm part)
06:23karolherbst: ohh, I know that one
06:23karolherbst: DavidHeidelberg: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26680
06:23karolherbst: but like.. it's all a bit cursed
06:24DavidHeidelberg: oh I see that one :D
06:24DavidHeidelberg: thanks
06:25karolherbst: yeah, but some drivers exposing their screen globally doesn't really help here with this issue.. so might as well just accept that drivers are like that and find a solution more suitable for that
06:28DavidHeidelberg: *saw that one
06:28DavidHeidelberg: So, if this works out, arm64 devices should be ready to test rusticl (well, at least after this one gets merged or addressed differently)
06:30karolherbst: yeah
06:35DavidHeidelberg: btw. if you will be around, I'll try to drop MR soon for a review
06:41DavidHeidelberg: karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29394
13:17ernstp: tjaalton: vulkan nouveau for debian/ubuntu... seems tricky to get all the pieces together right?
14:03DemiMarie: DavidHeidelberg: how bad is OpenCL-on-CPU compared to hand-written SIMD code or something like the Intel SPMD compiler?
14:04DemiMarie: Another factor to consider is that just because one’s GPU has OpenCL support doesn’t mean one’s workload can use it. IIUC lots of scientific code requires double precision and many GPUs don’t have that.
15:31karolherbst: DemiMarie: probably worse, because there is quite some overhead around launching kernels and stuff
15:32karolherbst: though I wonder if we could make it consumable by ispc
16:42furiouswendy: so the final bits are as simple now that we had encoder/decoder and data storing formula done, it follows the same data format offset+index+value+distancefromconst but now it's that data stream only one of this per answer set, and primary operation is subtract where the magic takes place, you add compact operands to the subtracter bottom src parameter, and add offset too, also you input
16:42furiouswendy: distances now once you subtract a value and distance from that it yields index for every offset, you can compute gazillions of alus that way, and it's the final revision of my research, I do not expect to get more storage efficiency or performance than this, it's just insane what it can do, so support for 16 bit controllers I added this way to emulate 64bit or 32bit, and it really is my
16:42furiouswendy: final words, also stop playing victims dudes you get higher sanctions this way!
17:29SolarAquarion: src/gallium/frontends/rusticl/rusticl_mesa_bindings.c:1:10: fatal error: ../mesa/src/gallium/frontends/rusticl/rusticl_mesa_bindings.h: No such file or directory
17:29SolarAquarion: 1 | #include "../mesa/src/gallium/frontends/rusticl/rusticl_mesa_bindings.h"
17:29SolarAquarion: | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
17:29SolarAquarion: compilation terminated.
17:29SolarAquarion: what the hll is going on?
17:29SolarAquarion: hell
17:29SolarAquarion: src/gallium/frontends/rusticl/rusticl_mesa_bindings.c:1:10: fatal error: ../mesa/src/gallium/frontends/rusticl/rusticl_mesa_bindings.h: No such file or directory
17:29SolarAquarion: 1 | #include "../mesa/src/gallium/frontends/rusticl/rusticl_mesa_bindings.h"
17:29SolarAquarion: | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
17:29SolarAquarion: compilation terminated.
17:30SolarAquarion: the file is there and all
17:31SolarAquarion: https://paste.debian.net/1318089/
17:38SolarAquarion: ah, i see
17:48DavidHeidelberg: DemiMarie: I think the question is, if you have good enough OpenCL everywhere for your use-case, if you going to write SIMD code :P
19:36DemiMarie: DavidHeidelberg: probably not, but a compiler could generate SIMT-style SIMD that is likely better than what LLVM would do on its own.
19:54karolherbst: SolarAquarion: I have a MR for that: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29275
19:54karolherbst: will get back to it next week
20:27robbielex: you disturbed my friends, assaulted me and tried to kill me everywhere I went for all the times where my family invested money in stacks, and you are penniless obnoxious mindill fuckers, of course you get charges and you already did, major batch of sanctions will hit the line once more, and if you do not stop the terror you end up slaughtered, ouh I am sure, your achievements are non
20:27robbielex: existing it hurts to look at your bitset implementation and you have no money, nor wisdom, I do all the code for you my own and you treat me with terror and tyranny, since I am doing quite well after you failed to kill me, I hope you understand that threat to you, you do this again in public places like was done in Cambodia, your delegation is immediately ambushed. It's cause I started to
20:27robbielex: seriously invest with my lines to finish such people, very nasty not sure why the hell do you see such delusions, I started to like kennylevinsen and emersion tbh. goguma is the mobile software I use to log in and tell those wisdom snippets I gathered with 30 years, so emersion Simon See wrote that client, I just noticed on fdroid that it had an update 5months ago, there's nothing special I
20:27robbielex: did, cause honestly I do not have time under excessive tyranny by incapable people myself to write irc related code, I already graduated me feed and gave you all the important, and wish you luck from now on and advise to not get into doing what you did in Cambodia or your delegation is smashed.
21:53tjaalton: ernstp: needs newer rust than what debian has right now
22:43DavidHeidelberg: karolherbst: if you can lay eye on https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/919
22:47DavidHeidelberg: I'm hitting Could not get number of platforms: (unrecognized error)
22:47DavidHeidelberg: which is way for piglit say the CL error is not in a range of 0-68 (after MR -72)