08:41 tjaalton: so my build with the new bindgen should be fine, but the build fails with "error: unknown type name 'atomic_uint_fast32_t'" which suggests it doesn't actually work
09:01 tzimmermann: bbrezillon, hi. panfrost and panthor do not support dumb buffers?
09:03 emersion: dumb buffers are for KMS
09:03 tzimmermann: yes
09:03 tzimmermann: oh, now i see it. those drivers dont provide that
09:03 emersion: these drivers are not KMS, are they?
09:03 tzimmermann: that answers my question :)
09:34 biju: After STR, during wakeup ADV7535 does not trigger HPD irq, in that case how framework get a notification for the connected state?
09:35 biju: What i can see before STR, the connector is in connected state. After STR connector is in disconnected state, but the display is up.
09:35 biju: STR: suspend to ram
13:20 MTCoster: I have patch in drm-misc-fixes (and Linus' tree), but now I need to send patch for drm-misc-next (which doesn't contain the original patch) that would cause a conflict. What's the correct procedure here?
14:15 wens: MTCoster: ask drm-misc maintainers to merge drm-misc-fixes into drm-misc-next?
14:27 jani: tzimmermann: mlankhorst: may I ask for rb/ab on https://lore.kernel.org/r/cover.1762251845.git.jani.nikula@intel.com please? pretty straightforward cleanup
16:01 mlankhorst: done
20:23 robclark: dcbaker: btw, not sure if you've seen https://gitlab.freedesktop.org/mesa/mesa/-/issues/14309 .. ideally we'd revert https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36296 but even on the 25.3 branch there is a bunch of stuff piled on top making that not such a simple thing to unwind .. and ofc zmike isn't around. But current state seems to be that 25.3 is broken on a bunch of drivers (firefox and possibly other
20:23 robclark: things crashy)
20:24 robclark: apparently splitting const/stream uploaders helps, but that feels a bit like papering over an issue
20:28 rcv11x: Hello devs, I use Cachyos as my distribution and wanted to ask if there is any problem with Linux 6.18.0-3, since last Saturday, December 6, I updated it and after restarting and entering the KDE Plasma login, the desktop did not load anything and there was no taskbar or anything. When I restarted the computer again to check if it was an error, I got some red letters with many error messages. I just wanted to know if kernel 6.18
20:28 rcv11x: has problems and if I should wait for 6.18.1, since I had to revert to 6.17.9. I have an AMD rx 9070 xt RDNA4 GPU and I use mesa 25.3.1.
20:28 rcv11x: Translated with DeepL.com (free version)
20:51 dcbaker: robclark: oooh, that's going to be fun
20:52 robclark: yeah.. I'm trying to figure out more about what is going on.. for sure this should be a blocker for 26.0
20:54 dcbaker: just looking at the revert diffs on those is... a lot
20:54 robclark: yeah :-(
21:02 dcbaker: So, the revert is going to be hard. Splitting the uploaders might paper over the issue for the 25.3 branch? I can test the patch on Crocus if that helps.
21:02 dcbaker: Sigh
21:03 robclark: if you can reproduce it, try https://gitlab.freedesktop.org/robclark/mesa/-/commit/bf3ed4f57425dfa7ecf823a20328d2c420f4fdeb .. there are still a couple drivers not converted since I need to look closer at their use of uploaders
21:03 dcbaker: I can try when I get home (my personal machine is crocus)
21:04 robclark: thx
21:13 dcbaker: no problem, I'm happy to be told about Crocus bugs before I run into them, lol
21:23 karolherbst: having run into issues with that change, I think splitting up the uploaders is probably the sanest thing to do here
21:35 alyssa: dcbaker: asahi is broken too apparently
21:41 dcbaker: Yeah. fortunately my macbook is so old it uses crocus. So I can pretend that everything is fine, lol
21:43 alyssa: dcbaker: ...Lol
21:44 rodrigovivi: agd5f: sorry to bug you again on this. But it would be great to have AMD eyes on the drm_ras thing... in the worst case we can convert to xe-ras netlink and only move to drm once more vendors think it is useful, but it would be better to start it already in the right place
21:44 rodrigovivi: https://lore.kernel.org/dri-devel/20251205083934.3602030-6-riana.tauro@intel.com/
21:45 rodrigovivi: airlied: sima: ^ please let us know your thoughts on that as well.
21:54 robclark: karolherbst, dcbaker: the patch splitting uploaders at least seems to fix the ffox issue.. but it is looking like the issue is actually u_vbuf.. and not clear to my why splitting uploaders fixes anything, other than maybe by chance
22:03 karolherbst: refcounting semantics are weird now, like how zink uses the const uploader + u_upload_data_ref inside set_constant_buffer
22:04 karolherbst: and then releasing the pipe_resource_reference
22:05 karolherbst: there is u_upload_data vs u_upload_data_ref now
22:06 robclark: yeah, I'm not really loving it.. and we probably should land these type of zmike changes before he goes on vacation ;-)
22:07 karolherbst: heh
22:08 karolherbst: I think it just need proper documentation, because usually when something went wrong it was just me not knowing what zmikes plans were or are 🙃
22:36 karolherbst: mhhh cachyos uses lto with mesa? mhhh
22:36 karolherbst: I don't think we support that, right?
22:52 airlied: they get to keep both halves
22:52 airlied: we definitely know it breaks depending on the gcc you use
23:04 karolherbst: well.. guess I shouldn't feel to bad closing issues from cachyos users then..
23:05 karolherbst: but also would be good to know if it's caused by UB on our side or just broken compilers 🙃
23:05 karolherbst: and maybe we should just refuse building with lto until that's all sorted out? Or is it really gcc specific?
23:06 robclark: so this is nutty, now u_upload can hand back a prsc with no refcnt.. pass it to driver which takes and later frees ref to that prsc, destroying it.. meanwhile u_upload will still happily will hand out the same prsc. I'm not entirely sure how this is expected to work in the first place
23:07 robclark: maybe I should just bite the bullet and figure out how to revert this mess
23:10 karolherbst: robclark: yeah, that's why you should use u_upload_ref if you need a ref
23:10 robclark: I'm a bit confused about when u_upload would not need a ref for itself
23:11 karolherbst: for non refcounted objects
23:11 karolherbst: like some of the resources are specifically owned by the frontend
23:11 karolherbst: and drivers just get a pointer to it without taking ownership, nor increasing the ref count
23:12 karolherbst: and if the frontend is done with it, it calls release to free up it's ownership and hands it to the driver
23:12 karolherbst: and the driver is then free to delete it
23:12 karolherbst: I _think_
23:12 robclark: well, I'm still trying to sort out why the prsc doesn't have a refcnt=1 when it is created.. but what happens is driver obtains a ref which is viewed as Create, and later drops the ref.. meanwhile afaict u_upload still thinks the prcs is valid
23:13 karolherbst: ohh it should have a refcnt=1 in any case.. I'm sure
23:13 karolherbst: robclark: drivers must not drop refs on those objects
23:14 robclark: it is created with refcnt=1.. so I'm still trying to figure out that part.. at least the $new_shenanigans confuses the refcnt debug stuff
23:14 robclark: but driver is dropping a refcnt it obtained
23:14 karolherbst: well it shouldn't
23:15 robclark: if those are the rules, zmike MR should have fixed all the drivers ;-)
23:15 karolherbst: yeah
23:15 karolherbst: he should
23:15 robclark: cause that defn wasn't how it worked before
23:15 karolherbst: anyway.. zink doesn't icnrease the ref on e.g. ubos
23:16 karolherbst: nor does it drop it
23:16 karolherbst: the point was to get rid of the ref counting dances, because atomics are apparently expensive on certain CPUs
23:16 robclark: breaking every driver that isn't zink isn't cool
23:17 karolherbst: yeah.. and I had to deal with some regressions myself
23:17 karolherbst: anyway.. I think we should document those semantics more explicitly so everybody knows what's p
23:17 karolherbst: *up
23:19 karolherbst: We should have gallium validation layers, that make sure everything is sound, but... :P