03:08 alyssa: robclark: i will ack if you MR a revert
07:40 glehmann: robclark: alyssa: tbf, zmike fixed up drivers for month, it's no coincidence that crocus and asahi broken - those two drivers have no CI
07:42 glehmann: obviously the current situation is not ideal, but only putting the blame on him isn't fair either
07:46 glehmann: karolherbst: https://github.com/CachyOS/CachyOS-PKGBUILDS/blob/master/mesa/mesa/PKGBUILD#L97 cachyos should not use lto
11:30 stefan11111: Posting this question here, to give it more visibility in case someone from intel has the time to respond: https://gitlab.freedesktop.org/mesa/mesa/-/issues/14452
11:45 vsyrjala: the limited size hints are a compromise to avoid a gigantic list. the non-square cursor hardware support also got nuked on the latest platforms
11:50 tzimmermann: mlankhorst, thanks for doing the -fixes PR
12:29 mlankhorst: tzimmermann: np :)
13:04 karolherbst: I've felt the urge to write something up in regards to using AI/ML tools for issue reporting: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38887 please comment
13:05 karolherbst: glehmann: I've only checked the mesa-git package and there it's enabled as far as I can tell
13:06 K900: Something that in my experience helps a lot is to say "if you've used an AI tool, you must disclose it"
13:07 K900: Helps manage expectations
13:08 karolherbst: b
13:08 karolherbst: ...
13:08 karolherbst: https://github.com/CachyOS/CachyOS-PKGBUILDS/blob/master/mesa/mesa-git/customization.cfg#L62
13:09 karolherbst: K900: I don't really care if they disclose it or not, I do care that it's not 100 pages of nonsense until I realize it's nonsense
13:09 karolherbst: like if they can vouche themselves personally for the correctness, whatever really
13:10 K900: Disclosing makes people consider the implications more, I think
13:10 karolherbst: maybe
13:10 karolherbst: like people will be more critical yes, but I don't think it really changes much fundamentally
13:10 danylo: I don't think those how just paste llm output without thinking a bit do read the rules about posting the issue
13:11 karolherbst: like if somebody opens an issue and sounds like they own the place and already know everything, then it doesn't really make a difference to me if it's AI generated or not
13:11 karolherbst: I'd close the issue regardless
13:12 karolherbst: (and being super wrong about most of it)
13:17 robclark: glehmann, alyssa: not sure CI would catch this.. we have plenty of CI for freedreno.. but I kinda see what is going on.. the changes around u_upload are fundamentally unsound if there are more than one allocation from the uploader per draw (which defn happens if driver uses same uploader for const and streaming, but can happen in other cases like user indexbufs). I could turn some hacks I have to force this case into a debug
13:17 robclark: option to make it insta-explode. But I think a partial revert of b3133e250e1c40496d98c4ba52386b7ae423d194 is doable
13:22 kisak: Kinda skirting the issue that it's the DDoS attack nature of the content against dev time. What could be written in a sentence is boldly and confidently written as an essay, regardless of any perceived truth behind the original idea that was being communicated.
13:23 karolherbst: yeah.. I think that's more or less the gist of it
13:24 karolherbst: if a single sentence is wrong, okay whatever, but if it's 10 pages long it becomes annoying
13:25 pinchartl: karolherbst: are you aware of the discussion on the ksummit mailing list about that same topic ?
13:25 glehmann: karolherbst: apperently they though lto is okay because mesa-git uses clang instead of gcc. But they are going to disable it
13:26 karolherbst: yeah.. I think somebody really needs to figure out why lto is breaking things. Might as well be our bug and then it doesn't matter what compiler you are using...
13:26 karolherbst: pinchartl: not really
13:28 karolherbst: but I'd assume it's some variant of "you own the entire output as if it would have been written by you, no 'this is ai generated' excuses"
13:29 pinchartl: there's a wide variety of positions
13:29 pinchartl: the topic was discussed today during the maintainers summit too
13:29 pinchartl: I expect a report on lwn.net soon
13:30 karolherbst: I see
13:31 karolherbst: but that's about code contributions, right?
13:31 karolherbst: that's a topic we haven't really gotten into yet that much, and I'd rather treat it differently from issue reports
13:32 karolherbst: random users using AI chatbots because they think it's going to be useful is probably a bigger issue than random developers using it for code generation anyway
13:44 pinchartl: karolherbst: code, bug reports, commit messages, everything
13:45 karolherbst: ahh, I see
13:48 pinchartl: https://lore.kernel.org/ksummit/57ed7cafe0c0a69d8a1a1d0bc7c2f312212c67b0.camel@HansenPartnership.com/T/#m30873ef3dc9bd2c4c95547e81efff3085474f2d9
13:48 pinchartl: https://lore.kernel.org/ksummit/aO3415vQ7TcOGz8a@stanley.mountain/T/#m4c1b1e911c7fb4ebd886f9fabdef645409114353
13:55 karolherbst: right.. I think from a contribution pov we'll gonna need to have those discussions sooner or later, but the thing is, if nobody feels the urge to start it, there is probably also not really the need for it right now
14:03 javierm: pinchartl: thanks for bringing out the ethical question in that thread
14:06 pinchartl: javierm: you're welcome
14:06 pinchartl: it's a question that is very rarely raised
14:07 javierm: exactly
14:22 karolherbst: yeah, I mean I don't mind discussing the ethical aspects of AI (which given the big shots in the space are all massive assholes... isn't too surprising that the ethics are mostly either not there or bad), but that's generally a more difficult thing to discuss and I'd rather go with the low hanging fruits first :P
14:55 sima: rodrigovivi, for ras I think best case we get some acks and then I guess ship it
14:55 sima: kinda awkward I'm not at lpc because out sick, that would have been a perfect topic
14:56 sima: maybe airlied or dakr can haggle it around to some folks there
14:56 sima: I don't think I have useful opinions myself on the technical details
15:08 rodrigovivi: exactly what I'm looking for.... my understanding is that it aligns with all it was discussed in the lpc a few years ago. But it would be awesome to be discussed there once again for the final confirmation
15:50 llyyr: is fdo dead
15:51 Venemo: it is dead for me
15:51 Venemo: says "HTTP 502: Waiting for GitLab to boot"
16:02 HdkR: supa-dead
16:04 HdkR: Oh, it might be back
16:11 stefan11111: vsyrjala: thanks
17:11 biju: Any one tested suspend to ram on ADV753{3,5}? Currently I am seeing HPD Interrupt bit is set after STR wakeup, before powering up the device using adv7511 driver. This causes missing interrupt as it is hardware driven.
17:36 dcbaker: Anyone care to ack this: https://github.com/mesonbuild/meson/pull/15372
17:36 dcbaker: wrong channel
17:36 dcbaker: derp
18:40 HdkR: "image driver extension not found" What is reporting this error message? grep is failing me today.
18:42 HdkR: It has a `libGL error:` it front of it but I can't seem to find it in mesa or glvnd
18:48 HdkR: I'm doing some terrible terrible things to a mesa build, so it's probably related.
18:52 robclark: dcbaker: do you know any good way to get a recursive graph of commits chasing thru Fixes tags?
18:54 dcbaker: robclark: recursively? Not off the top of my head
18:54 dcbaker: there's some python code in bin/pick/* for doing that at a single level
18:54 robclark: hmm, ok.. yeah was wondering how to deal with fixes of fixes
18:54 robclark: ok
18:54 dcbaker: I would guess it's not too hard to make that recursive
18:54 robclark: I'll take a look
18:55 dcbaker: I do remember that there's a corner case in that code for the way pick works, but I don't think it would matter for you
18:55 dcbaker: something to do with the fact that commits have different shas on the stable and main branches
18:55 dcbaker: which, I should fix
18:56 robclark: hmm
18:57 elibrokeit: dcbaker: did someone say Gerrit?
18:58 dcbaker: elibrokeit: please no
18:58 dcbaker: I don't think I can handle having to deal with gerrit and jira at the same time, lol
18:59 elibrokeit: heh, well, just consider that Change-Id solves this problem of having different sha1 across cherry picks
18:59 dcbaker: IIRC we have all of the information we need, we just don't look at it, lol
18:59 robclark: the different sha's are really not the biggest problem here, tbh
19:00 elibrokeit:has had Gerrit on his mind due to explaining repeatedly to people how forgejo's AGit support works
19:00 dcbaker: Yeah, you just jogged my mind that there's a bug there that I'd forgotten about
19:00 mareko: isn't gerrit great
19:03 elibrokeit: Gerrit has been the only serious effort to try improving the git workflow since GitHub was created
19:04 elibrokeit: creating review requests by pushing to refs/for/master is a mind-opening experience, it is very nice that forgejo adopted it
19:04 K900: Honestly gerrit is terrible, everything else is just worse
19:12 jannau: HdkR: probably old mesa. removed in https://gitlab.freedesktop.org/mesa/mesa/-/commit/3ae6ec9f60651dd5b57c05c8e35b83dbdde66eec#b6a76d910e44c480478ec8b942b695adde555d79_898_878
19:13 HdkR: hmmmm. Wonder what would cause that when I'm building HEAD
19:15 HdkR: At least gives me a direction to look
19:21 robclark: mareko: maybe you have some ideas on https://gitlab.freedesktop.org/mesa/mesa/-/issues/14309#note_3232731 ? I think zmike's original MR is unsound.. but am undecided about just trying to revert the u_uploader changes to avoid refcnting (and hopefully correctly re-work the related changes in b3133e250e1c40496d98c4ba52386b7ae423d194).. or figuring out a big chain of reverts (which will have some innocent victim reverts, I think,
19:21 robclark: where driver authors would need to look and re-cherry-pick things if they want)
20:14 karolherbst: question about constant buffer semantics. If a draw or compute job would be dispatched with an ubo slot not bound, is that undefined behavior from the runtimes perspective?
20:19 karolherbst: also.. anybody with an RDNA4 GPU around to check if things like "clpeak" work when running against mesa-git? It's fine on my RDNA2, and I don't really see why RDNA4 would be any special there
20:25 mareko: karolherbst: accessing NULL bindings is always treated as out of bounds; out-of-bounds loads return 0, out-of-bounds stores are dropped
20:25 karolherbst: okay, but drivers shouldn't crash or misbehave when the frontend never bound anything there?
20:26 karolherbst: or do I have to bind NULL?
20:26 karolherbst: I was seeing weird issues coming up with shaders that have ubos declared, but I never binding anything to them (or even using them in the shader at all)
20:26 mareko: all bindings are NULL after context creation
20:26 karolherbst: but maybe my code also had other issues...
20:27 karolherbst: okay
20:27 karolherbst: so the expectation is that it should just work (tm) and in the shader all reads are 0
20:27 mareko: yes
20:31 mareko: NULL sampler views are the only ones where we return (0,0,0,1)
20:31 stefan11111: Sorry to bother you so much, last question. When using the dri libgbm backend, is GBM_BO_USE_RENDERING only used for sanity checks, or am I missing something? Is there some history behind this? https://gitlab.freedesktop.org/mesa/mesa/-/issues/14130
20:31 karolherbst: mhh maybe I messed up, because my current version of the code behaves sanely when not binding any ubos...
20:31 karolherbst: maybe something with my refactoring earlier today
20:33 karolherbst: mareko: oh btw, are `load_ubo` accesses have better performance than `load_global_constant` on AMD hardware? Not sure how much better UBOs are there, but can I safely assume it's almost always better than raw global access?
20:35 pendingchaos: karolherbst: I noticed that the int32, fp16 and int24 (especially int32) compute numbers were probably low, but clpeak+rusticl+RDNA4 worked on my machine without anything in dmesg
20:35 pendingchaos: Mesa f8363b8d259b, 6.17.8-300.fc43.x86_64, clpeak 1.1.5
20:36 karolherbst: okay
20:36 karolherbst: I had a bug report that it didn't, but that was on cachyos with mesa-git (and lto enabled probably?)
20:37 karolherbst: thanks for testing!
20:38 karolherbst: but also interesting that the numbers are low...
20:40 karolherbst: here it's generally fast than ROCm
20:40 karolherbst: on RDNA2
20:40 karolherbst: *faster
20:41 pendingchaos: I was just comparing with fp32 perf: https://www.irccloud.com/pastebin/TRXBA6dg/
20:43 pendingchaos: scalar int32 is 1/10 of fp32, scalar half and int24 is 1/2 of fp32, and vec2 fp16 is equal to vec2 fp32
20:48 karolherbst: pendingchaos: I think that's using zink, isn't it?
20:49 karolherbst: try with RUSTICL_ENABLE=radeonsi instead
20:49 pendingchaos: no, radeonsi
20:49 pendingchaos: I used that env var and only built radeonsi and rusticl
20:49 karolherbst: huh...
20:49 karolherbst: with zink it would make sense because vulkan doesn't have fma (without that extension)
20:50 pendingchaos: radeonsi switched to ACO recently
20:50 pendingchaos: (in case that's why you think it's using zink)
20:50 karolherbst: ohh wait
20:50 karolherbst: you said int is slow, not fp32 🙃
20:50 karolherbst: I should learn to read
20:51 karolherbst: yeah.. int32 feels to slow indeed
20:51 karolherbst: mhhh
20:51 karolherbst: it's fine on my RDNA2 tho...
20:51 karolherbst: ehh wait..
20:52 karolherbst: pendingchaos: no, it's fine. The issue isn't that int32 is slow, the thing is that int24 is just super fast
20:52 karolherbst: well it's also slow
20:52 karolherbst: but also slow on ROCm: https://gist.githubusercontent.com/karolherbst/1a19c30f176ec60958d830c16e82f9a7/raw/e41f59fe9e673ee79d538a1ec26934d7eab32de5/gistfile1.txt
20:52 karolherbst: but not sure if 1/10 slower is expected on RDNA4...
20:53 karolherbst: but it's 1/5 slower here
20:53 karolherbst: anyway.. looks to work fine then
20:54 pendingchaos: right, looking at clpeak source, GIOPS is integer mul+add, while GFLOPS is fp32 mul+add
20:54 karolherbst: yeah.. that would explain a 2x factor
20:54 karolherbst: roughly
20:54 karolherbst: + dependency
20:55 pendingchaos: I assumed it was doing fp32 add and int32 add or something
20:55 karolherbst: aanyway.. surprising that integer perf is so significantly worse
20:55 karolherbst: yeah...
20:56 karolherbst: it's doing like a real fma with fp32, which means that perf with zink is bad, because I have to emulate fma for zink :')
20:56 karolherbst: I really should work on the fmad+ffma MR or so soonish
21:39 mareko: robclark: replied there
21:49 robclark: mareko: the new uploader usage model is kinda awkward when you have mix of mesa/st+utils+driver all sharing uploaders ;-)
21:49 robclark: but do agree that documentation about all this is somewhat lacking
21:51 robclark: probably this gets more confused when const_uploader and stream_uploader are the same thing
21:54 karolherbst: I never really understood which one to use for cb0
21:57 karolherbst: but yeah another way to fix it is that drivers always take references, which sucks a bit, but... maybe there is some weird refcounting bug somewhere
21:58 mlankhorst: I'm applying a patch with b4, and I'm getting an extra r-b I don't see anywhere else?
21:59 mlankhorst: b4 am 20251209151319.494640-3-dev@lankhorst.se -P 1
22:00 mlankhorst: + Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> (✓ DKIM/linutronix.de)
22:00 mlankhorst: not sure where that one came from
22:02 robclark: karolherbst: actually the commit that causes all the issues dropped the take_ownership stuff, so drivers do take references now.. but doesn't help if resource is already destroyed before coming to the driver
22:02 karolherbst: mhh well that shouldn't happen...
22:02 karolherbst: mhhhh
22:03 karolherbst: so my _assumption_ on what's going on is that one of the uploaders returns the buffer through the realasebuf argument which then gets release called on and for the impacted drivers it's a simple "drop the reference" thing going on.
22:06 robclark: naw, the only thing driver related in this is that driver sets up stream_uploader and const_uploader to be the same thing.. things go belly up in btw cso and u_vbuf
22:08 robclark: having two different uploaders works (or at least doesn't instantly explode with my debug hack to make u_upload_mgr always allocate a new buffer), so seems like it is an interaction btwn const uploads and vb uploads
22:08 mareko: see my second reply
22:09 robclark: yeah, ok.. that makes sense when the two uploaders are the same
22:11 robclark: mareko: are we guaranteed to not get user buffers for const state now? That is one place (outside draw_vbo) that something inside the driver could want to use a shared uploader
22:12 mareko: robclark: r300 gets user buffers for cb0 but never uploads them
22:14 mareko: robclark: but if user buffers must be uploaded, that upload is done in the frontend instead of TC now
22:14 robclark: ok
22:15 mareko: since the 2 uploaders are different, my reply is incorrect
22:15 robclark: I guess the other case I'm think of is indexbuf uploads, but that would be in draw_vbo() after state is bound so maybe that is ok
22:16 mareko: TC uploads indices and release the release buffer after the draw
22:18 robclark: sure, but ideally we don't depend on TC
22:18 mareko: then the driver upload indices
22:20 robclark: right.. but that should be safe because the other frontend uploads should all be bound to driver, which has taken a ref
22:20 robclark:just trying to think about what usages of shared uploaders are now problematic
22:21 mareko: if you share the uploaders, then st_pbo_draw would definitely crash
22:22 robclark: well, shared both in the case const_uploader==stream_uploader.. but also thinking about other random places that driver might have internal use of uploader
22:22 mareko: pipe_upload_constant_buffer0 + stream_uploader == const_uploader + st_pbo_draw + release after the first allocation ==> crash
22:22 robclark: right, that part I figured out :-)
22:22 robclark: there are still a lot of drivers that have stream_uploader==const_uploader
22:23 robclark: I have a patch that splits them for most drivers, but still 3 or 4 drivers I need to look at closer
22:24 mareko: any place that calls u_upload_* and releases the buffer immediately and it's not inside the driver is susceptible to crashing