00:19 Lyude: HdkR: and yeah, I sure hope so :S. I am getting really tired of having constant anxiety around people trying to force this stuff in.
00:26 Lyude: has definitely made it a lot harder to stick around
00:38 FireBurn: What stuff?
00:39 dwfreed: LLM authored PRs
00:40 FireBurn: Well I guess I'm guilty of that
00:42 FireBurn: I've used it too figure out IBM's KDBs and integrate support into Keystore manager, I've fixed an issue we've had with GCP Kafka connect doing weird things with blank messages, it's traced down an issue I've been seeing in kwin when doing this Vino work, and another fxing non overlapping displays which keeps happening too
00:43 FireBurn: These are things I probablt could do myself with enough time
00:44 FireBurn: Actually no, the KDB one I don't think I could have figured that out entirely on my own, I tried once before and failed, mosly becuase it stopped being a java thing
00:45 FireBurn: I absolutely understand that you don't want crap being flung at you though
00:45 HdkR: Lyude: You'll be happy to see FEX's contributing file. https://github.com/FEX-Emu/FEX/blob/main/CONTRIBUTING.md
00:46 FireBurn: I'm sure people will ingore that and submit anyway and just try and hide it
00:46 FireBurn: Or not bother at all
00:47 HdkR: Of course
00:48 HdkR: There's definitely a PR open right now that its contents regurgitate a trivial issue's comment and the LLM markers have been removed.
00:50 FireBurn: evdi+DLM work so badly on linux compared to Windows & MacOS, I decided to do something about it, I've been doing this for around 2 months now
00:50 FireBurn: Actually it might be closer to 3
00:51 FireBurn: I've hit a wall though, and I've been going round in circles trying to figure out what I'm missing
00:52 FireBurn: I've tried copying everything the linux version appears to do, then tried more aligning it to the windows version
00:52 FireBurn: Evertime I find a difference and close that gap I think - wil that fix it? And it dosn't :(
00:52 karolherbst: The good thing about setting up those rules is, that if you know that people are willingly ignoring those, they'll probably also ignore other boundaries... in which case you probably want to get rid of such people before they cause issues within your community
00:53 FireBurn: Oh totes
00:53 HdkR: Indeedily
00:53 FireBurn: If I get this working and its not wanted up stream, that's fine, I've scratched my itch and I'll be happy with what I've learned
00:54 FireBurn: And hopefully have a much better dock experience at the end of it
00:55 karolherbst: in the end getting a better understanding helps designing a better end result. The generated code I've seen so far is usually very verbose unless you really understand what you are doing there
00:56 Lyude: i think if yoy can use something like claude, which isnt a tool that can just teach a person entirely how to reverse engineer something as complex as displaylink, you ahouldn't undereztimate your abilities :).
00:57 FireBurn: Never underestimate ADHD and impatience
00:58 karolherbst: Linus kinda likes to bring up the analogy with assembly and compilers, and if you really want to understand what your compiler is doing, you have to learn assembly. And it's kinda the same with code and LLMs. Usually we in upstream do care about the code, so we also have to understand the code and there is no getting around that with an LLM,
00:58 karolherbst: because an LLM won't teach you
00:58 Lyude: as a severe adhd have i agree btw.
00:59 karolherbst: pro tip: make it your hyper-fixation
00:59 Lyude: Thw distraction swo4d goes both ways
01:00 FireBurn: I've worked with batch jobs written in assembly before for mainframe, I'd be curious to know how well an LLM could turn those into something human readable, espaclly as most of the folk who've written them have passed
01:00 FireBurn: karolherbst: Oh I think I'm way past that point :D
01:01 FireBurn: It's why I work in it, you know when I tried to get more captures under windows, I realised my windows patition hadn't been booted into for 2 years
01:03 FireBurn: I build my own kernels, ran Gentoo linux on my originoal crystal xbox, I think i even played with the origional nouview on there before it became a galium driver
01:05 FireBurn: But I guess there's a fine line between asking for help and being a nucence. My goal was to use rust, to reuse the stuff that had already been written as much as possible and extend where it hadn't been
01:06 FireBurn: I perhaps wrongly thought that if I extend things, the people I'm helping might be able to help with what I'm stuck on
01:17 karolherbst: Not sure it's anybody's fault. We all have different priorities in our morals, and some simply have a very strong stance on some of it. And we all make different unethical choices in our lives just to get by
01:17 Lyude: FWIW: most of my feelings come from the fact the experience of a lot of us w/r/t LLMs has been very forceful from a lot of fronts (employers withholding bonuses, promotions, eve threatening to lay people off for not complying with using these tools), along with the industry's general behavior of. it isn't just a single contributor.
01:18 FireBurn: My work has been crazy worrying about Mythos
01:19 FireBurn: I'm like hey lets fix that 9.8CVE we've known about for 6 years first
01:21 Lyude: Security isn't the worst place for an LLM. it IS shockingly good at noticing breakages in patterns in code, though, i still certainly get the feeling mythos has the overblown affext somewhat.
01:22 FireBurn: Like I said, if they're not fixing the current CVE's what that point of caring about the ones that it's not discivered yet
01:23 Lyude: But there is the rral perspective of the fact the LLM makes low hanging fruit hang lower
01:23 FireBurn: I bet we'll get an example before the end of the year where too agressive patching had exhasperated a supply chain attack
01:24 Lyude: ooo yeah, honestly that would check out
01:24 FireBurn: Wasn't both npm & Arch attacked in that way recently
01:26 HdkR: I'm looking forward to the day an LLM can find the novel transformation of x86 instructions to ARM that FEX has. Then I'll know that I can go out to pasture.
01:26 FireBurn: And a maintainer with burnout for XZ
01:27 FireBurn: I bet in 2 years it will be
01:27 FireBurn: Well assuming skynet hasn't happened :P
01:27 HdkR: So far the couple that allowed me in without an account I had some laughable results. "Just use the x86 instruction in ARM, it's easy."
01:27 FireBurn: Oh the free offerings generally aren't as good as the paid for
01:28 HdkR: But of course I'm not going to pay for that garbage.
01:28 FireBurn: Try google ai studio to try gemini pro and see the differnce compared to flash
01:28 HdkR: mmmmmmmmmmmmm
01:28 FireBurn: Opus you only get if you're paying
01:29 FireBurn: And it's much better compared to Sonnet
01:29 FireBurn: Fable I saw, but would instantly downgrade to Opus when dealing with Vino
01:29 HdkR: Oh hey, I have some Sonnet stuff.
01:29 HdkR: It's in my server rack holding my Mac Minis in it.
01:30 HdkR: :>
01:30 FireBurn: That made me chuckle
01:31 FireBurn: Oh god it's 2.30am and I'm working in the morning, nice chatting folks, and if you ever had the curse of a DisplayLink dock, wish me luck
06:10 CounterPillow: I wish gregkh would stop auto-backporting amdgpu slop to stable kernels so I can watch my youtube videos in peace without null pointer dereferences in amdgpu
11:55 DragoonAethis: CounterPillow: amdgpu didn't need slop to segfault on YouTube :>
12:09 FireBurn: I'm using Chromium on Wayland and VAAPI and I've never had a null pointer deref watching a video on youtube
13:04 pq: If a driver does not yet implement any plane color pipeline, userspace setting the client cap will remove the old plane color properties and give nothing in return. Is this expected?
13:28 karolherbst: what hardware/drivers do we have that does not support fp32 denorms?
13:32 danylo: karolherbst Which part of fp32 denorms? E.g. in Turnip we emulate shaderDenormPreserveFloat32
13:33 karolherbst: CL does not require fp32 denorm support, nor does it require flushing for devices that claim not to support it, so no emulation would be required unless the driver wants to anyway
13:34 karolherbst: so I'm mostly interested in hardware that can't run arbitrary compute shaders with denorms preserved
13:36 pinchartl: pq: I can't answer that question, but I'm planning to add support for the color pipeline properties to the R-Car DU driver. what do you recommend using in userspace to test it ?
13:41 emersion: pq, you mean the cap is advertised regardless of driver support? that sounds like a bug
13:41 pq: pinchartl, I would like to say that IGT exercises it all, but I haven't looked at IGT. Weston has some support in upstream main branch, leandrohrb should be able to tell more how to use it.
13:42 pinchartl: pq: thank you
13:42 pq: emersion, rmader did some investigation and it seems so.
13:53 MTCoster: I have a linux process question - can anyone tell me what tree MAINTAINERS changes are supposed to go through? Is it just the relevant tree for the entry, or is there a central one?
14:03 javierm: MTCoster: usually just the relevant tree for the entry
14:03 glehmann: karolherbst: fp32 denorms are slow on amd for various reasons
14:04 karolherbst: glehmann: does AMD have per instruction flags for it? And are those instruction then just slower?
14:05 karolherbst: but yeah.. that's kinda tricky, because it doesn't fit the CL model very well
14:05 MTCoster: javierm: Thank you! That was my assumption but just wanted to be sure :)
14:08 glehmann: karolherbst: it's a per wave register, and on some early hardware it's slows down everything to fp64 rate, it disallows v_mad_f32 for hw that has it, and it disallows the free 0.5/2.0/5.0 output multiplication
14:09 karolherbst: mhhhh
14:10 karolherbst: kinda wondering what rocm-opencl is doing there...
14:19 glehmann: not sure, but they also only support hw where denorms and v_fma_f32 are full rate, so if they always enable denorms is a much smaller issue
15:06 karolherbst: ahh I see
16:33 alyssa: karolherbst: apple doesn't do fp32 denorms
16:33 alyssa: iirc
16:53 glehmann: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/15052 maybe we need a better way to deal with confidential bug reports than hoping that the correct person sees them by chance
16:57 karolherbst: could maybe make a bot that pings release managers every now and then if there is no activity and the issue wasn't closed?
17:01 glehmann: we have https://gitlab.freedesktop.org/mesa/mesa/-/work_items/2384 with 6 years without a reply
17:01 glehmann: but I guess that is only softpipe, so not really important
17:13 karolherbst: yeah... not really sure otherwise. I don't really want to make release managers responsible in any way, but I also don't know who else would be a better fit to deal with it. But I do think we might want to have a bot that just pings on confidential issues if there is no activity... could also just leave a comment and hope somebody sees it, but then
17:13 karolherbst: it might just get ignored if there are no labels..
17:14 karolherbst: but maybe could have it be two things: a bot that complains a confidential issue hasn't been triaged yet (and we might need more labels in case the issue is very potential and nobody knows if it's real or not) and then another that just pings if there is no activity?
17:14 karolherbst: and for the first we could have a group of people who want to triage those
19:05 alyssa: glehmann: would you nak the full set of *csel_[cmp] opcodes being added?
19:05 alyssa: right now we have fcsel_gt but not fcsel_lt etc
19:06 alyssa: (you can't just commute operands because of NaNs)
19:08 glehmann: we probably have worse opcodes at this point
19:09 glehmann: but can you make sure that you pay attention to denorms? iirc many of these fpsel opcodes in NIR are defined to flush denorms, but I'm not sure if that matches everyone's hw
19:10 alyssa: that's a good question
19:13 alyssa: glehmann: ...good grief
19:13 alyssa: the Intel instruction flushes output denorms only if you use an abs/neg/sat modifier
19:14 alyssa: so we want the NIR instruction to not flush, i.e. be exactly equivalent to bcsel + flt
19:14 alyssa: and then the backend gets to pick up the pieces
19:15 alyssa: although this is considerably more screwed than I thought now
19:15 karolherbst: mhhh.... we don't have that one in one instruction, but two
19:16 glehmann: alyssa: wait so if one source is negated, it also flushes denorms when the other one is selected?
19:17 karolherbst: but our FSEL instruction seems to flush the result
19:18 alyssa: glehmann: Unclear
19:25 Kayden: intel csel flushes the comparator's denorms before comparing against zero. denorms are retained unless you have a modifier on the selected source
19:26 Kayden: if the selected source has abs/negate then you get FTZ
19:26 glehmann: ah so it's at least somewhat sane
19:27 Kayden: if you have saturation set then negative denorms are clamped to zero, but positive denorms are retained
19:28 Kayden: that doesn't seem too crazy, though if you need a float compare against zero that preserves denorms you can't use it
19:28 Kayden: er
19:29 alyssa: Kayden: the abs/neg behaviour seems fine, the saturation behaviour seems wrong
19:29 Kayden: howso?
19:29 alyssa: like i agree that's what the bspec says i'm just saying that's not what we want
19:30 Kayden: sure
19:30 alyssa: fsat(bcsel(..)) is supposed to flush to zero
19:30 Kayden: oh, fsat is supposed to flush positive denorms too?
19:30 alyssa: I'd assume so
19:30 alyssa: I mean it's a floating point op
19:30 alyssa: MOV.f32.sat presumably flushes
19:31 karolherbst: when do you only want to flush negative, but not positive denorms?
19:31 karolherbst: ohh wait.. fast
19:31 karolherbst: *fsat
19:32 karolherbst: can you really call this denorm flushing though? Sounds like that's just how fsat operates
19:32 Kayden: Yeah, it's not denorm flushing. It's just claming values outside of the range [0.0, 1.0]
19:33 Kayden: the saturate bit on our instructions seems to work the same way, things outside of [0.0, 1.0] get clamped to the closest value, so negative denorms would turn into 0.0. positive denorms would stay. but then any denorm flushing behavior of the underlying instruction would happen too
19:33 karolherbst: right
19:33 karolherbst: that reminds me.. we also have FMUL.SAT
19:35 alyssa: Kayden: ..does that mean our fsat is broken in intel/compiler?
19:35 glehmann: Kayden: sounds like your backend will have to be very careful when applying fsat then
19:35 alyssa: because MOV.f32 doesn't flush
19:37 alyssa: glehmann: nir_op_fsat flushes yes?
19:37 glehmann: yes
19:37 glehmann: would be a pain otherwise
19:37 alyssa: ok. yes. fsat is totally broken on intel mesa then I think, all compilers :/
19:37 alyssa: `ADD.f32.sat x, -0` is a valid fsat, `MOV.f32.sat x` isn't
19:38 alyssa: I guess there's a CTS coverage gap here
19:40 Kayden: lovely. I haven't tested, I'm just reading the docs
19:40 Kayden: we could write small executor tests to actually try out various things and see how it works
19:41 alyssa: Yeah. should I put that on the list or are you feeling sniped?
19:42 glehmann: you don't even needs the -0, +0.0 would work too because it's fsat.
19:42 glehmann: but maybe that doesn't matter for you and I'm too amd brained where 0 is cheaper
19:42 alyssa: uh yeah that doesn't matter :p
19:44 Kayden: alyssa: I think you're right, but no, not feeling sniped
19:46 alyssa: on the list it goes
23:04 karolherbst: would anybody complain if I'd rename fcsel to f32csel, so I can add a fcsel that takes a bool as the condition (src0?
23:16 mareko: that's bcsel, "boolean-condition select"
23:18 karolherbst: it's not
23:19 karolherbst: we have a FSEL instruction that also flushes denorms
23:19 karolherbst: and also can take abs/neg float source modifiers
23:25 karolherbst: but could probably call it something else, or make it a backend op and do more optimizations there