00:00 demarchi: q66: can you send this patch to the i915/xe mailing lists? https://github.com/chimera-linux/cports/blob/master/main/linux-stable/patches/xe-nonx86.patch
00:01 demarchi: q66: probably with a s/defined(CONFIG/IS_ENABLED(CONFIG/
00:19 q66: demarchi: it's not my patch though
03:30 soreau: does glReadPixels sync like glFinish before reading the buffer?
03:55 mareko: yes
03:56 mareko: if the buffer is idle and linear, then no
04:12 soreau: I'm not sure what you mean by the latter, but the former answers the question(?)
05:35 mareko: if the buffer is not being used by the GPU, there is no wait
05:36 soreau: but the guarantee is there that it won't read a buffer that is unfinished, i.e. former gl calls have not been applied
05:39 soreau: sounds almost like an undocumented sync point, but that would explain the behavior I'm seeing
07:53 MrCooper: soreau: why "undocumented"? Pretty sure the spec clearly says ReadPixels captures the effect of previous commands
08:07 DemiMarie: alyssa: Please do not include any static destructors. They cause use-after-destroy in multi-threaded programs that try to exit normally.
08:12 mripard: sima: your help is needed for a bit of KMS archeology https://lore.kernel.org/all/w6hoxhwyrp44e6yqelxe5qtlyq643bvynmqrwzybuflhb7lkvu@bmsy3losd6t4/ :)
08:15 sima: mripard, it's a fun one, will reply
08:37 HdkR: static constructors and destructors are a battle I fight far too often, and I'm the one adding them. gaah
11:31 emersion: pq, i've started reviewing the drm_colorop stuff
11:33 emersion: i don't know HDR well, so let me know if you've been reading the replies and i missed anything
11:34 sima: mripard, dropped some replies
11:35 soreau: MrCooper: what spec are you reading? the usual user-facing docs don't mention it for glReadPixels AFAICT
11:38 MrCooper: the GL spec
11:40 MrCooper: I mean, if it wasn't the case, every non-PBO glReadPixels caller without preceding glFinish would be broken, that's pretty much every one I've seen
11:41 mripard: sima: awesome, thanks
11:51 soreau: MrCooper: idk, skimming the 4.6 spec around ReadPixels doesn't seem to say anything explicit either (not disagreeing with you that drivers don't sync, just that it's not well documented, if at all)
12:43 phasta: I just saw that discussion with DRM maintainers and Greg about cherry picking fixes commits
12:43 phasta: Soooooo. I don't have expertise on this. Why are we doing that in DRM?
12:43 phasta: When fixing sth, why can't we just send it to Linus with Cc stable and Fixes: and Greg will do the backporting?
12:44 mripard: because, sometimes, we get it wrong
12:44 mripard: and a patch that was initially merged in -next turned out to be needed in -fixes
12:45 phasta: Hmm. But that must be a general problem in the kernel, no? Isn't there a process for that?
12:45 mripard: most of the other maintainers rebase their trees
12:46 mripard: so in such a case, they would drop it from their next branch, and apply it again as a fix
12:46 phasta: Ah alright. And we're too big for that
12:46 mripard: we have so many people committing on the trees that rebasing the trees isn't something we can do, really
12:47 sima: phasta, not so much too big, but we have committers and you can't rebase branches when more than 2-3 people touch it
12:47 sima: phasta, the other part is also that developers just want to push their work to the main branch, and figuring out where a bugfix needs to go is sometimes tricky
12:47 phasta: I assume it has been discussed in the past to make DRM More hierarchical, with many independent subbranches that actively get merged into drm-xy-zz?
12:47 sima: so for the drm-intel tree with paid maintainers, we cherry-pick _all_ bugfixes
12:48 sima: because that's easier for committers
12:48 sima: phasta, it's a pile of paperwork to make that happen, and like any other subsystem we lack volunteers
12:48 mripard: phasta: that was pretty much how early drm-misc looked like
12:48 sima: so instead of trying to pull of the impossible, we've adjusted the process to not be so much busy work for maintainers
12:49 sima: there's also all the cross-branch coordination pain you have with lots of tiny branches
12:50 phasta: I see
12:54 sima: phasta, https://blog.ffwll.ch/2017/01/maintainers-dont-scale.html blog length rant on why that very hierarchical model is pain
12:58 phasta: will read – still, that's exactly what Linus is doing, just at smaller scale
12:59 sima: phasta, what do you mean with that here?
13:00 phasta: sima, Linus has subsystems below him, and those subsystems often have dedicated driver maintainers with their own branches. So it's the same model, many branches, and they all merge at Linus, with merge conflicts and all those problems
13:01 sima: phasta, yeah eventually a single tree gets too messy and different trees make sense. we still have some within drm, just a lot less
13:01 javierm: phasta: there's also the fact that cross-kernel changes are less common I would say that cross-subsystem changes
13:02 sima: or at least they're happening more gradually/slower
13:02 sima: within a subsystem it's just nice when you can just land a refactor in one go and done
13:02 javierm: phasta: when those occur, the inter trees coordination is painful. Need topic branches and so on
13:03 sima: but if you touch too many trees that becomes impossible, and you need to do it in stages: 1 land new uapi 2 push refactoring into all separate trees 3. wait for a full release for everything to converge 4. delete old uapi
13:03 javierm: sima: yeah, or as mentioned ask for topic branches that can be merged in all the other trees but that's painful to coordinate
13:03 phasta: Yes, touching APIs across the kernel is also painful
13:03 sima: javierm, topic branches only work for smaller stuff, ime they have limits
13:04 javierm: sima: yeah, agreed
13:04 sima: like adding the new uapi can be done with topic branch often, otherwise you need to already wait a full cycle between 1 and 2
13:05 sima: and for really big stuff you get to repeat 2/3 a few times because new users of the old uapi keep cropping up
13:05 sima: it's just a lot of pain all around
13:06 javierm: sima: yeah, the .i2c_probe_new work from Uwe comes to mind. It took 6 years to replace everything and 606 patches only to remove the old users
13:06 javierm: https://patchwork.kernel.org/project/chrome-platform/cover/20221118224540.619276-1-uwe@kleine-koenig.org/
13:07 javierm: s/remove/convert
13:07 javierm: a change like that in drm can be done with a single patch and merging it is trivial once you get all the acks
13:23 mlankhorst: So it seems initially drm_client_modeset_probe correctly detects the tiles and offsets, and in second pass just ignores the offset. :s
13:46 sima: mlankhorst, would probably also need some minimal atomic retry to try with fewer crtc, since multi crtc constraints kinda regressed with conversion to atomic
13:47 sima: or at least I thought you get black screen now if the config with all crtc doesn't work
13:47 sima: otoh before you got black screeen sometimes due to crtc-by-crtc switching on vt switch
13:48 mlankhorst: It works, I just run into a detection issue
13:49 mlankhorst: I have a tiled display on DP-MST, with DP-0.8 and DP-0.9, DP-0.9 is the primary screen, DP-0.8 the secondary
13:50 mlankhorst: DP-0.8 needs to be set to the offset at 1920, but the offsets are not set correctly when not using the fallback code
13:51 sima: mlankhorst, oh I more meant when you have even more displays and run into clock/bw and other sharing issues
13:52 mlankhorst: Sorry, just a boring 4k tiled display. :-)
13:54 mlankhorst: https://paste.debian.net/1345481/
13:55 sima: hm yeah looks like it gets lost
13:58 alyssa: jenatali: will give that a try, thanks :)
13:58 alyssa: more code than attrib((constructor)) I think, though
13:59 alyssa: but portability counts :)
14:08 mlankhorst: On a positive note, I can now debug very easily my own machine.
14:14 mlankhorst: sima: https://paste.debian.net/1345482/ ? Not sure since it has some fallback non-tiled code too
14:14 mlankhorst: but it works for me(TM)
14:20 alyssa: jenatali: works great, thanks
14:20 jenatali: 👍
14:20 alyssa: technically less code, thanks :p
14:20 alyssa: +17 -18
14:22 glehmann: looks like marge is broken? https://gitlab.freedesktop.org/mesa/mesa/-/jobs/69457009
14:25 glehmann: jenatali: ^ given that this is a msvc job
14:26 tzimmermann: i have a one-liner for bochs: https://patchwork.freedesktop.org/patch/630844/?series=142702&rev=2 could someone please review?
14:26 jenatali: alatiera: ^^
14:26 jenatali: glehmann: MS folks only maintain one of the Windows runners, the others are maintained by gstreamer
14:29 jenatali: Might have been a one-off or one of the runners might be having issues. Re-run picked a different runner and passed
14:32 glehmann: not a one-off, it also caused https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33031 to fail
14:35 mlankhorst: https://lists.freedesktop.org/archives/dri-devel/2025-January/486236.html for tiled display fixes
14:36 jenatali: glehmann: yeah seems gst-htz-5-windows-shell is unhealthy
14:38 jenatali: Pinged in #freedesktop
14:45 jenatali: glehmann: that runner should be paused now
14:45 glehmann: thanks
15:49 chaos_princess: hi all. how do dri drivers that have bridges deal with someone unloading the bridge or panel drivers? i seem to be unable to find the right callbacks for "your bridge just got yanked out"
15:51 mripard: chaos_princess: poorly
15:52 mripard: chaos_princess: bridge module unloading triggers use-after-free really easily at the moment
15:52 mripard: (and panels are in the same situation)
15:53 chaos_princess: i am trying to submit a new driver, and got review feedback to the effect of "what if someone unloads your mipi bridge or panel".
15:53 mripard: we're working on both at the moment, but we're not yet at the "please be nice and signal when you go away phase", we're at the "please please please don't crash" phase :)
15:54 mripard: do you have a link to that review?
15:54 chaos_princess: and, like, ok, technically possible, but 1. why, and 2. i guess you will power down relevant hardware, and when you insmod the driver again, you will get a serror
15:55 chaos_princess: https://lore.kernel.org/asahi/20250114-adpdrm-v4-3-e9b5260a39f1@gmail.com/T/#u - ctrl+f for "https://lore.kernel.org/asahi/20250114-adpdrm-v4-3-e9b5260a39f1@gmail.com/T/#u"
15:55 chaos_princess: * for "What happens if the MIPI driver is unbound"
16:24 alyssa: jenatali: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33067 as discussed
16:39 jenatali: alyssa: I like the foundational work for sure. I'm a *little* hesitant on adding global constructors/destructors for registration but happy to defer that discussion to the next MR
16:55 demarchi: q66: whose patch is that?
17:39 pq: emersion, appreciated. Since drm_colorop all about exposing hardware capability, it doesn't matter much if the operations "make sense". The most important part is that they are unambiguously defined.
17:45 rodrigovivi: sima: airlied: about "drm: Introduce device wedged event"... our user space components don't have daemons to keep listening to the udev events... and udev events seems more for admins creating their own scripts or distros to take some action... so, the question is, should we really require the regular open source upstream consumer to get them in, or could be like sysfs is for admins only in many cases?
17:46 sima: rodrigovivi, I still think some demo script that shows this can be integrated or used in production would be good, just to show we didn't design unusable uapi
17:46 sima: doesn't need to be much, I agree with that
17:46 zamundaaa[m]: rodrigovivi: compositors do use udev events
17:47 sima: but if we built this and then later on some management middleware thing tries to use it and balks, it's kinda awkward
17:47 rodrigovivi: yeap, because many different kind of actions could be taken when the device is declared wedged... I didn't want to put a hard rule in the compositor
17:47 sima: I mean if you get a compositor to use this to drive its fallback to sw rendering or something, that'd be epic
17:48 sima: for this one I don't think we need quite that much
17:48 sima: but should be more than a bunch of igt
17:48 rodrigovivi: hmm.. I like that idea very much indeed...
17:53 demarchi: rodrigovivi: I think we did that impl basing it on the sysadmin need, but there are other possible uses... example... (?) the integration with userspace drivers ( slide 10 of https://www.youtube.com/watch?v=qpBLju1l9_w @ 5:34)
17:57 sima: demarchi, userspace driver would probably need a drm_event, not udev event
17:57 sima: so yeah if umd needs this itself, it defo needs real userspace since I don't think the uevent works :-)
17:58 zamundaaa[m]: sima: hmm, that epic example isn't actually that far out
17:59 zamundaaa[m]: I just tested it, and with some minor adjustments to clean things up (like the linux-dmabuf Wayland global), it would work fine in KWin
18:00 sima: zamundaaa[m], dump it into an mr, make rodrigovivi really happy?
18:01 sima: or directly put an "ack, this works, here's the link to the code" reply onto that patch
18:03 zamundaaa[m]: will do
18:03 demarchi: zamundaaa[m]: that would be awesome, thanks
18:16 alyssa: jenatali: I mean I don't love it but... I don't really see an alternative
18:17 jenatali: alyssa: Explicit registration like how it's staged in your current MR?
18:18 jenatali: I guess, I don't know what the bindgen stuff will look like so I don't know how well that would work, but it seems feasible for each generated file to define an exported register/unregister instead of constructore/destructor
18:18 alyssa: the problem is, who calls the explicit callers
18:18 alyssa: s/callers/functions/
18:18 jenatali: Whoever's responsible for compiler init/deinit?
18:18 jenatali: I.e. for GL put it in mesa/st and for VK it's in the driver
18:19 alyssa: I don't think that really works
18:19 alyssa: it's an n:m problem
18:20 alyssa: like it would work "for now" but long-term we'll have many CL libraries across the tree, some for drivers, some common code, some for frontends
18:20 alyssa: and the latter can be used for various combinations of drivers / APIs
18:20 alyssa: it's not feasible for the driver to enumerate every library it might use - using CL in a common NIR pass should be an impl detail
18:20 soreau: is there a way to simulate a gpu reset in llvmpipe?
18:21 jenatali: IMO the right choice is for each component to have an init/uninit. E.g. if a common NIR pass happens to use CL then NIR (or that pass) needs an init/uninit
18:21 alyssa: can't do it in the frontend because there are driver libs (maybe even more than 1, if gl/vk get split out between a vendor. arguably asahi should probably have 3)
18:21 jenatali: Like how the GLSL type singleton requires callers to init/uninit
18:21 alyssa: yeah and I *hate* hate hate hate the glsl type singleton :p
18:21 alyssa: ("so why'd you go and copy it?" "*sigh*")
18:21 jenatali: :)
18:22 zamundaaa[m]: soreau: I don't think there is, but that would be very cool
18:22 alyssa: The mental model with vtn_bindgen2 is that it's just nir_builder
18:22 zamundaaa[m]: Testing GPU resets by manually triggering amdgpu to do GPU resets again and again isn't exactly awesome
18:22 alyssa: whether the nir_builder is being done by hand or targeted from CL (or potentially GLSL?) is an impl detail, the caller shouldn't have to care
18:23 jenatali: Sure. But if the nir_builder has printfs in it then the caller might have to care
18:23 jenatali: Source doesn't matter, contents matter
18:23 soreau: zamundaaa[m]: that's what I've been thinking this whole time, while not implementing gpu reset event handling
18:23 alyssa: It has to care in the sense of "handling printfs" but shouldn't in the sense of "enumerating every place it might get format strings from"
18:24 alyssa: If we really can't do global ctor, the next best would be meson tricks to accumulate all the defiitions across the tree or something like that
18:25 jenatali: FWIW I'm not going to hard block it, I just want to make sure that it's really the right tool for the job
18:25 alyssa: *nod*
18:25 jenatali: If there's other options I want to make sure we explored those first
18:25 soreau: zamundaaa[m]: I suppose you could just fire the event on a compositor trigger to test with any driver, and then if it works, test 'for real' (since that's eventually unavoidable)
18:25 jenatali: DllMain bugs are awful to try to debug
18:25 alyssa: right..
18:26 alyssa: The other viable option is embedding the format string in the nir itself - not as a sideband in nir->printf_info, but as actual nir instructions
18:26 jenatali: I'd take global ctors over that :)
18:26 alyssa: ...Fair :p
18:27 alyssa: It's really about the programming model
18:27 alyssa: the original sin here is format-strings being a sideband in NIR instead of first class
18:28 alyssa: all of the resulting dominos of nonsense (ending with global ctors) is just a consequence of marrying that sketchy design with the programming model of "self-contained nir_builder functions that Just Work"
18:28 zamundaaa[m]: soreau: you can, but that misses all the fun real world bugs
18:28 alyssa: (and like, everything else in NIR is fine here, it's just printfs that are uniquely screwed up such that the serialized NIR function impl does not actually tell you what the function does)
18:29 alyssa: (nir->xfb_info is pretty bad too but not relevant here)
18:29 jenatali: Yeah, fair
18:30 alyssa: although now i'm wondering if there's a cleaner solution where the gpu binaries are still writing hashes (not whole strings) but the whole string is embedded as a nir intrinsic or something
18:30 alyssa: actually that doesn't solve my problem nvm
18:31 jenatali: There's the nir_debug_info intrinsics which have strings
18:31 jenatali: You could make the printf take an SSA value instead of a hash, and then embed the (hash, string) in a printf_string intrinsic
18:31 alyssa: wait that doesn't solve my problem though :/
18:31 alyssa: because of disk caching
18:32 alyssa: (would require backend special casing if the string isn't going into the binary proper)
18:32 alyssa: (which is very much Not Better than the alternatives I think)
18:32 jenatali: Oh because you need to process the format string without walking the nir?
18:32 alyssa: right
18:32 jenatali: Yeah. Hard problem for sure
18:33 alyssa: for the use case of "used a bindgen'd printf when compiling an app shader, that saved to disk, a week later we load the shader back and hit the printf instruction but we don't know what the hash is from"
18:36 alyssa: hmm.... but maybe I *can* solve this with Meson shenanigans
18:36 alyssa: currently bindgen'ing is happening in the leaves of the tree (e.g. in each driver's independent meson.build)
18:37 alyssa: but I guess we could invert that and do all the bindgen for the tree at root-level
18:37 alyssa: which is a little ugly but afaik legal
18:37 alyssa: and then we can easily aggregate all boundgen-things across the tree at a meson level
18:38 alyssa: and at that point I'm ... not even sure if we need the singleton tricks, since it all becomes static
18:38 alyssa: dcbaker: are you around? this is out of my wheelbarrow
18:40 alyssa: (if we're going to do it this way we should probably pivot now since it would render much of the code in that MR redundant)
18:42 daniels: if all you want to do is aggregate, then put generated_nir_progs = [] at the root level, have every leaf do e.g. generated_nir_progs += libagx_h in its own meson.build, then at the end you have a fully-populated array of targets
18:42 alyssa: daniels: that might be the way to go.. I'm trying to figure out where "the end" would be, though
18:43 alyssa: I guess I should just try that and find out what blows up :p
18:43 alyssa: thanks
18:44 daniels: at the bottom of src/meson.build, where subdir('tool') is, you'll have processed all other src/ subdirectories, so the array will be as full as it's ever going to be
18:46 daniels: then probably what you want is subdir('src/compiler/nir/prinwtf') or whatever, and do whatever it is you're trying to do in src/compiler/nir/prinwtf/meson.build
18:46 alyssa: nice 'typo' XD
18:48 alyssa: the complication there is that prinwtf/meson.build would spit out an object file which needs to link with every relevant .so in mesa ... except all those .so's were from all the subdirs above
18:48 daniels: that's fine, it's a global namespace
18:49 daniels: so libagx = shared_library(...) in src/asahi/libagx/meson.build will be available to any other meson.build, provided it's sourced later
18:50 alyssa: the problem is in the other direction... prinwtf/meson.build would be declaring `libwtf = shared_library(..)` and then {libgallium_dri.so, libpanvk.so, ...} all need to link with libwtf.so
18:51 alyssa: except libwtf hasn't been declared yet becuase it depends on all those drivers' subdirs
18:51 alyssa: it's cyclic at a meson.build level (even though the actual data flow isn't cyclic - I don't think meson can break that cycle itself)
18:57 daniels: yeah, in that case you'd need to have src/ include compiler/wtf/, then have compiler/wtf/ include src/asahi/wtf/ + src/panfrost/wtf/ + ... and use that to build libwtf, then have everything later link with libwtf
18:58 alyssa: mmmh right
18:59 alyssa: and then the added spice I'm now seeing is that our (intel, asahi, and mary's MR for pan) spv's are depending on generated source files from genxml
18:59 alyssa: which causes heartburn for both directions of meson tricks
18:59 alyssa: maybe the global ctor isn't so bad ;-;
19:00 daniels: do the genxml in wtf and then they'll be available to the driver build later
19:01 daniels: ('later' in the sense of, the meson.build is parsed via a subdir() call occurring afterwards)
19:02 alyssa: that should work ... i'm trying to figure out if we're actually better off at that point.
19:02 alyssa: will mull on this
19:03 alyssa: thanks for the input :}
19:11 daniels: np
19:24 pixelcluster: mlankhorst: regarding the dmem fix, the general issue happens whenever you have a cgroup that doesn't have a pool that's part of the pool hierarchy we're currently traversing (simplest case would probably be a cgroup with no pools) - that cgroup must also have at least one child
19:26 pixelcluster: hope that's somewhat understandable? hard to put into words but I'm not sure I have enough ascii art skills to visualize it either :S
19:31 mlankhorst: so basically cg1/cg1_1,cg1_2 and evicting from cg1_2?
19:31 mlankhorst: and then what is the failure with cg1_1?
19:32 mlankhorst: * XE_BO_FLAG_SCANOUT should ideally be set at creation, or is
19:32 mlankhorst: * automatically set when creating FB. We cannot change caching
19:32 mlankhorst: * mode when the boect is VM_BINDed, so we can only set
19:32 mlankhorst: * coherency with display when unbound.
19:32 mlankhorst: oops
19:32 mlankhorst: https://patchwork.freedesktop.org/patch/632661/?series=143593&rev=1
19:32 mlankhorst: I meant
21:10 dcbaker: hakzsam: looks like https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33042 is good to go?
21:37 hakzsam: dcbaker: yes
21:38 dcbaker: Sweet, its on the marge queue and will be the last thing in the release today
21:59 pixelcluster: mlankhorst: more like cg1/(cg1_1/cg1_1_1),cg1_2, then evicting from cg1_2; cg1_1 (and by consequence cg1_1_1) would be the cgroups that have zero pools (or only unrelated ones)
22:02 pixelcluster: the issue is that, when iterating over cg1_1's pools, we overwrite our "current pool" variable (that's "pool" in code) - the next loop iteration we'll descend down the hierarchy to cg1_1_1, at which point we'll set the "current parent pool" variable ("parent_pool" in code) to the value of the "current pool"
22:03 pixelcluster: but we just overwrote "current pool" with some completely unrelated pool (or didn't overwrite it at all...)
22:05 pixelcluster: so in the end we'll traverse some pools that are completely unrelated to the ones we started with, or something like that