08:03 BacardiAltium: What really happened was i started to smoke weed in couple of days when i first wrote to get rid of the tension handle the pressure, now i figured that the reference point was never shifting away, which means that i have six methods to access the members on data, so the testing is so difficult when you ban and boot my brain off. However i am already being accused of torning the us economy
08:03 BacardiAltium: indirectly, i saw some threads. First i was indirectly accused for being Russian supporter, it goes worse and worse to me, but i might get the code working, what i say is that selecting and testing takes the most time of mine, i am programming this entirely alone, but there is some large X group that supports me with VPNs as i can see, i think Russians have been behind my back for ages,
08:03 BacardiAltium: and i just try not to betray them. It's all politics i am not a big fan of ukraine and russia being in war at all. Maybe i get handled in another assault, so i need someone to guard me anyways. But the coding phase will be shorter than the testing and selection of an algorithm.
08:33 BillionCoding: So in may 15n i started the first below indexing, and on the third index i magically screwed up, i was testing the sixth member and fourth member, and used indexes of sixth where i also did not add the 4, and now i deciphered that the bookkeeping shifted away from it cause of my mistake, so 16+4 is correct cause 24 on one end needs -4 cause of reference, than 12+4 is also correct which is
08:33 BillionCoding: 16, but the third sigma proof goes wrong, it should be 124−120−60+27+27+4=2 but the base needs to be stretched anyways to accommodate more stuff, now there is just so many ways to do it, so the reference point of 122 was entirely correct, yeah well i just make mistakes with rushing through stuff. But the info is yeah so classy that some managed to figure out, and see that economy goes
08:33 BillionCoding: down with such code.
09:03 Andinekkonen: I gave all my heart to open source development and tried to be there for anyone who had as deep troubles in life, so deep to come to dirty me, but now maybe the results are not as good, maybe i should had not done this all, a person who can not help oneself is maybe not worth an effort, i am one of the biggest contributors to sanity as well as results we have today, but there are always
09:03 Andinekkonen: some who never like this, my job also is nearing towards the end tbh. But it's not like i could not earn legally, which i started from first minute when the sanctions were over, i am only widening my grip there, but i am no longer around and there for you , you'll gonna have to take care of yourself now too, and i really think that from such position you'd be capable in doing it, just by
09:03 Andinekkonen: dropping all the evil and fraud etc. Commit yourself to something better than scam, fraud,gangsta issues, evilness , hatrism etc. Things start to roll on it's own for way better , thinking you can manage i suppose regardless of the devil inside of you, if you drop the last it goes even better.
09:53 vbb9[d]: What is this chat
10:19 karolherbst[d]: just a person who is around for a decade and doesn't stop it
12:33 gfxstrand[d]: I'm so tempted to write a banbot and try to somehow integrate it into the bridge. I just really don't want to waste my time on it
12:34 gfxstrand[d]: Or just disable the bridge
12:34 gfxstrand[d]: Bridge matrix directly instead
12:36 asdqueerfromeu[d]: gfxstrand[d]: I'm not sure how many IRC users use Matrix though (and also Matrix has its own issues)
12:37 gfxstrand[d]: Yeah, there are no good solutions
12:38 gfxstrand[d]: But he's a solid half of our IRC traffic or more.
12:58 karolherbst[d]: gfxstrand[d]: what would you ban tho
12:59 karolherbst[d]: we could try to ban all VPN networks, but... he might also just get random VPS then
12:59 karolherbst[d]: also each nick is registered and authenticated
13:00 gfxstrand[d]: Yeah. It would basically have to be an ML model
13:01 karolherbst[d]: matrix suffers from the same issue tho, if you really want to, you can just spam the network and nobody can do a thing
13:01 karolherbst[d]: gfxstrand[d]: not the worst idea
13:01 karolherbst[d]: wondering how reliable those things are to detect a certain person
13:02 karolherbst[d]: if somebody wants to investigate it, might make sense to first only report the detection and if it's reliable enough we can also act on it automatically
13:02 karolherbst[d]: though
13:02 karolherbst[d]: what would that help with?
13:03 karolherbst[d]: he gets 1-3 messages through, gets banned and moves to a new account
13:03 karolherbst[d]: well.. at least on non IRC the bot could clean up the messages
13:03 gfxstrand[d]: It would have to get integrated into the bridge so we'd never see the messages
13:03 karolherbst[d]: right...
13:04 karolherbst[d]: maybe we can also ask the IRC admins if it could be done on their end
13:05 asdqueerfromeu[d]: gfxstrand[d]: That's trained on that person's messages?
13:40 f_: karolherbst: dwfreed said he can recognise the person before they even talk
13:40 karolherbst: ohh right...
13:40 f_: so probably a matter of time until some ban is implemented or something
13:41 f_: gfxstrand[d]: At least I'd prefer this kind of spam over the CSAM stuff that's been going on Matrix
13:42 gfxstrand[d]: Oh, for sure. He's harmless, just a little annoying.
13:42 f_: People report getting repeatedly invited to CSAM/cat torture rooms from people with awful matrix IDs and awful profile pictures
13:43 f_: <dwfreed> I can usually spot him if i'm babysitting the channel <dwfreed> I will say I can spot him before he speaks
13:45 asdqueerfromeu[d]: f_: The Qt Matrix client room in particular has been targeted a few times
13:46 f_: asdqueerfromeu[d]: #fdroid was also targeted
13:46 f_: I was really happy the bridge bot they used to bridge to Matrix didn't handle images properly
13:46 f_: so all I saw was thousands of "image.png" messages
13:48 f_: Anyway I promised a dmesg log a few days ago
13:50 notfunderscore: https://bouncy.vitali64.duckdns.org/uploads/funderscore/8e1c3d8f-nouveaudmesg-fail-may2025.log
13:51 notfunderscore: from old bouncer because I didn't setup file upload on my new one yet
13:53 f_: if that helps..
13:55 f_: Visible symptoms were that when switching from wayland to a tty the laptop's screen froze and the external one connected via DP completely died, then switching back to wayland made the internal one functional, except the cursor was gone and it was extremely laggy. The external monitor only showed gibberish
13:55 f_: I think the tty does make the GPU switch modes.. so switching modes just makes matters worse
13:56 f_: sorry for the delay in uploading a dmesg, life went on the way..
14:04 gfxstrand[d]: snowycoder[d]: Okay, I've been through all the NIR lowering code and all the NIL code. I think I'm going to wait until you deal with the torrent of comments to go further. Once we're all settled there, I think the rest should go pretty quick. Really good work! 💜
14:21 misyltoad[d]: gfxstrand[d]: the other half is hdkr who i could just invite here as they are on discord :frog_gears:
14:40 karolherbst[d]: I just wished we had something good to replace IRC with 🙃
14:41 dwfreed: There is nothing good, not even IRC
14:41 dwfreed: IRC is certainly the simplest, though
14:42 ermine1716[d]: karolherbst[d]: I forgor to test revolt 💀
14:42 karolherbst: dwfreed: what are the IRCv3 plans tho?
14:42 dwfreed: half the IRCv3 plans are also garbage
14:42 karolherbst: well..
14:42 karolherbst: can only pick the good ones :D
14:43 dwfreed: exactly :>
14:43 karolherbst: more wondering if oftc has plans to adopt some of them
14:43 dwfreed: yes
14:43 karolherbst: like the notification stuff would be great :D
14:43 dwfreed: that won't happen
14:43 dwfreed: :P
14:43 karolherbst: IRC on mobiles is... uhm... well... not great :D
14:43 karolherbst: ahh
14:44 dwfreed: bouncers are great; I hear quassel is decent for mobile because of its sync mechanism
14:44 dwfreed: notifications are better implemented between end client and bouncer if anything
14:45 karolherbst: right... just... not sure every user wants to set up a bouncer
14:46 dwfreed: there are bouncer services like irccloud
14:47 karolherbst: fair enough
14:51 dwfreed: the current roadmap looks something like: 1) rebuild all the servers we operate, because some of them are still running debian *stretch* (stretch -> trixie is 4 releases, for those not familiar); 2) implement all our custom services in a standalone psuedoserver (this will include the ability to detect our "friend"); 3) switch to atheme; 4) fix anything that needs to understand irc server details; 5)
14:51 dwfreed: switch to solanum
14:52 dwfreed: that's the high level overview, there's a lot of tasks in each stage
14:57 karolherbst: I see
15:01 gfxstrand[d]: misyltoad[d]: Yeah, I've never understood why hdkr hasn't joined the Discord room. But whatever. Maybe they hate emoji?
15:01 misyltoad[d]: I think they just dont know about it
15:03 dwfreed: I find it hard to believe that they don't know about it :)
15:11 gfxstrand[d]: Oh, I'm very sure they know
15:11 gfxstrand[d]: I'm going with my emoji hate theory
15:23 f_: gfxstrand[d]: well yeah I'm really sad IRC doesn't have emoji support 🫠
15:23 f_: wait a minute it does
15:27 orowith2os[d]: f_: probably depends on client. If it's Unicode, chances are it'll work.
15:27 f_: Who uses an IRC client that doesn't even support Unicode these days
15:28 gfxstrand[d]: I don't think I have the locale in my IRSSI box set up for them at the moment.
15:28 gfxstrand[d]: But it'll work if you have a UTF8 terminal, even if it does get very confused by double-wide characters.
15:29 f_: yeah but also, sane GUI IRC clients should work just fine with emojis
15:32 gfxstrand[d]: Why use 1990s technology with a 1980s chat protocol?
15:32 gfxstrand[d]: *she says from a web browser*
15:36 asdqueerfromeu[d]: At least IRC chatrooms didn't seem to use UTF-16 (because that would be a nightmare)
15:40 f_: gfxstrand[d]: because they improve the experience :P
15:40 f_: Want to use 1980s IRC? Go to EFnet for that (don't)
15:45 karolherbst[d]: gfxstrand[d]: mhenning[d] I've done some thinking on how to solve this phi vector value issue and I'm wondering what your thoughts are on making phis inside NAK to be vector aware... a lot of the movs/par_copies I'm seeing are just RA not being smart enough to properly allocate vectors across phis and me wondering if just keeping the information (phis being vectors) up until RA might solve this
15:45 karolherbst[d]: issue in a nicer way than trying to make RA smarter
16:54 karolherbst[d]: the only real difference I'd try to do here is, that instead of allocating a single reg, those nodes would just allocate vecs and fall back to single regs on failure,,, not sure if that's a great idea, but I was considering not doing _actual_ vectors on phis, just a list of sources RA should allocate aligned
16:54 karolherbst[d]: and either it does and everybody is happy or it tries with a lower alignment until it works
17:02 mhenning[d]: Yeah, I think the two options we have there are 1) make phis take vectors so we can try to align at the PhiSrcs/PhiDsts or 2) extend the existing vector alignment heuristic to operate on information from the whole program (it currently only considers the current block)
17:04 mhenning[d]: I'm not totally sure which would be easier. Changing the semantics of phis touches a log more code, while option 2 could be a change just to the register allocator
17:04 mhenning[d]: gfxstrand[d]: pls review https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35100
17:06 karolherbst[d]: mhenning[d]: sounds like a mess and kinda unreliable, but.. maybe that's fine?
17:06 karolherbst[d]: mhenning[d]: yeah... not sure I want to touch the phi code 🙃
17:07 karolherbst[d]: I know that vector aware RA can be a massive pita
17:08 karolherbst[d]: so I was just considering instead of changing RA itself, just have a list of SSAValue groups which are then allocated together instead of alone
17:08 karolherbst[d]: or well.. tried at least
17:08 karolherbst[d]: then you can even allocate all vec4s first
17:09 karolherbst[d]: then vec3, vec2, ....
17:11 karolherbst[d]: dunno.. maybe it makes no sense, I haven't really looked at the code too much
17:21 mhenning[d]: karolherbst[d]: you can't allocate in an arbitrary order in a treescan allocator, you need to allocate all the dominators of an instruction before that instruction
17:21 karolherbst[d]: mhhh, I see
17:22 mhenning[d]: karolherbst[d]: this sounds a lot like our existing heuristic in `SSAUseMap`. The issue is just that `SSAUseMap` only considers the current block. It could be extended to include information from other blocks
17:23 karolherbst[d]: mhenning[d]: if that's simple enough, so be it, it's just that the phis itself don't have that information, so might need to check how the phi is used/written
17:35 mhenning[d]: karolherbst[d]: Yeah, we also have this PhiWebs structure that collects ssa values into phi equivalence classes
17:36 mhenning[d]: which should have the other half of the information
17:36 mhenning[d]: the vector heuristic could potentially track phi equivalence classes instead of ssavalues directly
17:43 karolherbst[d]: well the phiweb just contains ssavalues, no? How would you know about the vectors there?
17:50 mhenning[d]: you'd need to add that information
17:50 mhenning[d]: eg. SSAUseMap could have equivalence classes in it instead of ssavalues
17:56 karolherbst[d]: ahh, I see
18:18 HdkR: Wha? IRC can do the only emoji that is necessary 🎉 :P
18:20 f_: :D
18:20 snowycoder[d]: gfxstrand[d]: In your review you are trying to optimize the code for descriptor size, shouldn't we optimize for n. of instructions instead? That's what old drivers seem to do
18:25 sonicadvance1[d]: :headempty:: I guess this is good as well.
18:42 mohamexiety[d]: eyy welcome <a:vibrate:1066802555981672650>
19:44 gfxstrand[d]: snowycoder[d]: Both matter.And things like `image_size` aren't common operations.
19:45 gfxstrand[d]: Neither are 3D textures and MSAA is a loss anyway
19:45 gfxstrand[d]: For the common 2D or 2D array load/store ops, my descriptor compaction makes no difference.
19:48 snowycoder[d]: gfxstrand[d]: But we would need to handle imageSize multi-sampling explicitly, if someone expects it to be a fast lookup it might be a lot slower
19:49 gfxstrand[d]: Oh, because we have to divide by sample counts?
19:49 gfxstrand[d]: <a:shrug_anim:1096500513106841673>
19:50 gfxstrand[d]: For actual MSAA image load/store, I guarantee it's faster because it's 2 fewer dwords to fetch.
19:51 gfxstrand[d]: If it all gets promoted to cbufs, maybe that's okay
19:52 gfxstrand[d]: For `imageSize`, yeah, it's more ALU. IDK how much that's going to matter.
19:52 gfxstrand[d]: ALU and memory is weirdly balanced on nvidia
20:47 gfxstrand[d]: Testing on SM30
20:54 gfxstrand[d]: And... nothing works.
20:54 gfxstrand[d]: I mean it writes stuff. It looks like the format is fine. But it's not writing the right stuff to the right adresses
20:55 gfxstrand[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1375215429974364210/image.png?ex=6830e0ac&is=682f8f2c&hm=5a8fa949312a0b557179c736281e1dea1cca865ee964f7f19b94bf8e36b47524&
20:57 snowycoder[d]: Mmmmh, do the hw tests work? I might have messed up imadsp encoding
20:57 gfxstrand[d]: Yeah, they do. That's the confusing part
20:58 gfxstrand[d]: `dEQP-VK.image.store.with_format.buffer.r8g8b8a8_unorm` fails. 🤯
20:58 gfxstrand[d]: It's got to be the store instruction
21:00 snowycoder[d]: There's some basic imageToBuffer and bufferToImage tests that helped me a lot, i also modified them to work with pitch_linear
21:06 snowycoder[d]: Found them: `dEQP-VK.compute.pipeline.basic.copy_image_to_ssbo_large`.
21:06 snowycoder[d]: To test stores you might need `copy_ssbo_to_image_{small,large}`
21:14 gfxstrand[d]: Looks like imadsp is wrong after all
21:14 gfxstrand[d]: Let me fuzz it quick
21:15 snowycoder[d]: So the hardware test is wrong?
21:15 gfxstrand[d]: Or the hardware test doesn't fuzz hard enough
21:15 snowycoder[d]: It should fuzz every modifier
21:22 gfxstrand[d]: Okay, I got distracted by the nvdisasm bug
21:25 gfxstrand[d]: I wonder if there's an argument order that's different or something
21:28 snowycoder[d]: I couldn't test on KeplerA, in KeplerB I'm sure there's the bug (the hw tests confirm it)
21:29 gfxstrand[d]: Well, if I "fix" kepler A, the hardware test fails so I think it has the same bug.
22:15 mhenning[d]: gfxstrand[d]: do you have opinions on what the semantics of OpUndef should be in NAK?
22:15 mhenning[d]: spirv defines that "Each consumption of Result <id> yields an arbitrary, possibly different bit pattern or abstract value resulting in possibly different concrete, abstract, or opaque values."
22:15 mhenning[d]: but I've been talking to alyssa about it and it sounds like "every use gets the same arbitrary value" might be closer to the way that nir's optimizations treat it right now
22:58 karolherbst[d]: that's just the normal definition of undefined value
22:58 karolherbst[d]: it just means that each read of the value might give you a different value
22:58 karolherbst[d]: which means you can do whatever (tm)
22:59 karolherbst[d]: that also means that adding the undef value to itself doesn't have to yield an even number
23:01 karolherbst[d]: tldr: do whatever you want
23:12 mhenning[d]: it's not that simple. eg. alyssa pointed me to https://web.ist.utl.pt/nuno.lopes/pubs/undef-pldi17.pdf section 3.1
23:26 karolherbst[d]: mhenning[d]: that's not true anymore
23:27 karolherbst[d]: in llvm undef means even the result is undef and doesn't contain any of the inherent properties of the operation
23:27 karolherbst[d]: if you want them, you need to freeze the value first
23:27 karolherbst[d]: only if you freeze an undef value, `add x x` will be even
23:27 karolherbst[d]: if you don't freeze it, the result can be anything
23:28 karolherbst[d]: https://llvm.org/docs/LangRef.html#freeze-instruction
23:29 mhenning[d]: right, but nir doesn't have freeze and is happy to convert `x * 2` to `x + x`
23:29 karolherbst[d]: even the mul x 2 can be any result
23:29 karolherbst[d]: oh sure
23:29 karolherbst[d]: it's entirely valid to have always an even number as the result
23:30 karolherbst[d]: undef just means you get no promises
23:30 mhenning[d]: so either nir's opts are wrong or every undef gets the same value
23:30 karolherbst[d]: and the compiler can do whatever
23:30 karolherbst[d]: nir isn't wrong
23:31 karolherbst[d]: undef just means "whatever" and that's literally it
23:31 karolherbst[d]: if nir replaces undef with 0, and just optimizes according to that, that's entirely valid behavior
23:32 mhenning[d]: by the spirv spec, undef * 2 is even , since there's only a single use of the undef
23:32 karolherbst[d]: the poison/freeze semantics llvm added just allows them to propagate the undef through the operations and be more aggressive with optmizations
23:32 mhenning[d]: nir is happy to turn this into undef + undef
23:32 karolherbst[d]: mhenning[d]: mhhhhh, does the spirv spec promise that every undef is frozen?
23:33 mhenning[d]: every use of the undef has only one value by "Each consumption of Result <id> yields an arbitrary, possibly different bit pattern or abstract value resulting in possibly different concrete, abstract, or opaque values."
23:33 karolherbst[d]: huh?
23:33 mhenning[d]: that means any transformation that duplicates uses of an undef is illegal
23:34 karolherbst[d]: that measn that each consumption can yield a different value
23:34 mhenning[d]: right, but we can't turn one consumption into two
23:34 mhenning[d]: because that changes semantics
23:35 karolherbst[d]: I think that depends if using an undef value in an operation keeps its inherent properties or not
23:35 karolherbst[d]: with undef in its sources, you can just state "the result is always undef"
23:36 karolherbst[d]: and nothing else matters anymore
23:37 karolherbst[d]: _might_ want the working group to clarify that
23:38 mhenning[d]: I think the spec is pretty clear
23:39 mhenning[d]: anyway, I think I'm going to advocate for us to turn on nir_lower_undef_to_zero for now and not worry too much about it
23:39 karolherbst[d]: I mean, I agree that your reading is probably the correct one according to the spec as it is now, I'm mostly wondering if that was the intentional interpretation of the working groups intention
23:41 karolherbst[d]: but yeah.. I think having proper undef propagation in nir could help a bit here, but...
23:41 karolherbst[d]: I think that's going to be difficult to do properly
23:47 Ray_111: Hello
23:59 gfxstrand[d]: mhenning[d]: I wouldn't make that assumption. The SPIR-V spec committee has been debating the semantics of undef for half a decade or more.