07:16mareko: airlied: lowering bool to int32 breaks other passes, so it should be the last pass
09:17emersion: danvet: "Maybe we should also note that cursors are not necessarily exposed as cursor planes, even for drivers supporting atomic modeset."
09:17emersion: you mean user-space needs to use legacy uAPI for those?
09:18emersion: i didn't know there were atomic drivers not exposing cursors as planes
09:18emersion: or do you mean something else?
09:20emersion: s/atomic modeset/universal planes/ maybe?
09:24danvet: emersion, msm4
09:24danvet: has cursor, has atomic, but the cursor isn't an atomic plane
09:25danvet: I think that's the one exception
09:25emersion: after all nothing stops a driver from doing this…
09:25danvet: emersion, yup :-/
09:26emersion: i wonder if drm core could expose a fake plane for these
09:26emersion: drm core does expose a primary plane for non-atomic drivers right?
10:01danvet: emersion, imo that was a bad idea
10:01danvet: it's very ill-defined
10:01danvet: and definitely not atomic
10:01danvet: we've done it for universal planes only
10:08sravn: danvet: I will be more offline than usual the next couple of months. New house that needs renovation so not much time left for other hobbies
10:09danvet: sravn, no worries
10:09danvet: and have fun renovating :-)
10:10sravn: danvet: 50 years old house, whith limited modernization so I need to break dwon a few wall etc. And then workers to fix it all up again :-)
10:10sravn: pinchartl: ^
10:22pinchartl: sravn: we'll miss you :-)
10:23pinchartl: so you'll do the fun part, hurling the sledgehammer around ? :-)
10:28sravn: pinchartl: Yeah, with a litte bit of help :-)
11:13sumits: hello danvet, mlankhorst_, mripard, tzimmermann: 2nd gentle reminder, could you please pick the current drm-misc-next-fixes for the next pull request to Linus - this will fix a build break with MIPS with dmabuf heaps
11:14danvet: sumits, tzimmermann is out, he said he'll do a pull once per week or so
11:14danvet: I think the entire idea of just letting someone else do it instead of checking once per week wasn't clear enough :-/
11:15danvet: I mean that's why it's a group
11:16sumits: danvet, ok.. just want to make sure a build fix doesn't get missed, that's all :)
11:16danvet: sumits, imo stop worrying, not your problem anymore
11:16sumits: danvet, :) ack
11:17danvet: oh nice doc patches from emersion landed
12:38tanty: tomeu: it will help me a lot if you could give a quick look to this one:
13:04emersion: danvet: is there an easy way to tell whether a driver supports cursors if no cursor plane is exposed?
13:04danvet: emersion, not sure
13:04emersion: also, should i reply to my reviewed patches when i merge them like you do? i've seen you do it
13:05danvet: most folks don't
13:05danvet: some maintainers script this
13:05danvet: ideally we'd just use "this MR is now merged" but hey I can dream :-)
13:06danvet: emersion, I'm not even sure we guarantee that the cursor_width/height properties are set if there's a cursor
13:06danvet: I think you just have to try
13:07emersion: all drivers i've seen expose a non-zero cursor_width/height
13:07danvet: emersion, existence of the ->cursor_set2 or ->cursor_set plus ->cursor_move callbacks indicates cursor support
13:08danvet: or if crtc->cursor is set
13:09emersion: drm core sets CURSOR_WIDTH/HEIGHT to 64 when mode_config.cursor_width/height isn't set
13:10danvet: the cursor client caps seem optional
13:10emersion: client caps?
13:11danvet: I guess we could easily add a DRM_CAP_CURSOR if there's a need for that
13:11danvet: would kinda need to be per-crtc
13:11danvet: so maybe better a property
13:11danvet: that cursor_plane_id prop, which could be -1 if it's legacy-only cursor
13:11danvet: but yeah probably no one asking for that
13:12emersion: my user-space just requires cursor planes
13:12emersion: which isn't great on radeon, but w/e
13:12danvet: I guess we could at least check that if you have crtc->cursor set, then the cursor_set/move callbacks are NULL
13:12danvet: and also that if they're set, they're reasonable
13:13danvet: emersion, you require atomic?
13:13emersion: we don't require atomic
13:15danvet: hm right there's a bunch of drivers which are internally atomic but don't expose it
13:15danvet: at least by default
13:15danvet: (nouveau and early i915)
13:15danvet: otherwise there's not a single driver left that supports universal planes and not atomic
13:16danvet: emersion, imo universal planes without atomic doesn't make sense
13:16danvet: either legacy, or full atomic
13:17emersion: we use the cursor plane to check whether cursors are supported, but then use the legacy ioctls
13:37emersion: why can't i learn to stash properly
14:05zmike: if anyone's around a rb on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8199 would be appreciated
14:10bnieuwenhuizen: zmike: done
14:10zmike: bnieuwenhuizen: 👍 thanks
14:49yshui`: why does mesa pick zink when I set `LIBGL_ALWAYS_SOFTWARE=true` ?
16:09tlwoerner: contributions to mesa are done primarily via pull requests on gitlab? or patches to the mailing list? (or both?)
16:12melissawen: danvet, ivyl: hey, I'm working on adding overlay plane for vkms and I'm looking for an igt test for checking...
16:12melissawen: I found this one: kms_universal_plane
16:12melissawen: that needs some generalization, but ok, I can also check it
16:13melissawen: I wonder if you know another igt test that fits better
16:13melissawen: to check overlay plane
16:15danvet: vsyrjala, mlankhorst_, ^^
16:16danvet: we might get to the point where "just run them all, and make sure skipping is fast enough" is best
16:16danvet: melissawen, one option might be to run all igts, capture results
16:16emersion: there's also igt@kms_plane_multiple
16:17danvet: then enable a 2nd overlay, capture results and compare for anything that now runs
16:17danvet: piglit can compare multiple results pretty ok-ish
16:19melissawen: bu I can just fall into the i915 limitation (I mean, a setup requirement) and do not test anything... no?
16:20danvet: melissawen, we should check for all that in each subtest
16:20danvet: so a lot might still skip
16:21danvet: but often there's subtests that do work fully generically
16:21melissawen: emersion, thankx
16:24melissawen: danvet, ok, I will try this approach too... thanks
16:32tlwoerner: it's weird that gitlab keeps telling me my (incredibly simple) patch needs to be rebased, i rebase and there are no conflicts :-S
16:34jenatali: mareko: Let me know if there's something you want me to take a look at for that test failure. I can reproduce it, but I don't understand it :)
16:34jenatali: mareko: I reproduce it on softpipe too FYI, but not llvmpipe
16:59daniels: tlwoerner: right, it doesn't mean that you need to resolve non-trivial conflicts, it just literally means that what you've pushed is no longer a fast-forward of master, which is fine
17:00daniels: tlwoerner: it will tell you if something is pushed which means a rebase is no longer clean
17:01tlwoerner: daniels: ah okay, thanks :-)
17:02anholt: gitlab-runner updated on the fd-farm machines, as some ui was getting whiny about how out of date it was. lmk if anyone sees anything funny with freedreno tests.
17:28kisak: I just saw impossible vram usage reported in mesa's overlay and a Cayman gpu ... Requested VRAM - 294MB, VRAM Usage - 9.052 GB
17:29kisak: amusing, but harmless
17:48kisak: video card has 1 GB of ram
18:28tlwoerner: daniels: thanks for the merge :-)
18:29tlwoerner: although i'm still curious to know why non-conflicting rebases aren't clean. i haven't seen that in other projects/repositories
19:10jekstrand: airlied: Probably
19:10jekstrand: airlied: Assuming you actually want var arrays in your back-end.
19:10jekstrand: airlied: Also, if you're going into LLVM, I personally wouldn't bother and would leave booleans as they are.
19:15airlied: jekstrand: llvmpipe does bools different than llvm
19:15airlied: so 32-bit ints make more sense
19:16airlied: in the end I jst made the backend reg path handle 1-bit as 32-bit
19:16jekstrand: That works, I guess.
19:24tanty: anholt: of course, it couldn't go completely without some noise ...
19:24tanty: It seems there is some flaky trace for freedreno (?)
19:24anholt: wasn't in the past
19:25tanty: same commit, just different run
19:26tanty: only difference is having several traces running in parallel
19:26tanty: from before
19:27anholt: give it a few more runs, we may have to ban that trace if it's not stable any more :(
21:47Lyude: danvet: in case you're curious what ended up happening with the CRC thing, I found a magic bit that fixes everything. yay
21:48danvet: Lyude, any meaning to that bit, or you just tried them all?
21:51Lyude: danvet: just noticed an option in the state cache (basically the current display hw state on nvidia's hw) that was set by default that wasn't documented (and was therefore getting turned off on accident). turned it on and suddenly we get the right CRCS
21:55Lyude: I have an educated guess on what this actually does though
22:56danvet: Lyude, moar reliable crc, sounds awesome whether guessing or not involved :-)
22:57Lyude: heh-definitely was a very 'educated' guess
23:34daniels: tlwoerner: it's just because we use an ff-only workflow rather than merged
23:38robclark: tlwoerner: usual process is when an MR is ready to merge (reviewed, etc), assign it to marge-bot.. who will do the rebase (if trivial) + CI + ff-merge