07:34 MrCooper: FWIW, I found https://diegoe.be/2026/09/25/llm-policies-progress-at-all-costs/ quite an interesting take related to what (not) to use LLMs for in FLOSS projects
07:34 MrCooper: ("collectivism" better describes what I'm here for)
08:33 ccr: MrCooper, interesting point of view indeed.
08:36 ccr: I have personally observed a curious contradiction in some of "AI advocates". like me personally, they might perceive themselves less on the "utilitarian" side of things and seem to enjoy the "craft", but neverthless present this urge to "do more" as enabled by "AI". or do things that they were unable to do without it.
08:36 ccr: though perhaps "contradiction" is not the correct word to describe it
08:39 ccr: I can understand the urge to do "more" in principle. but I feel that for me, the doing would lose most of the meaning if I was just prompting and reviewing what a LLM does.
08:53 MrCooper: same here
08:56 airlied: I don't think a FLOSS project needs to be taking a hardline against having both types of people participating, we haven't in the past
08:57 MrCooper: I'm not advocating for any hard line
08:58 MrCooper: regarding gains from using LLMs, I found https://www.normaltech.ai/p/why-ai-hasnt-replaced-software-engineers insightful
08:58 airlied: I rarely see anyone who uses AI tooling tring to convince anyone they need to be using AI tooling
08:58 airlied: like if we are convinced it's not useful, and people still find it useful for them, then we just leave them alone
08:58 MrCooper: a similar argument applies in reverse
08:59 MrCooper: guess we need to find some kind of middle ground
09:58 CounterPillow: airlied: weird, I see that all the time, as basically their main personality trait.
10:26 llyyr: yeah, I can count on my fingers the amount of people who use AI extensively but aren't in some kind of AI psychosis
10:36 CounterPillow: "you are going to be left behind" and "[xyz] is cooked" is such a common moniker used by vibechuds that I am astonished someone can seriously say "I rarely see anyone who uses AI tooling [trying] to convince anyone they need to be using AI tooling" without either 1. lying, 2. being severely out of touch with the scale of the psychological warfare being waged against this profession.
10:36 CounterPillow: It's the new normal for raving bands of techbros to be calling you a horse for your refusal to review their +2000 lines of ill-justified code.
10:54 pq: CounterPillow, mind the wording, that sounds like an insult, and it applies to me too as far as I recall reading things.
10:55 pq: maybe I don't read those forums, maybe my mind automatically filters such comments out
12:15 alyssa: So I hate to interrupt the flamewar with topical questions, but--
12:16 alyssa: adrianb and calder found a shader in Horizon Dawn Remastered that - by my readings of both SM5 and Vulkan specs - hits undefined behaviour
12:16 alyssa: leading to hangs on Jay
12:16 alyssa: what I don't understand is how the game works on /any/ drivers, particularly for AMD
12:16 zmike: sometimes the undefined behavior hits just right
12:17 alyssa: There's a fragment shader that does something like `while (atomicCompExchange(...) != 1234));` spin-lock kind of thing
12:18 alyssa: But atomics return undefined values in helper invocations, so depending on which undefined values are picked by the driver -- on Intel, that means which registers RA picks and what garbage happened to be leftover in them -- that may hang helper pixels
12:19 alyssa: So all the lit pixels become inactive and all the helper pixels just loop infinitely doing `while (5678 != 1234) {}` and the result is a GPU hang / timeout.
12:19 alyssa: Are other drivers secretly giving defined behaviour for cases like these? Is there an app workaround we're missing?
12:19 alyssa: Commit logs suggest the game /does/ work on all the Mesa drivers, so..
12:20 alyssa: pendingchaos: fixed this game in aco in 2022 but nothing to do with atomics in helpers
12:21 alyssa: and gfxstrand fixed it in nvk, although maybe nvidia gives defined behaviour in hardware here somehow, idk.
12:21 alyssa: and hakzsam_ fixed the game in the spir-v frontend in 2020, but also nothing related to helpers
12:22 pendingchaos: with aco, that undefined value should happen to be the data source
12:22 alyssa: which is exactly what the shader expects here
12:22 pendingchaos: not really an intentional decision, but the data source has to be the same register as the destination
12:23 alyssa: OK. So all the AMD drivers are doing that, at least.
12:23 alyssa: Maybe Nvidia drivers give that guarantee in hardware too?
12:23 alyssa: would explain how the bug slipped past the game devs..
12:23 alyssa: Jay could provide those semantics but it doesn't currently
12:25 CounterPillow: at that point maybe it's time to update the spec to make it defined behaviour :D
12:26 pendingchaos: if the uniform atomic optimization is done, I don't think it would necessarily return the data value
12:27 karolherbst: alyssa: atomics are for sure defined behavior in helper invocs on nvk. There is a hw flag to enable loads in helper invocs and we turn that on. I suspect this also changes the behavior for atomics
12:28 alyssa: karolherbst: Loads are well-defined everywhere. Atomics are not.
12:28 karolherbst: yeah, but I don't see why atomics wouldn't behave well defined on nvidia there
12:28 karolherbst: if that flag is toggled
12:28 karolherbst: I could check, but I'm sure they just do the load properly
12:28 alyssa: On Jay we manually predicate atomics
12:29 karolherbst: what sort of predicate?
12:29 alyssa: But I think we could tie the source & destination registers and get AMD-equivalent behaviour
12:29 alyssa: karolherbst: !gl_IsHelperInvocation
12:29 karolherbst: ahh..
12:29 karolherbst: we don't have to do that on nv hw
12:29alyssa:has nv envy
12:30 karolherbst: atoms won't write in helper invocs, but they read
12:30 karolherbst: I just checked
12:33 alyssa: Oookay
12:33 alyssa: that's different than AMD behaviour and would be a lot more expensive to emulate on Intel
12:34 alyssa: although for this shader I think either way works out.
12:34 karolherbst: maybe I should check with the specific shader, do you have something trivial to reproduce? Just want to double check in case I misinterpret something there
12:38 alyssa: I don't have one, I can ask adrian when he's in the office (timezones)
12:38 karolherbst: alyssa: what do you mean by gfxstrand fixing it in nvk btw?
12:38 alyssa: some other bug in the game
12:39 alyssa: i just grepped for commit messages
12:39 karolherbst: I failed to grep :'(
12:40 karolherbst: ohh found it
12:40 karolherbst: yeah.. that's unrelated
12:41 DragoonAethis: alyssa: I remember Horizon Forbidden West hanging the GPU every few hours on a RX 6800 too, same engine etc, so you might want to bonk that for more funny shaders too
12:44 alyssa: DragoonAethis: lovely.
12:46 karolherbst: guess to do a load in the gl_IsHelperInvocation case might be a trivial enough game workaround then?
12:52 glehmann: the amd solution seems a lot saner to me
12:52 karolherbst: mhh I guess if you want to add an RA constraint..
12:53 alyssa: glehmann: for sure
12:54 alyssa: I'm guessing that's how this works on Intel Windows, not that I've looked
13:01 daniels: CounterPillow: no-one in here is saying that people are going to be left behind and/or are cooked though, are they? if they did, they'd get rightly slapped down for it. it's not fair to blame people for all the stupid shit that anyone says on the internet. there are quite a lot of 'vibechuds' who have either been in the middle of this discussion or lurking, and none of them have been denigrating anyone who thinks LLMs should be banned.
13:06 alyssa: :q!
13:07 dwfreed: Password:
13:07 zmike: hunter2
13:07 dwfreed: Incorrect password; you're stuck in vim for the next 24 hours
13:08 zmike: ffffffffffuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu
13:24 dcbaker: Could be worse. You could be stuck in nano 🤷
13:26 zmike: wow I feel attacked
13:55 airlied: MrCooper: like I get someone in other areas pushing you to use LLM tools, but is this happening in mesa?
13:58 MrCooper: what I meant is that using LLMs for everything would also exclude some people, just like banning them for everything would (and there's a spectrum between those extremes)
13:58 airlied: where as anyone pushed to use LLMs for everything in the mesa project
13:59 MrCooper: not sure where you got that straw man from, as I said that's just one extreme of a spectrum
13:59 airlied: I want to have discussions about the mesa project
13:59 karolherbst: I'd suggest to speak from personal experiences here on that topic to not run into those kind of communication issues
13:59 airlied: I keep getting examples from unrelated places
14:00 MrCooper: per the mutter MR I linked, I'm against LLM-generated commit logs
14:00 airlied: like yes if I go by my mastodon feed, I'm going to burn in hell if open claude, if I go by twitter, I'll be replaced by claude if I don't open claude
14:01 airlied: and mutter should make a policy around that in that project
14:01 MrCooper: glad I'm not using either of those then :)
14:01 MrCooper: that's kind of the point I'm trying to make on that MR
14:02 airlied: like obvious slop is fairly obvious and minimal pushback should shut it down
14:02 karolherbst: Like if commit messages and other text is a problem, we should certainly point it out on MR reviews. Like yeah, some are kinda worse than they should be, but I haven't seen anything horribly wrong that got merged yet, but I also don't look as much there except for the things I review
14:02 airlied: is it frustrating we have to push back, yes
14:02 airlied: but if someone write an AGENTS.md guide that produces perfect Mesa commit logs everytime, well do we still refuse them
14:03 MrCooper: I'm against it on principle, regardless of the quality of the output
14:03 airlied: no exceptions for non-english speakers?
14:04 MrCooper: yes, translation from a different language is an exception
14:04 airlied: like it's a nice principle to have, but there are plenty of places where AI might improve the quality of commit messages if done properly
14:04 airlied: it's just by default with no effort applied it makes slop
14:05 karolherbst: I mean we have to accept that there are many reasons to be against it that are unrelated to quality of the output itself
14:05 airlied: and those reasons are personal and it's fine to hold a moral principle, but your freedom ends where someone elses begins
14:06 karolherbst: well.. the tools in itself restrict the freedom of others, so we should stop using them?
14:06 karolherbst: and I mean this by knowingly causing health issues in certain neighborhoods due to AI DCs. Those moral arguments are never that simple
14:06 airlied: karolherbst: you do udnerstand this applies to phones and computers
14:06 airlied: lithium mining
14:06 MrCooper: airlied: if you wonder why people might feel pressure to use LLMs, just read the the last few lines of scrollback ;)
14:07 airlied: like I don't care if you use it, I care if you want to stop others from using it
14:07 karolherbst: airlied: yeah, just saying your argument doesn't mean much as it works both ways
14:07 airlied: it literally doesn't work the other way
14:07 karolherbst: it literally does
14:07 airlied: because I'm not telling you what to do
14:07 karolherbst: that's a different point
14:07 airlied: you are telling me what don't want me to do
14:08 karolherbst: those things are always intertwined
14:09 airlied: this feels like people who confused having boundaries and enforcing them on others
14:09 karolherbst: so if I didn't want you to insult others, that's enforcing boundaries onto others?
14:09 airlied: as anyone insulted anyone?
14:10 airlied: where did that even come from?
14:10 karolherbst: that's an example of telling something not to do something because we morally accepted as the right thing
14:10 karolherbst: we can also morally accept using AI as the same thing
14:10 karolherbst: like.. that it would be morally justified to not use it
14:10 airlied: morals are personal
14:10 karolherbst: sure
14:10 airlied: stop trying to make them general
14:10 karolherbst: and we have norms in the context of society and community
14:11 karolherbst: and as a community we could have the norm of not using AI
14:11 airlied: but the community has rejected that stance already
14:11 karolherbst: sure
14:11 karolherbst: but that's a different argument than yours
14:11 airlied: the members of the community are on a spectrum of moral and practical stances
14:11 karolherbst: you argued that it's somehow wrong to impose restriction on others, where I say it's a norm of the community we could just have
14:12 airlied: but it's not a norm
14:12 airlied: and you can't make it a norm
14:12 karolherbst: that wasn't my point
14:12 airlied: whereas insuting people is more likely a norm
14:12 karolherbst: not in every community
14:12 airlied: so you can enforce not insulting ppl
14:13 airlied: hence why norms emerge from the community, and can be enfored, but you are trying to make a norm where none exists
14:13 airlied: at which point, you get to decide how much you interact with AI production, AI produced works, etc and we try to figure out if any norms exist that are acceptable to the current community
14:13 karolherbst: norms can change, and if you want something changed, you have to engage in conversation
14:13 airlied: and if they emerege we can enforce them later
14:13 karolherbst: none of this is a static
14:14 airlied: yes but nobody seems persuaded to chance stance at this point
14:14 karolherbst: that has many reasons
14:14 karolherbst: and not all of them point towards a healthy community sadly
14:14 airlied: that is where I feel you are reaching a bit
14:14 zmike: TIL having an opinion is a sign of an unhealthy community
14:15 airlied: sadly implies some sort of disapointment
14:15 airlied: that there isn't a norm I can enforce
14:15 karolherbst: I haven't said all of them do. Some do
14:15 MrCooper: airlied: I'm saying I'd prefer if the projects I'm involved in didn't allow LLM-generated commit logs, that's all
14:15 karolherbst: there are people that are intimidated enough to not engage to voice their anti AI position
14:15 karolherbst: is that a sign of a healthy community?
14:16 airlied: karolherbst: I got banned from mastodon for voicing a proAI position
14:16 karolherbst: I'm not talking about mastodon
14:16 karolherbst: I'm talking about our community here
14:16 airlied: so we are going with the silent majority?
14:16 karolherbst: who knows?
14:17 airlied: why do we base our decisisons on people who won't voice their opinins
14:17 airlied: like I know people who won't due to employer pressure
14:17 karolherbst: I couldn't tell what the majority even is, but going by simple majority is also not the right way of approaching this topic
14:17 airlied: or other externalities
14:17 karolherbst: "> why do we base our decisisons on people who won't voice their opinins" is a very anti-democratic stance btw
14:17 karolherbst: there are structural reasons why some can't or won't
14:18 airlied: but we aren't voting on anything here, mesa isn't democratic
14:18 airlied: it's a ommunity
14:18 karolherbst: right and my expectations of a community is to figure out what everybody thinks
14:18 airlied: and there is no need for any group to enforce thier will on others
14:18 airlied: and so far I'm not seeing much sign of that
14:18 karolherbst: but if some/a lot/a few don't feel safe to voice their opinions, that points towards a problem we have to solve first
14:18 daniels: looking at #dri-devel, I really don't see people feeling inhibited from expressing an anti-AI position
14:18 airlied: yes or in the MRs
14:18 karolherbst: well.. some do, some don't
14:19 airlied: the number of review an anti-AI MR gets before anyone else sees it is quite a lot
14:19 karolherbst: group dynamics are weird...
14:19 daniels: but I do see people who aren't actively anti-AI getting told that they're immoral, destroying project consensus, etc, for having a view which others thing is wrong
14:21 airlied: daniels: ^
14:22 daniels: so if you want to have a proper discussion free of chilling effects, then that's fine, but ... this is not that. if you want to just somehow dictate that only one view/outcome is acceptable across the community, then do that, but don't pretend it's some kind of balanced discussion to generate community consensus.
14:23 karolherbst: I get it that it sucks getting told that certain believes are causing issues elsewhere
14:24 airlied: karolherbst: no it doesn't, but I bet it feels good to point it out
14:25 karolherbst: okay, so now concretely, which part are you having an issue with?
14:26 airlied: I'm having an issue with the quality of conversation and critical thinking around this whole topic
14:26 karolherbst: that's all subjective
14:26 daniels: like airlied says, being chained to smartphones and smart devices isn't exactly free of human misery either. working to enable people to have their 2kW rigs at home isn't exactly a great victory for climate justice. if you want to go full FSF on it, working to enable various bits of proprietary software isn't quite a moral success story. but here we all are, tainted in some way, because there is no ethical consumption under capitalism.
14:27 daniels: (even before you get in to how the entire OSS OS+GPU+camera+codec+media stack has enabled drone warfare)
14:27 karolherbst: I don't really want to go into the "no ethical consumption under capitalism" topic here, but your understanding of it is out of context and not what was meant by that
14:27 karolherbst: but I do understand your sentiment here
14:28 karolherbst: and nobody disagrees that certain actions have certain consequences, but that doesn't mean that because we are doing something wrong, that it excuses doing another new thing that is also wrong
14:29 daniels: the point is that morals are subjective and not universal absolutes, and that you could point at anyone here and tell them that their morals are in the bin because they're an enabler of human misery
14:29 karolherbst: so I think we shouldn't use that in such a way. Like sure, everything sucks, that doesn't mean we have to make everything suck even more
14:30 karolherbst: oh sure, but that also feels like downplaying the harm caused by AI specifically, because it's not just that
14:30 airlied: does the mesa project not using AI make a major dent in the misery, or is it just feel good for us?
14:30 karolherbst: does it matter if we still want to take that stance?
14:30 airlied: it matters if we know we don't
14:30 karolherbst: like that's not an argument not doing that
14:31 airlied: like even if there was one mesa developer pro-AI we'd probably be bad in taking it
14:31 airlied: but the thing is there definitely more than 1
14:31 daniels: karolherbst: it's not downplaying the misery, because the misery is fucking miserable. but several years of working for a company which is a key supplier for the US Department of Defence sure does require having some moral blindspots, so how reasonable is it then to point to others and say 'you're destroying civilisation'?
14:31 karolherbst: yeah.. glad that I decided to leave
14:32 karolherbst: (and honestly too late)
14:33 karolherbst: but that's not a reason to not bring those things up
14:33 karolherbst: like how would we know how many people care about those things
14:33 airlied: but we keeping having the discussion like suddenly a consensus will arrive
14:33 daniels: is it the role of Mesa as a project to take a moral position on which parts of society are acceptable?
14:33 airlied: I don't mind having the conversation but I'm not seeing people being swayed by moral arguments
14:34 karolherbst: yeah... I mean I guess that's not possible with that topic, so we all just hope the middle ground is making people too upset on average
14:34 karolherbst: daniels: if we as a community want to, why not?
14:34 daniels: do we want to?
14:34 airlied: but I think we are telling you that this community doesn't want to
14:34 karolherbst: maybe?
14:35 daniels: factually, Mesa enables genocide, not just directly through being a part of bombs raining down on people, but by accelerating climate change. is that ok?
14:35 karolherbst: I would love to have more open stances on a few things as a project. Am I alone with this? Do many agree? or only a few? Who knows
14:35 airlied: on this, you know people agree and disagree
14:35 Company: the one thing Mesa doesn't compromise on is trans rights
14:35 karolherbst: so we should have that conversation to see if 1. we acknowledge those issues and 2. what as a community we could do to mitigate the problems?
14:36 karolherbst: I don't like this sort of defeatism where we just not do anything, because we think it's pointless or inevitable
14:36 karolherbst: or because we think we don't matter
14:37 airlied: is mesa going to have to take a stance on every single moral question, or can we just go join other societies and communities of like minded people to push those ideas forward
14:37 daniels: ^
14:37 karolherbst: that's a straw man
14:37 karolherbst: like obviously we won't, but we can on matters many people in our community care about
14:37 karolherbst: because communities are about the people, or well.. that's how I see it
14:37 dcbaker: I don't think you can avoid taking a stance on a moral question, whether you want to or not
14:37 daniels: well - is it morally defensible for Mesa to support GPUs which draw 1kW, at a time where climate change is destroying the planet? or should we limit ourselves to a few watts?
14:37 dcbaker: and whether you're explicit about it or not
14:38 karolherbst: maybe?
14:38 airlied: yes and on this one, we've had the same converstation 4 or 5 times now over 3-4 months and I don't see anyone moving far
14:38 karolherbst: like.. I wouldn't mind making a decision here if many would like to
14:38 airlied: you don't need many, you need all
14:38 daniels: is it acceptable for people who have a genuine belief that supporting huge GPUs for light entertainment to shame anyone who works on those?
14:39 airlied: or enabling the pron industry
14:39 airlied: like it's tiring, let's just agree for AI, nobody gets to tell anyone else what do, how to feel, and we work out some practical framework to ensure that
14:39 karolherbst: have I said we should shame people? Or just to point out/confront people on those issues
14:40 anholt: airlied: that, exactly.
14:40 airlied: if you don't want to engage on AI PRs/MRs, just don't. like alyssa told me to fuck off with my CMM patches to intel, and I accepted it
14:41 daniels: karolherbst: do you believe that you have avoided shaming people thus far?
14:43 karolherbst: are you asking about intent or what actually happened?
14:45 karolherbst: like sure I'm not perfect, but I don't want to _shame_ people for using AI or thinking it's a great thing. I do however don't mind pointing if a certain thing has a certain negative impact. Do I want to point those out individually? No, if I have, then I'd want to know and properly apologize for it
14:47 MrCooper: airlied: "let's just agree for AI, nobody gets to tell anyone else what do, how to feel" is a contradiction
14:47 karolherbst: and also.. people do point out to me in private that they got intimidated by the pro AI crowed in this community, so not sure if mud throwing is really the way to go here. everybody makes mistakes in this conversation on both sides
14:47 dcbaker: airlied: I'm a resigned ant-AIer. I really don't like it, but I understand that people are going to use LLMs to write/edit code by choice or by employer preasure and I can't stop that. Even in a project like Meson where there is strong maintainer concencus of anti-AI, we can't stop people from submitting LLM generated patches. What I really don't want to do is interact with an agent in comments/PRs, I want to see talk to a person. The problem
14:47 dcbaker: with the "then just ignore" it is that unless I can say that I have zero dependencies on code that might get AI comments, I don't really have that ability, because the only solution to avoid that is to abandon interacting with patches or to NAK something.
14:47 dcbaker: I don't see how you avoid having a project policy on AI for comments and discussions and MRs/PRs
14:48 dcbaker: is what I'm trying to say
14:48 daniels: dcbaker: tbf, Mesa does have a policy against using agents to interact, which is something everyone actually agreed on
14:49 daniels: karolherbst: I think it's worth reflecting on
14:49 karolherbst: yeah and to be fair, I do think the current policy is more on the better side of things that are achievable here
14:49 karolherbst: daniels: same back to you tho
14:49 daniels: ofc
14:50 karolherbst: but again.. point out the specifics and I'll gladly apologize for it
14:50 mareko: my personal AI code reviewer helps produce code that has almost no bugs before I test it for the first time
14:50 mareko: *helps me produce
14:50 karolherbst: like I definitely don't want to point out individuals, and I know I've made mistakes in the past
14:51 mareko: my instructions to it is that its role is only advisory, it can't change files, and that's about it
14:51 karolherbst: yeah and I wouldn't be surprised if that's something a lot of people will end up doing long-term
14:52 karolherbst: having good code analysis tools is a good thing, I just wished... all those other issues would exist related to AI
14:53 dcbaker: daniels: I was using that as an example everyone agreed on, to make the bigger point that there really isn't a way to have a policy for shared components that makes everyone happy, and "just ignore it" doesn't work. If someone sends a large LLM generated series to NIR and half of the NIR developers refuse to interact with it on principle, and then it gets merged and there are problems. I hope the point makes sense. I don't think we can put LLM
14:53 dcbaker: usage in the same category as "do you like vim or emacs or vscode", if half of the project is refusing to look at the other half's code on principle, we have a problem.
14:53 karolherbst: well it wouldn't get merged, because somebody would nack it.. probably
14:53 daniels: dcbaker: that I agree with
14:54 karolherbst: I don't think we are at the stage where things just get merged like that and I do trust maintainers to do proper reviews and developers to not sneak things in to avoid the nack or something
14:55 daniels: again, if we don't trust developers to responsibly merge things, they should not be able to merge things
14:55 karolherbst: or at least I haven't seen it yet happening in that sense
14:55 karolherbst: right
14:55 dcbaker: I'm not trying to accuse ill intent
14:55 dcbaker: sorry if I did so
14:55 karolherbst: I mean.. in principle I agree, but "trust" is a very difficult topic for some people
14:55 daniels: dcbaker: I didn't read that into your message at all
14:55 karolherbst: I generally would avoid blanket statements around trust. While yes, in a perfect world everybody here should trust every developer, but in reality it's more complex than that
14:56 Company: dcbaker: the obvious MR example would be something like "LLM rewrite of NIR in Rust" I guess?
14:56 dcbaker: I was thinking more along the lines of a major Vulkan or SPIR-V change coming in
14:57 soreau: mareko: that sounds like a good workflow but how does the review know your intent? like I had AI review my code yesterday and there was one line that should have been omitted but it made a production out of it instead of realizing it didn't need to be there in the first place
14:57 dcbaker: but sure, adding Rust support, even in the kernel style of "rust wrappers"
14:58 soreau: like HdkR said, when has AI ever produced a net-negative LOC patch?
14:58 karolherbst: we had some
14:58 karolherbst: but the purpose was to remove stuff...
14:58 soreau: right, that was the intent
14:59 karolherbst: I mean yeah.. AI can generate a lot of bad code, but from what I've seen from developers that know how to use it, it can be good. Just sometimes you have to spend more time on review, or less.. depending on the person
14:59 mareko: soreau: I have a good model that doesn't seem to produce slop at all
14:59 karolherbst: like I'm not a fan of people that just go and say that all AI content is terrible
14:59 soreau: yes, you can't give a double edged sword to a toddler and expect a warrior
15:00 soreau: mareko: that's because you know how to prompt it though, I'd expect :P
15:00 mareko: the prompt is often either "review HEAD" or "review again"
15:00 jenatali: It really seems it all boils down to trust
15:01 soreau: mareko: ah ok :)
15:01 mareko: it's GPT-6-Astra medium
15:01 karolherbst: soreau: tbf, quality of reviews is quite a lot better than code generation in general
15:01 jenatali: If you trust someone to have good judgement, then that could extend to that person's judgement of generated code, both from a point of posting and reviewing patches
15:01 soreau: karolherbst: makes sense
15:01 karolherbst: but still not at a level where you could just hook it up to CI and expect wonders
15:02 karolherbst: like.. being able to filter is a skill
15:02 alyssa: unsurprisingly, the people who were writing high quality Mesa patches pre-AI are largely doing the same now too (mareko is in this category)
15:02 alyssa: and the converse also... largely holds.
15:02 karolherbst: jenatali: yeah, that I guess makes sense
15:03 jenatali: Also in my experience a lot of the "AI text" actually comes down to specific models. The Claude models are awful at this while GPT models are much better
15:03 karolherbst: a lot of the anti-AI discourse is also from people that can't effort to simply trust others
15:03 alyssa: jenatali: I don't understand how Claude models manage to be so /annoying/
15:03 karolherbst: for various legitimate reasons
15:04 jenatali: But we shouldn't be trying to dictate "you can only use X model because it writes comments more human-like" IMO
15:04 jenatali: I think it really just comes down to people using their own judgement here
15:07 daniels: alyssa: yeah, and equally the discussion about which tools we should allow for contribution, hasn't been about whether or not we should allow shit contributions
15:08 soreau: I'm in the category where I write something by hand, upload it and then people from unlikely sources feed it to their model to review. not saying my code is perfect but the old adage applies here - Garbage In, Garbage Out. You can't feed ai-review a thoughtless patch (set) and expect it to know your intent without telling it somehow
15:08 daniels: karolherbst: running a zero-trust community is fundamentally impossible
15:08 karolherbst: I agree with that
15:09 karolherbst: I'm just saying that trust is a difficult concept for people for good reasons
15:09 karolherbst: well.. some people
15:09 soreau: daniels: true, even Linus said it re. sussytem maintainers - the flow is based on a chain of trust of people
15:10 soreau: subsystem*
15:10 karolherbst: like I think it goes too far to expect trust to be there. Sometimes it just takes a really long time to build. And there shouldn't be an automatic there either
15:10 karolherbst: it's fine if people here aren't trusting everybody from the start, and trust always have to be build individually
15:10 karolherbst: but some people have a very easy time to just trust everybody being a developer
15:10 karolherbst: not everybody has this luxury
15:11 Company: isn't cargo or pypi or npm essentially a zero-trust community? Where people just pull in whatever package looks good without the slightest clue about its maintainers?
15:11 mareko: given how much good model subscriptions cost, I estimate a good AI review bot for Mesa that doesn't blow through the weekly token budget in 1 hour would likely cost thousands of dollars a month to operate and be beneficial
15:13 daniels: Company: cargo/pypi are less fd.o and more pastebin
15:13 karolherbst: well.. I'm sure some companies might be willing to pay for that...
15:13 karolherbst: just needs the right spin
15:14 Company: daniels: I think with that example I was trying to understand the nuances of what "community" and "zero trust" mean in your sentence
15:14 daniels: Company: you get away with zero trust because you don't have to interact with anyone, and you're in full control of whether not anything anyone else does can affect you. that's ... not true in a shared codebase.
15:16 Company: kind of - with cargo it is also a shared codebase - and I would argue even with the old C/distro model alll your deps are more or less shared, unless it's a well-defined interface like GL or POSIX
15:21 Ermine: Don't really want to give any ai advice, but gregkh in a recent talk stated that local models are good enough. But that was for kernel, not sure if that's relevant for Mesa.
15:21 Company: that talk was about security
15:22 Company: not about code authoring/review
15:22 daniels: Company: it's a shared codebase sure, but you can pin your deps to the specific version you like, without having to trust that the other person won't subsequently do something bad
15:23 Ermine: ah indeed. Though it boiled down to finding bugs, so that's kind of review too...
15:23 Company: you want security and bug fixes, so pinning is not really what you want. And it assumes that you review the version you pin to
15:30 airlied: dcbaker: so the counterexample I have been given, is if a developer submits human code, and we have an AI patch reviewer but they ignore the reviews and their code has bugs that I have to fix later, what is the answer?
15:31 airlied: like do I stop accepting code from that developer because they are putting burden onto others?
15:32 karolherbst: I think the issue with static code analysis is, that people have experience there, and the experience is usually "too many false positives"
15:32 dcbaker: airlied: That seems like another manifestation of the same problem I'm trying pointing out with the "just ignore AI generated conent"
15:33 karolherbst: there is a high bar until such systems are perceived as genuinely helpful
15:33 alyssa: I'd rather have AI reviews and no AI code, than AI code and no AI reviews.
15:33 MrCooper: depends e.g. on the signal to noise ratio of the AI patch reviewer
15:33 alyssa: IMHO
15:33 karolherbst: +1
15:33 dcbaker: I've found AI code review to be pretty good, tbh
15:33 karolherbst: yeah I do get the argument for AI code review, and I think once it's ready that's something worth talking about
15:33 airlied: karolherbst: in the kernel sashiko is more useful than it isn't, like stats show reduced followup fixes
15:33 dcbaker: Like, it was able to find python and C++ exceptions that I wasn't handling that I should
15:34 karolherbst: airlied: I didn't mean "it's more than 50+" I mean "what rate do we need so people aren't annoyed"
15:34 karolherbst: and the rate is above 80%+
15:34 karolherbst: somehwere
15:34 karolherbst: we don't know yet
15:34 karolherbst: no system has ever been that highly reliable
15:34 airlied: but even at 50% is annoying people worth it, vs letting bugs in that might cause others annoyance?
15:34 karolherbst: greg said it in regards to coverity, they have a 80%+ rate of being right, still people don't like it
15:35 karolherbst: airlied: who is filtering?
15:35 karolherbst: like I get that experienced devs know
15:35 karolherbst: but do new ones do?
15:35 karolherbst: I'm happy about devs doing it on their local machine, that seems fine
15:35 karolherbst: I wouldn't agree that we are ready yet to roll it out generally
15:36 karolherbst: but...
15:36 MrCooper: 50% was nowhere near acceptable for traditional static analysis, why would it be now?
15:36 karolherbst: I could also be just overcautious here
15:36 airlied: MrCooper: because it finds bugs better than static analysis
15:36 airlied: and it happens directly on sending the patch
15:36 airlied: not 4 months later
15:36 karolherbst: airlied: greg said that coverity was more reliable than shasiko tho
15:36 airlied: karolherbst: and sashiko is more productive
15:36 alyssa: coverity finds dumber bugs than sashiko
15:37 dcbaker: As the Intel Coverity monkey.... Coverity is awful
15:37 alyssa: ^ that
15:37 karolherbst: yeah maybe sashiko is already better from an experience/UX pov
15:37 airlied: I was the meas covertiy maintainer for a few years
15:37 karolherbst: haven't done much kernel development recently
15:37 alyssa: I would happily have Sashiko if it meant people would stop asking me to human review AI code
15:37 airlied: it wasn't a pleasent time
15:37 karolherbst: right
15:37 alyssa: and instead Sashiko reviewed their human code
15:38 dcbaker: all of the bugs are: "Wow if C had non-nullable pointers this wouldn't exist", "if C did the obvious widen before arithmatic this wouldn't exist", "if C had a way to deterministically clean up on funciton exit (destructors, defer, something) this wouldn't exist."
15:38 karolherbst: great to spot them tho
15:38 karolherbst: I mean maybe we should do something opt-in there at some point.. dunno
15:39 dcbaker: And the nullable pointer thing is always 100 steps in a helper function with three deep nested loops that was just missing an assertion
15:41 dcbaker: While we're having a flame war. 2 of those three issues are solved by C++ :D
15:41 karolherbst: I always loved the concept of static code analysis, so if we do have something really incredible awesome there then that's for sure worth looking into
15:41 karolherbst: dcbaker: rust has all three I guess :P
15:42 alyssa: maybe I should RiiR jay..
15:42 dcbaker: Rust has all three, yeah
15:42 dcbaker: I guess C23 might get a defer keyword
15:42 karolherbst: yes!
15:42 karolherbst: I'm hyped for defer
15:42 dcbaker: errr, whatever the next C standard is
15:42 karolherbst: day 1 we should move to C23, lol
15:42 karolherbst: C26?
15:43 karolherbst: ohh
15:43 karolherbst: they go with C29...
15:43 karolherbst: oh no
15:43 dcbaker: Not sure, last I saw defer was kinda embroiled in whether C should get lambdas
15:43 karolherbst: yeah.. the syntax is kinda weird
15:43 karolherbst: but it's defer
15:43 karolherbst: so need to use macros to make it sane anyway
15:44 dcbaker: It would kill like 50% of the real bugs in mesa that coverity finds
15:44 karolherbst: yeah...
15:44 karolherbst: (so would a full rust rewrite :P)
15:44 karolherbst: but... speaking of coverity...
15:44 karolherbst: would there be a way to make the reports more accessible?
15:44 karolherbst: I always hated the UX
15:44 dcbaker: lolol, tell me if you find a better way
15:45 alyssa: dcbaker: C is getting defer without lambdas
15:45 karolherbst: I hoped "some bot posting on the MR" would be nice lol
15:45 alyssa: It's purely lexical, it doesn't add new "structure"
15:45 karolherbst: alyssa: there are also defer blocks
15:45 dcbaker: ah, they went with the blocks proposal
15:46 karolherbst: it's kinda funny there is a C block syntax since almost forever
15:46 dcbaker: There's been a push to make C++ a strict superset of C again, so everytime there's a new feature that would require changing both languages there's always the tension of "C++ has a solutio for this, can we sue that?"
15:47 karolherbst: somebody thought it would be funny to have blocks in OpenCL C, so clang added support for it.....
15:56 dcbaker: Oh nice, C29 also adds a standard way to get the number of elements in an array
15:57 karolherbst: oh wow!
15:57 karolherbst: 2029 is going to be the year of C
16:01 karolherbst: wait.. we also get case ranges?!?
16:01 Hazematman: How long until we can adopt C29 after it comes out? 😅
16:03 alyssa: dcbaker: I tried https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41801
16:12 karolherbst: :'(
16:12 CounterPillow: Impressive frontend bug
16:15 CounterPillow: I wish I could use explicit backing types on enums in the kernel on occasion, but I know I won't get to use that C23 feature for a while longer because GCC 8.1 is still supported
16:15 CounterPillow: e.g. there's a panthor priority type that currently u8 for size reasons but really should be the priority enum, but it can't be because the enum is int, so you either choose type safety or struct size
16:16 CounterPillow: s/type/member/
16:17 dcbaker: alyssa: that makes me sad
16:24 daniels: MrCooper: 'depends on the signal to noise ratio' is true of any reviewer ...
16:25 soreau: CounterPillow: couldn't you swap the enum for #defines cast to u8?
16:26 CounterPillow: soreau: then you lose the enum type safety of your compiler warning you if you've forgotten a case in your switch statement etc.
16:26 rpavlik: i <3 static analysis. I used to be really annoying with it. esp. back in ~2010 when I was trying to do more cross-platform builds (linux, windows, mac)
16:26 soreau: CounterPillow: hm, tradeoffs
16:26 rpavlik: Clang getting better warnings really raised the bar
16:27 DragoonAethis: karolherbst: dcbaker: if you hate the Coverity UX, you can always download the raw data from its API and vibecode a better UI :^)
16:29 rpavlik: there is some Ericsson frontend for a bunch of static checkers, I don't remember but it might let you pull in coverity too. it pulls in several other formats
16:29 karolherbst: DragoonAethis: there is raw data dump? interesting...
16:30 DragoonAethis: rpavlik: you mean https://github.com/Ericsson/codechecker maybe?
16:30 karolherbst: I wonder if something with the gitlab UI is possible. Could maintain a list of lints that are almost always correct or something... and get it posted as a gitlab review comment?
16:31 karolherbst: I think my UX gripe is, that if you submit an MR, some tool should run on it and comment on the code in the question
16:32 karolherbst: but I guess coverity only does scans on main?
16:32 DragoonAethis: No, you can do premerge runs on Coverity too
16:32 karolherbst: guess somebody has to pay for that then?
16:32 DragoonAethis: It's a bit harder to pull off and I don't know if the sponsored Coverity Scan thing works for it though
16:32 rpavlik: yeah that's the one. no import, bummer
16:33 dcbaker: DragoonAethis: I think the free ones have a 1 per month scanning limit
16:33 DragoonAethis: welp, that sucks
16:34 DragoonAethis: I don't know if anyone played with gcc's -fanalyze?
16:34 karolherbst: the issue with those is always UX and.. false positives
16:34 karolherbst: I did play around with fanalyze, but it gets tiring real quick
16:35 DragoonAethis: You're not going to run away from that with C though
16:35 karolherbst: the default lints clippy has enabled for rust code are pretty solid tho...
16:35 rpavlik: Fanalyze: not as fun as fun, safe math optimizations
16:35 karolherbst: but I think my point is more: find good lints that are ~99% correct, figure out how to add those to CI, make the thing post on the MR
16:36 rpavlik: yeah. the glue code to turn it into gitlab notes is really the missing link for easy actionable work. if you find a tool to do that, lmk, i've got several more projects that could use it
16:37 karolherbst: gitlab has an API
16:37 rpavlik: oh i am painfully familiar :D
16:37 karolherbst: the review one isn't even horrible afaik
16:37 rpavlik: https://github.com/rpavlik/OpenXR-Automation
16:40 karolherbst: uhhh.. what was the name for the review notes in the API...
16:41 DragoonAethis: karolherbst: Discussions API
16:41 karolherbst: pain!
16:41 karolherbst: but yeah..
16:41 karolherbst: that's the one
16:41 karolherbst: should be a simple API call to post those
16:42 karolherbst: the more difficult part is going to be.... force pushes to MRs
16:42 karolherbst: could maybe not run if it's drafted. or always opt-in
16:43 karolherbst: or it's a label that the author applies
16:43 karolherbst: I think it would be cool to get infra going for that at least
16:43 rpavlik: oh yeah, if you run the fixes and want to push it, that's a whole other can of worms. Right now i'm experimenting with those as a "not run by default" job in the pipeline
16:44 karolherbst: auto resolving would also be nice...
16:44 karolherbst: in theory that's all super simple, in practice you have changes of the line number and identifying resolved problems is going to be annoying..
16:44 rpavlik: the associating of old warnings with new ones to compute the resolved set would be the hard part. I wonder if the test results interface would help at all there
16:45 karolherbst: mhhh
16:45 karolherbst: maybe?
16:46 rpavlik: the irony is that on all my projects, test fail equals CI fail, so the test results interface almost never has useful things, but I know it has a between-runs diff
16:46 karolherbst: the pasting of the thing could be an optional step
16:46 karolherbst: like.. it's just a test run, but then some bot converts the output to discussions on request
16:46 rpavlik: sure
16:46 rpavlik: might be less annoying like that too
18:24 rpavlik: ahh there is a built-in thingie. https://docs.gitlab.com/ci/testing/code_quality/#import-code-quality-results-from-a-cicd-job
18:25 rpavlik: but it looks like the nice UI is in Ultimate only
18:30 karolherbst: ohh....
18:30 karolherbst: interesting
19:00 linkmauve: Hi, how does a driver wait for the rootfs to be available? In order to reduce the duration of a reboot and speed up my development, I disabled initramfs and module support in the kernel, but now my driver gets loaded very early during boot, before the rootfs is available, so it fails to load its firmware.
19:01 linkmauve: I found this patch from a decade ago, but nothing else in a recent kernel: https://lkml.iu.edu/hypermail/linux/kernel/1409.1/05465.html
19:01 linkmauve: How do other drivers do it?
19:02 dwfreed: if you've disabled module support, the driver is initialized extremely early and there's nothing you can do about that; you can build the firmware into your kernel and that will satisfy the driver
19:04 linkmauve: Should I make that conditional on it not being a module? Or is there some other config I should take in consideration?
19:05 linkmauve: Do other drivers care about that, or do they also fail in this situation?
19:05 karolherbst: you can embed the firmwares into the kernel and that's usually the way to resolve it
19:08 dwfreed: see https://elixir.bootlin.com/linux/v7.2.8/source/drivers/base/firmware_loader/Kconfig#L53
19:59 Venemo: hey guys, do we know yet when is the branch point for Mesa 26.3?
20:00 karolherbst: the 14th according to the doc
20:00 karolherbst: you can check out https://docs.mesa3d.org/release-calendar.html usually
20:00 karolherbst: ohh wait.. that's rc1...
20:02 Venemo: rc1 is the same as the branchpoint isn't it?
20:02 dcbaker: Venemo, karolherbst: branchpoint and rc1 are at the same time
20:02 karolherbst: ahh, okay
20:02 Venemo: thanks dcbaker for clarifying that
20:02 karolherbst: so I didn't say nonsense at first, :D
20:26 dcbaker: So, I'll be starting that process in about a week :)
20:29 alyssa: dcbaker: !remindme in 6 days: panic upstream jay branch from august
20:30 dcbaker: alyssa: Ack
20:30 dcbaker: Also, I'm expecting we'll backport a lot of Jay work
20:31 alyssa: Yeah, there's just one feature branch that we technically need for correctness
20:31 alyssa: and both of our lives are easier if I can focus long enough to finish it off and merge it :p
20:32 dcbaker: Lol. I'll keep asking about it
20:32 alyssa: (Zero known workloads or conformance tests exercising the code path, but, technically Jay is out-of-spec right now.)
20:33 alyssa: I am expecting piles of smaller bug fixes to get backported but that's the only Big piece
20:34 dcbaker: Also, Coverity has in the most around-about way ever notices that util_dynarray_Append_typed and _append_array can attemp to use nullptr as a dest parameter in memcpy, the first of which blames to you
20:34 dcbaker: I'm trying to decide if it's worth hanlding
20:34 dcbaker: or just ignore it
20:34 alyssa: Uhhh
20:36 dcbaker: The question I have is how the heck do you handle it? if dynarray_grow_bytes fails and returns a nullptr do you just... not do the memcpy?
20:36 karolherbst: just use the non_null attribute? 🙃
20:36 dcbaker: C macro magic is hard
20:37 karolherbst: ohh.. dynamic reallocation failing..
20:37 dcbaker: Yeah
20:37 karolherbst: uhh.. pretend that it never happens like everybody does?
20:38 karolherbst: I kinda hate that interface..
20:38 karolherbst: maybe we should have a wrapper that simply aborts if realloc ever returns NULL
20:38 dcbaker: My three thoughts are: 1) ignore it. 2) abort if it's NULL 3) skip the memcpy if it's NULL
20:38 karolherbst: I mean technically we'd have to through that error up to the API where possible...
20:38 karolherbst: but...
20:39 karolherbst: none of the rust code atm does... soo....
20:39 karolherbst: though I did plan to enable the explicit memory handling stuff for rusticl... I'm not sure it's worth the pain
20:42 dcbaker: The annoying part is it's intuitively obvious to me how to make this do what I want in C++ with templates, but how to get a C macro that does what I want...
20:42 dcbaker: I think we'd want to return a bool for success or not, and let the caller decide if they want to know if the copy happened
20:42 karolherbst: maybe make a realloc_on_success helper with a status return?
20:42 karolherbst: ehh realloc_with_copy_on_success
21:13 alyssa: dcbaker: if malloc fails in mesa, everything blows up
21:13 alyssa: IDK why we pretend otherwise
21:13 zmike: I don't
21:14 alyssa: I don't either, and feel vaguely bad about it
21:14 zmike: pour yourself a cold glass of water
21:14 zmike: you're a hero
21:14 alyssa: https://www.youtube.com/watch?v=z9C0yakmues
21:14 alyssa: brought to you by Q from Star Trek
21:17 zmike: incredible.
21:32 orowith2os: daniels: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/44924 is up by the way.
21:53 HdkR: Having a static string in the library somewhere so when malloc fails you can spam "Help! I've run out of memory and will explode!" through a raw write to stderr. Not a bad idea
21:54 HdkR: Just make sure to track every allocation through library local allocator, ez :P
21:57 soreau: or, or.. write a net_malloc() and borrow some memory from other machines through the tubez
21:58 soreau: it won't be slow or horrible, and you will have saved the day
22:00 HdkR: With oversubscription malloc is only likely to fail for 32-bit processes anyway. So it'll just eventually crash on access otherwise
22:03 orowith2os: soreau: reminds me of using Google Drive as swap space.
22:06 Ermine: can you just download more ram
22:06 zmike: I can
22:06 zmike: you can't
22:07 Ermine: then i want your api key for that ram downloader
22:07 orowith2os: zmike's just special like that
22:10 HdkR: Once you have your own allocator in place, you can just start dynamically paging stuff to disk :P
22:13 orowith2os: feels like (ab)using seccomp would be better for that ðŸ«
22:21 alanc: just tell your kernel to up the compression level for all your RAM, and wait for it to recompress everything already in RAM
22:22 alanc: (and more seriously, even on systems with overcommit disabled, it seems like we see more failures from users setting stupid limits via setrlimit() and the like than actually running out of memory/address space)
22:41 alyssa: Ermine: downloading RAM? in this economy?!
22:41 alyssa: you Wouldn't Download A RAM
22:42 karolherbst: I know about so many cursed ways to extend RAM and downloading RAM wouldn't even the be most cursed one
22:42 rpavlik: cache as ram
22:43 rpavlik: mercury delay line </oldschool>
22:44 karolherbst: there is a RAM via OpenCL cl_mem allocation thing somewhere
22:45 karolherbst: I tihnk technically it was for adding it as a swap partition
22:45 karolherbst: and the cl_mem was backing a fuse partition
22:46 karolherbst: uhh block device I mean
22:50 HdkR: alanc: Just use VA rlimits set to 20GB as a security precaution :P
22:53 Ermine: alyssa: i mean warez ram
23:00 karolherbst: yeah I also want to know where the ram is
23:02 orowith2os: karolherbst: I remember reading that funny arch wiki page on using an AMD GPU as swap 🙃
23:03 karolherbst: it's a great idea!
23:13 DragoonAethis: NFS as swap is always a great idea
23:15 alanc: swapping to NFS worked for diskless Sun 3 workstations with 4MB RAM back in the 80's... it didn't work quickly, but it worked...
23:25 HdkR: If you have like 800gbit network connections it probably won't even be terrible :P
23:25 DragoonAethis: Hmmm, on AWS you can mount S3 as NFS I think?
23:25 DragoonAethis: Wonder how that would work
23:31 karolherbst: RAM as a service
23:33 soreau: and train AI to download the RAM it needs to do your biddings
23:33 Hazematman: yes RAMaaS
23:34 alanc: trade ENOMEM for ENOUS-EAST-1 when there's an AWS outage
23:49 soreau: zmike: I just read through your latest and it's possibly one of the most transparent thing I've ever skimmed.
23:50 soreau: maybe rename it to 'How to become a FLOSS developer in 60 minutes or less'