07:39 pq: Hmm, receiving a massive KMS patch series, it's really hard to see what new UAPI it is actually adding. E.g. no UAPI headers are touched at all, and they don't need to for new KMS properties. Likewise, all UAPI docs are buried in .c files - or is that an indication they don't exist?
07:41 pq: yes, a cover letter has a summary list, but it's a little vague.
08:37 DavidHeidelberg[m]: After Debian CI uprev to 12 passes, I intend to merge, quick reviews are much welcome https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21977
10:44 DavidHeidelberg[m]: I got some feedback from Michel Dänzer, incorporated changes, I'll go to the lunch then I'll merge. It's solidly stress-tested, but I need merged rather sooner than later, because it's huge enough to break with additional MR.
10:45 DavidHeidelberg[m]: In next few days I'll work on making the rebuilding containers and rootfs faster, so more will come soon!
10:48 MrCooper: sounds good, thanks for incorporating my feedback
12:32 DavidHeidelberg[m]: eric_engestrom: can I just merge? For libdrm, I'm preparing whole approach to handle as debian package. You just define git repo + version + add needed patches and it'll build a repository for you
12:32 DavidHeidelberg[m]: so no-one will have to touch Debian packaging and in Mesa3D CI, you'll just install right packages from the repo@commit
12:33 DavidHeidelberg[m]: also you'll be able to install same packages locally on your machine and test
12:35 eric_engestrom: DavidHeidelberg[m]: sure, that sounds like a reasonable solution, as long as you actually manage to do it before the next libdrm uprev is needed 😅
12:36 DavidHeidelberg[m]: this week is fine? :D
12:36 eric_engestrom: feel free to ignore my libdrm & wine comments
12:36 DavidHeidelberg[m]: thanks. I'll move the false -> disabled checks
12:36 eric_engestrom: haha yeah if you think it'll be done that quickly then I have no reservation :)
12:37 DavidHeidelberg[m]: I'm currently as Debian miniconf in Hamburg, so in case I get stuck, I'm sure it'll be question of minutes :D
12:37 eric_engestrom: haha, perfect timing
13:34 shadeslayer: daniels: btw I noticed that a630 reports gpu hangs when running some of the traces on mesa master
14:47 karolherbst: dcbaker: some time to look at my meson PR? I really want to be it part of 1.2 so I only have to bump the version req once: https://github.com/mesonbuild/meson/pull/11733
14:48 dcbaker: karolherbst: yes, I will have a look today!
14:48 karolherbst: cool, thanks!
15:33 eric_engestrom: DavidHeidelberg[m]: would you know how to get ci_run_n_monitor to take a --pipeline instead of trying to guess it? I'm having a need for this again, and last time I had a look I got lost and gave up
15:34 eric_engestrom: (the guess behaviour works in the common use case, so we should keep it, but also allow the user to specify one)
15:35 karolherbst: I was thinking about it a bit, and I decided that we probably want to have some "Rust update policy" writeup distributions can and will rely on. If you have some thoughts please chime in and comment on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23110/diffs?commit_id=f7a3a2a66ee7a74104fc5ab95be379a38b3afce8
15:39 DavidHeidelberg[m]: eric_engestrom: check `bin/ci/gitlab_common.py` lines 37, in general we could optionally pass pipeline there possibly
15:45 eric_engestrom: DavidHeidelberg[m]: thanks!
15:46 eric_engestrom: btw my use case this time is that I'm running a pipeline in someone else's fork
15:47 robclark: pq: for kms atomic prop new uapi, there should be some .rst
15:55 emersion: robclark: right, but burried in a .c file comment
15:56 emersion: i wish these were extracted to a proper .rst file, and made so one can link to a particular one
16:03 robclark: emersion: hmm, wasn't there a giant table of properties in .rst.. or did that change when I wasn't looking
16:03 emersion: the big table is for (some) legacy properties
16:04 robclark: ahh, it's csv now..
16:04 robclark: but tbh, I'm surprised we don't require central documentation of all new props
16:05 robclark: sima: ^^^
16:08 sima: robclark, uh you want to scroll up on that
16:08 sima: https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#existing-kms-properties
16:08 sima: or well in the generated docs at least
16:08 sima: "Because this table is very unwieldy, do not add any new properties here. Instead document them in a section above."
16:10 sima: emersion, do you mean link to a specific property instead of just the section?
16:10 emersion: yea
16:10 robclark: hmm.. but just having them documented in code means there aren't some files to filter on to look for new properties, which is I think what emersion was looking for
16:10 sima: hm ... not sure how to do that
16:10 sima: robclark, yeah it's not super great
16:10 emersion: just use a regular heading instead of the weird <b>
16:10 sima: :-/
16:11 sima: emersion, headings in inlined C comments get funny when the nesting is wrong
16:11 sima: iirc
16:11 emersion: sima, would you mind if the prop docs were not in .c files?
16:11 emersion: but in a proper .rst?
16:11 robclark: heh.. if we had CI we could do something like write a test that fails if any new prop added what isn't also listed in an allowlist.txt type thing
16:11 sima: the .c comments are proper .rst, just funny inline directives
16:11 robclark: s/what/which/
16:12 emersion: i mean a separate .rst file
16:12 sima: for ioctl v4l has some validator, but the problem is it's pretty hard to programmatically detect prop names
16:12 emersion: i do parse the existing docs to display them on drmdb
16:12 emersion: but it's horrible
16:12 sima: emersion, ime pulling docs out of .c files means developers ignore them even harder than now
16:13 sima: and as long as we don't have dedicated doc wranglers, that's probably worse
16:13 emersion: i'd say 30% worse than the parsing of formats and modifiers from drm_fourcc.h i'm doing
16:13 sima: but we can change the formatting to something that's beter
16:13 sima: emersion, uh can't you pull it out of the rst?
16:13 emersion: sima, the prop docs are scattered in random .c files atm
16:13 sima: sphinx parses it as an entire rst before it's actually generating the output
16:14 sima: not sure whether there's a good way to dump that intermediate step though
16:14 sima: parsing .c directly is indeed a bit much lol
16:14 emersion: i don't really want to run any of the kernel's build when doing that
16:14 emersion: i don't even have a full kernel checkout
16:14 sima: emersion, could you at least reuse the kerneldoc parser?
16:14 sima: that should give you the .rst (without headings)
16:14 sima: and then it's just rst parsing
16:15 sima: but yeah if you want to build your own .rst kerneldoc parser I guess you get to keep the pieces :-)
16:16 sima: hawkdoc from jani might be compatible enough if the kerneldoc one is too horrible
16:16 emersion: well, w/e i just give people linkds to drmdb instead of kernel docs now
16:16 emersion: links*
16:16 sima: emersion, another option might be to put your parser magic into kerneldoc and generate the output there
16:17 emersion: it's not exactly super complicated, just ugly https://git.sr.ht/~emersion/drmdb/tree/master/item/drmdoc/generate.go#L19
16:17 emersion: also it's already written and works so
16:17 sima: yeah imo totally fine to link people to drmdb
16:17 sima: the overview is neat
16:20 sima: emersion, do you also take downstream trees for drmdb?
16:20 sima: some of the props look really funky
16:20 emersion: yeah, people submit snapshots from various trees
16:20 emersion: see the kernel version
16:21 emersion: not sure how to reliably detect downstream vs. upstream
16:21 sima: I guess a "upstream documented" flag would be useful in the overview table
16:21 sima: ^^
16:21 emersion: right
16:21 sima: if it's not documented it's probably one of the old driver specific ones that you don't want to use in new generic compositor code
16:22 sima: maybe with a comment that upstream documented should mean consistent semantics across upstream drivers, good for use in generic compositors
16:58 linkmauve: When DRM_CAP_CURSOR_WIDTH and DRM_CAP_CURSOR_HEIGHT are defined, wouldn’t it make sense to also have the cursor planes set the maximum size of CRTC_W and CRTC_H to it instead of INT32_MAX?
17:05 emersion: these caps aren't always the max
17:05 emersion: they're just a good™ size
17:05 emersion: on i915 they're the max, on other platforms they're not
17:06 linkmauve: Oh, ugh.
17:07 linkmauve: Why did other platforms just use it as a hint?
17:07 linkmauve: It makes it pretty much useless.
17:07 emersion: user-space needs a hint
17:07 emersion: ville had a series to improve this
17:08 emersion: advertise multiple sizes, indicate when there are no size constraints
17:46 agd5f_: linkmauve, when the CAP was added, we had hardware that didn't support 64x64 cursors and everything assumed that so we need some way to convey what size the hardware actually supported
17:48 agd5f_: IIRC, the AMD hardware at the time had a min size of 128x128 IIRC. There was also some ARM SoCs that only supports 32x64 cursors
17:50 linkmauve: But in that case, couldn’t the plane set the property to "CRTC_W" (atomic): range [128, INT32_MAX] = 0 or something?
17:50 linkmauve: And [32, 32] in the case of that ARM SoC.
17:50 linkmauve: Can they still do scaling in that case?
17:54 linkmauve: emersion, it seems drmdb only handles one of the two cards of my drm_info: https://drmdb.emersion.fr/snapshots/00609be6f033
17:54 emersion: cards would show up separately
17:54 linkmauve: The JSON I just uploaded also contains the tegra device, this is only the nouveau one.
17:55 linkmauve: Oh, then perhaps it’s the reply to curl which doesn’t give both pages?
17:55 emersion: drmdb prints one URL per node
17:55 emersion: then "Thanks!" at the end
17:56 linkmauve: Ah!
17:56 linkmauve: /dev/dri/card1: error: device bus type host1x not supported
17:56 emersion: ah, interesting
17:57 linkmauve: Perhaps I did something wrong in my kernel, it is a forward port from the 4.9 Linux4Tegra to 6.0.
17:58 emersion: this bus type is not handled by drmdb atm
17:59 emersion: i am unfamiliar with host1x, can i just use the "compatible" string array to tell two devices apart?
18:01 linkmauve: device_data is null in the tegra platform, so no compatible either; perhaps I should add one in the dtb?
18:01 emersion: hrm, drm_info doesn't seem to populate this atm
18:01 emersion: https://gitlab.freedesktop.org/emersion/drm_info/-/blob/master/json.c#L119
18:02 emersion: i just thought it was an obscure bus type that nobody uses lol
18:03 linkmauve: It is used only by that one vendor it seems: https://www.kernel.org/doc/html/latest/gpu/tegra.html
18:04 emersion: sigh, did we really need a whole bus type for this…
18:04 emersion: well, anyways, feel free to send patches for drm_info, if you have the time
18:04 HdkR: Considering it is only on Tegra, one could say it actually is obscure :)
18:05 emersion: should be copy/paste of platform mostly
18:06 linkmauve: I’ll try adding a compatible string to my dts, perhaps nvidia,tegra210-host1x or something?
18:07 linkmauve: Hmm, but almost none of the existing dts for tegra platforms do that…
18:08 emersion: so you mean the device tree leaves host1x compatible to NULL?
18:19 linkmauve: Even if I set a compatible string it doesn’t get displayed in drm_info -j, weird.
18:20 emersion: linkmauve: linked above is the drm_info code, which doesn't support reporting host1x
18:20 dottedmag: w.r.t. plane sizes: there is a display controller (in Apple's M1/M2) with planes that cannot be placed partially offscreen. 1) is there a way to provide a hint about it to userspace? 2) is it useful, or _all_ userspace already assumes that cursor planes can be placed partially offscreen? 3) is it a good idea to "fix" it in driver by clipping and passing the clipped piece to the controller?
18:21 linkmauve: Ah right, I’ll have a look there, thanks. :)
18:21 emersion: dottedmag: (1) no, just a way to reject atomic commits (2) user-space does assume cursor planes can be offscreen partially
18:21 emersion: (3) yeah probably, if you can crop. amd is doing the same kind of thing iirc
18:22 linkmauve: Speaking of which, Weston never places the cursor plane at negative locations even if it means falling back to GL compositing.
18:23 jannau: the overlay (cursor) plane can be partially off-screen but 32 pixels have to remain on-screen horizonatally
18:24 jannau: i.e. this is mostly a problem at the right screen edge
18:25 emersion: hm, that sounds cumbersome
18:25 dottedmag: jannau: and left screen edge for the X root cursor :)
18:25 emersion: maybe allocations matching the cursor size can be padded on the left?
18:29 jannau: not sure how I would enforce the padding if I can guarantee that the plane is allocated via the display kms driver
18:31 emersion: yeah, it'd be super hacky in any case…
18:31 emersion: no user-space is prepared to see the cursor plane fail when moved around
18:31 zamundaaa[m]: emersion: KWin does handle such things
18:32 jannau: s/can/can't/
18:32 emersion: intresting
18:33 zamundaaa[m]: It does an atomic test for any and all cursor updates, and if it fails then KWin disables the plane and falls back to a sw cursor for the next frame
18:33 emersion: wlroots handles drmSetCursor failures, but doesn't fallback to GL when drmMoveCursor fails
18:33 emersion: hm, actually on atomic it's worse for wlroots :/
18:34 emersion: it doesn't expect the cursor plane to fail because of constraints
18:34 jannau: it's probably more efficient if the driver copies, crops and pads the cursor plane if it is too much off-screen than falling back to SW cursors
18:35 jannau: just ugly and annoying
18:40 agd5f_: linkmauve, at the time hw cursors on most hardware had a fixed size, so the CAPs just exposed the size that usespace should use
18:40 agd5f_: i.e., if the cap says 128x128 and you used 64x64, it wouldn't work
18:41 agd5f_: most hw cursors have a fixed stride
18:47 jannau: no hw cursor on the apple display controller, just universal planes with limitations which makes them annoying to use for cursors
18:48 emersion: how many planes?
18:49 jannau: only 2 for blending on all current hw although the interface has 4
18:55 agd5f_: yeah, hw cursors aren't exactly universal planes, at least on our hw. They have ordering and scaling limitations unlike real planes
18:59 jannau: the first plane seems support only the wide gamut 10-bit RGB color space macOS uses: 0.0 at 384 and 1.0 at 895
19:05 linkmauve: emersion, there: https://gitlab.freedesktop.org/emersion/drm_info/-/merge_requests/97
19:25 emersion: linkmauve: ty! so, with that fixed, does the kernel expose a compatible string or is it still empty?
19:40 linkmauve: emersion, it does, it was defined in arch/arm64/boot/dts/nvidia/tegra210.dtsi actually, which I hadn’t read before.
19:40 linkmauve: "device": {
19:40 linkmauve: "available_nodes": 5,
19:40 linkmauve: "bus_type": 3,
19:40 linkmauve: "device_data": {
19:40 linkmauve: "compatible": [
19:40 linkmauve: "nvidia,tegra210-host1x"
19:40 linkmauve: ]
19:40 linkmauve: },
19:40 linkmauve: "bus_data": {
19:40 linkmauve: "fullname": "\/host1x@50000000"
19:40 linkmauve: }
19:40 linkmauve: },
19:40 linkmauve: Oops, I forgot we aren’t on XMPP here.
19:42 emersion: nice!
19:43 emersion: i will update drmdb as well, unless you have time for that
19:44 linkmauve: Feel free to, I still have a bunch of driver porting to do from 4.9 here, plus some more RE for the things we have no driver for yet.
19:46 airlied: mlankhorst: fixes?
19:54 DavidHeidelberg[m]: robclark: Hey! Is the `iommu/arm-smmu-qcom: Fix missing adreno_smmu's` patch still latest solution available (will be doing kernel uprev tomorrow)
19:55 robclark: DavidHeidelberg[m]: I think if you rebase that patch should drop out
19:55 robclark: it should be on ToT already
19:56 DavidHeidelberg[m]: robclark: on 6.3.4? it's still there
19:57 robclark: it should be in drm-fixes.. possibly linus ToT.. not sure about stable branches
19:57 DavidHeidelberg[m]: this is the fix, right? https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.3.4&id=2125d41ae4742d628f91d82555a6a966d6d29454
19:57 robclark: DavidHeidelberg[m]: basically just keep it until at some point in the future it disappears when you rebase
19:57 robclark: yup
19:57 DavidHeidelberg[m]: I guess it just did resolve conflict during rebase and let both commits in. I'm droping the previous then
19:58 robclark: sg
19:58 emersion: linkmauve: should be all good now
19:59 emersion: let me know if it still doesn't work
19:59 DavidHeidelberg[m]: robclark: "drm/msm/a6xx: don't set IO_PGTABLE_QUIRK_ARM_OUTER_WBWA with coherent SMMU" is not there yet
20:00 robclark: I think you might need that one for the a660 runners
20:00 DavidHeidelberg[m]: yeah, we have it in CI repo, just not backported into stable yet
20:01 linkmauve: emersion, thank you, it worked! https://drmdb.emersion.fr/snapshots/8f14da0df2b6
20:02 emersion: nice!
20:13 emersion: oh mutable zpos, nice
20:15 emersion: hm weird the overlay has mutable zpos [0, 255] and cursor has immutable zpos 255
20:15 emersion: the overlay should probably have zpos [0, 254]
20:15 linkmauve: Should probably be [0, 254]?
20:16 linkmauve: This can still be fixed before upstreaming.
20:16 emersion: would be nice :)
20:26 linkmauve: emersion, just checked, my phone also supports mutable zpos: https://drmdb.emersion.fr/snapshots/70ed44106660
20:28 linkmauve: In pretty much the same configuration as the Switch, except YUV formats are only available on one of the two overlay planes, while on the Switch they are available on both.
20:29 linkmauve: And on Intel they are available on both the primary and the overlay.
20:29 linkmauve: On AMD there is no non-primary plane whatsoever.
20:29 linkmauve: And that’s the extent of the hardware I have powered on around me. ^^
20:37 linkmauve: emersion, small suggestion for duplicated uploads, in addition to saying this has already been uploaded you could return the URL of said upload.
20:37 emersion: yeah, would be nice indeed
20:46 linkmauve: Uh, there is a bug in pretty.c, the JSON now says 254 because I modified the driver, but the pretty still says UINT8_MAX.
20:47 linkmauve: But that shouldn’t be possible, hmm…
20:48 linkmauve: Wut, now it’s correct.
20:48 linkmauve: Haha, I was still looking at my previous ssh session, before the reboot. ^^'
20:48 emersion: ahah
20:48 linkmauve: Ok, so that’s now fixed.
20:49 linkmauve: Ah, the 255->254 can already be applied to mainline.
20:55 linkmauve: There, sent to the maintainers and the MLs.
21:13 Hi-Angel: Oh, my Mesa commit marked with "cc: stable" that was merged 6 days ago didn't make it into the 23.1.0 release :c
21:15 karolherbst: Hi-Angel: I think the prober way is "cc: mesa-stable"
21:15 karolherbst: not sure.. maybe stable also works?
21:15 Hi-Angel: karolherbst: right, sorry, it's `Cc: mesa-stable`
21:15 karolherbst: I see both in the log...
21:15 Hi-Angel: I just typed that from the memory
21:15 DavidHeidelberg[m]: karolherbst: I really hope stable works, I recently reviewed some commit with it as OK
21:16 karolherbst: yeah.. I don't know...
21:16 karolherbst: the docs say `Cc: mesa-stable`
21:16 karolherbst: you all might want to double check :D
21:17 karolherbst: mareko: seems like your commit 60a3f0667f7bffcc1667396f3aa1fc891dcba3a0 with Cc: stable, didn't make it into 23.0
21:19 karolherbst: eric_engestrom, dcbaker: seems like some patches are tagged with `Cc: stable`, and it looks like those aren't picked automatically
21:19 dcbaker: yeah, it needs to be mesa-stable IIRC
21:20 dcbaker: eric_engestrom: has some patches to do away with the CC: stable and just have a `stable: X.Y` I think
21:20 dcbaker: or maybe it's backport: X.Y?
21:20 dcbaker: can't remember
21:20 dcbaker: if they're for 23.0 let me know if there's any more shas and I'll get them pulled
21:21 dcbaker: * If there are any more
21:22 karolherbst: 04699cc3aa1c3037b4b6d15f88e5157d31adda1a, 60a3f0667f7bffcc1667396f3aa1fc891dcba3a0, da7dfbe3b85089fa242d076f4e4306431f69b084 are all I think
21:22 karolherbst: there are some patches from last year, but that's all before 23.0
21:23 Hi-Angel: Anyway, my commit 275cf62e is properly tagged as Cc: mesa-stable but didn't make it into 23.1 (which was created 5 days after my commit), so I'm just a bit worried if it will make it into 23.0.4. My friend kind of depends on the fix
21:24 karolherbst: huh...
21:24 karolherbst: 23.1 tagged commit: "Date: Wed May 10 17:48:43 2023 +0100"
21:25 karolherbst: yours is 8 days later
21:25 Hi-Angel: karolherbst: oh… I am sorry, I'm just looking here https://docs.mesa3d.org/relnotes/23.1.0.html and it says the date is 2023-05-23
21:26 karolherbst: ahh yeah.. I think we have some latency on that side
21:26 karolherbst: dunno, but the tag is like 2 weeks old :)
21:26 Hi-Angel: Gotcha
21:43 dj-death: lol
21:43 dj-death: I just noticed some of my commit message have : Part-of: <f{merge_request.web_url}>
21:44 jenatali: Well that's not great
21:46 dj-death: seems to have affect only one MR
22:03 eric_engestrom: Hi-Angel: 🤦
22:03 eric_engestrom: I forgot the docs when I did the 23.1.0 release and tried to backdate them, but clearly I messed up :]
22:04 Hi-Angel: eric_engestrom: mhm?
22:04 Hi-Angel: Oh, I see
22:04 Hi-Angel: No worries, nice that everything cleared up ☺
22:05 eric_engestrom: also, 23.1.1 was supposed to be tonight, but I haven't had time, it'll be tomorrow
22:06 airlied: eric_engestrom: would be good to get the fix from 23221 landed into it
22:06 airlied: since it's a big regression in 23.1
22:07 eric_engestrom: Hi-Angel: 275cf62e is in staging/23.1 and will be in 23.1.1 :)
22:07 Hi-Angel: Nice, thanks!
22:08 eric_engestrom: airlied: ack; marge it by tomorrow morning and i'll make sure I include it
22:08 airlied: mareko: ^ got time to fast track it?
22:09 eric_engestrom: mareko: btw the last commit of that MR isn't tagged for backport; just making sure that's not a mistake :)
22:10 eric_engestrom: (from the commit title it sounds like this was intentional)
22:12 eric_engestrom: dcbaker: thanks for mentioning the backport tag again, I had forgotten about it (again). it's too late for me to look at it tonight but I'll try to remember tomorrow
22:46 daniels: dj-death: yeah, that was the only MR which had that
22:58 Hi-Angel: …as if there's a special case if author == 'dj-death' : break_formatting() 😄