03:51 hays: when you all are blackbox reversing a GPU driver.... is there a libera channel for that kind of thing? particularly as it generalizes to other related drivers like neural net hardware showing up on some of these SOCs
07:46 MrCooper: karolherbst: CI is a big motivator for moving to gitlab though
09:14 MrCooper: janesma: FYI, pushing to merge-requests/<number>/head doesn't modify the MR source branch
09:48 javierm: jadahl: is there a place were I can read what is needed in the atomic mode settings API to have this "cursor hotspot" support that's needed to remove virt-gpu from mutter's atomic deny list ?
09:49 javierm: jadahl: I know that you already discussed this with Bilal a little bit, but I'm trying to understand what exactly entails
09:51 javierm: jadahl: oh, I see there was a series posted by Zack some time ago: https://lore.kernel.org/all/20220613104529.25fc650a@eldfell/T/
09:56 emersion: javierm: yeah the Zack series was the latest work on this
09:56 emersion: javierm: see in particular the replies by Pekka/Jonas/me
09:57 emersion: i think the consensus from user-space was that we want a cap for user-space to opt-in
09:57 javierm: emersion: yeah, I'm reading the thread now
09:57 javierm: makes sense for user-space to opt-in IMO
10:04 jadahl: that thread is good to read indeed
10:11 javierm: jadahl: indeed I just pointed out to Bilal because it explains in great detail what these cursor hotposts are, I wasn't familiar with that concept
10:11 javierm: emersion: I didn't know that there was a SW fallback
10:11 javierm: then the driver doesn't expose a cursor plane
10:11 emersion: yeah, pretty sure all compositors have this
10:12 javierm: emersion: as Zack mentioned mutter adds it in a deny list. That's how I noticed this, because fixed virtio-gpu to properlty report FB_DAMAGE_CLIPS but didn't work due using the legacy API
10:13 javierm: for now I patched mutter to remove it but of course have issues with the guest cursor
10:13 danvet: javierm, if it's all wired up properly then should work with legacy dirtyfb ioctl too
10:13 javierm: danvet: damage clipping you mean?
10:14 javierm: hmm, but unsure if makes sense to invest in wiring that. I prefer to push Zack's series forward and have atomic mode settings with virtio-gpu :)
10:17 javierm: emersion: I don't fully understand Zack pushback to your proposal, since old user-space will keep using the legacy API anyways...
10:17 javierm: so what could be the drawback of hiding the cursor plane if user-space doesn't opt-in ?
10:18 emersion: i think Zack wants to force all user-space to properly set the cursor plane's hotspot always
10:18 emersion: on atomic
10:20 javierm: emersion: yeah but if you need to modify user-space anyways to set the new mouse cursor hotspot info, then what's the problem with also set the cap ?
10:20 emersion: yup
10:21 emersion: and the cap allows user-space using atomic but not hotspot-aware to display properly
10:21 javierm: emersion: and yeah, SW cursor fallback is slower but at the very least old user-space that doesn't set the cursor hotspot info can do that and have a functional driver
10:21 emersion: indeed, slow better than incorrect
10:21 javierm: so hiding the (broken) cursor plane makes totally sense to me
10:22 emersion: well, glad we all agree :)
10:22 javierm: emersion: it seems Zack doesn't though :) but I haven't finished reading the thread yet
10:22 emersion: i think at the end Zack ended up agreeing somewhat iirc
10:25 javierm: emersion: Ok, let me read the rest and I think Bilal or me can re-spin a v2 with your suggestions and resend
10:25 emersion: nice!
10:29 emersion: swick[m]: \o/ https://a.uguu.se/lTYVZJmv.png
10:29 emersion: this is in the HDMI 2.1 VSDB
10:30 emersion: a bit worried that it's 0 to say "i don't flicker"
10:30 emersion: (so maybe sinks set it incorrectly)
10:30 emersion: but at least it's there
10:33 swick[m]: nice. now we need the same for everything that's not HDMI
10:33 swick[m]: and somehow get manufacturers to actually use it :s
10:34 swick[m]: btw, I'm on PTO right now, back on monday for work
10:37 emersion: swick[m]: maybe we can hope that the HDMI VSDB gets advertised on DP as well?
10:37 emersion: ah, feel free to ignore me then!
10:39 emersion: hrm i didn't capture EDIDs on both DP and HDMI during the hackfest
10:39 emersion: so hard to tell for these displays
10:41 swick[m]: we should probably have done that in hindsight
10:41 emersion: maybe we can ask Carlos to do this for us
10:42 swick[m]: but there are displays without hdmi support and there the vsdp makes no sense
10:42 danvet: javierm, yeah, should be a one-liner to plug in the compat helper
10:42 emersion: yes, i agree it's not a very reliable way to find out
10:42 emersion: maybe i should try to see if DisplayID has anything similar
10:43 javierm: danvet: oh, I'll take a look then
10:43 emersion: but i don't have super high hopes
10:44 swick[m]: edid-decode also tells me there is more vrr stuff in the hdmi vsdb
10:44 swick[m]: Supports media rates below VRRmin (CinemaVRR)
10:44 swick[m]: Supports negative Mvrr values
10:45 emersion: yea i see this in the spec too
10:46 emersion: the spec is kinda hard to read tbh
10:46 emersion: many references to variables defined elsewhere
10:52 danvet: javierm, maybe we should add a warn_once if that isn't set correctly like we have for the missing prop?
10:52 danvet: since atomic drivers really shouldn't hand-roll this I think
10:53 danvet: but maybe i915 is a legit enough exception
10:53 danvet: so maybe could just check that there is a ->dirty callback and not necessarily that it's the default compat helper
10:55 javierm: danvet: Ok, let me dig that I'm not familiar with the legacy KMS compat layer
10:56 danvet: drm_atomic_helper_dirtyfb() but with fbdev generic helper you need to call the different setup func for that iirc
10:57 javierm: danvet: hmm, virtio-gpu already uses it https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/virtio/virtgpu_display.c#L63
10:58 danvet: hm then it should get passed through for legacy kms too
10:58 danvet: maybe mutter hasn't wired that up?
10:59 javierm: danvet: could be, I'll take a look. Bilal asked jadahl (or was Robert Mader?) and pointed out to him about not using the atomic API
10:59 javierm: BilalElmoussaoui[m]: o/
11:06 hch12907: fyi, irc doesn't show Robert and Bilal's messages
11:06 javierm: :(
11:08 hch12907: <karolherbst> "so what's the value discourse..." <- I think fedora wants it because their ML is more forum-y
11:08 emersion: daniels: do you think we could allow unauth users to talk, it doesn't seem like we have had spam from these in #freedesktop?
11:11 hch12907: But even without discourse, gitlab alone is already pretty nice for mesa & drm I think. Discussions can be done using the issue tracker.
11:11 daniels: emersion: sure, let's give it a try and see what happens - as long as we have the Matrix bridge we're always going to have this frigging problem
11:12 emersion: yea :/
11:12 emersion: and lack of SASL on OFTC makes this rather painful
11:12 emersion: at least we don't kick unauth users
11:16 emersion: alright let's see how this goes
11:16 emersion: will revert if we get spam
11:18 BilalElmoussaoui[m]: i guess it should work now?
11:18 emersion: yes
11:18 javierm: BilalElmoussaoui[m]: welcome to this side of the IM tunnel :)
11:19 BilalElmoussaoui[m]: awesome :)
11:19 daniels: emersion: thanks!
11:22 mlankhorst: Do i fast forward drm-misc-fixes to drm/drm-next too?
11:27 karolherbst: MrCooper: sure, but we can do CI later or people will add CI once we are on gitlab and we can discuss in MRs if proposed ideas are good or not
17:48 alyssa: I'm not really sure what's happening with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22695
17:48 alyssa: Got two soft-naks. I don't want to override the objections (because frankly I don't disagree) but I'm not sure where we go from here
17:48 alyssa: and I can't tell if this is stalled on me needing to change the code or others that haven't reviewed it yet
18:18 alyssa: although maybe I do want to do ineg propagation in my backend instead of implementing isub
18:19 alyssa: so then i can drop isubshl_agx at least, and also don't need to introduce imsub
18:19 alyssa: gfxstrand: does NVIDIA have imsub?
18:19 alyssa: and do you care about having that in NIR rather than ingesting imad(x, y, ineg(z)) into your backend?
18:25 DUOLabs[m]: I've been trying to integrate venus into QEMU for MacOS, but when I try to run vkcube, all I get is "stuck in ring seqno wait with iter at". Looking at the source code, it's waiting for something, but I'm not sure what.
18:25 alyssa: oh, woof, apparently I even have (a * b) + (c << #d) in one op
18:26 alyssa: likely sufficiently obscure it's not worth bothering NIR over though
18:26 alyssa: unless maybe it comes up with address arithmetic, which is entirely possible.
18:33 alyssa:writes the neg fusing rules at least
18:33 alyssa: should cut the NIR side combinatorics in half, at least
18:53 alyssa: 6 files changed, 71 insertions(+), 3 deletions(-)
18:53 alyssa: see this is just an obnoxious amount of code needed for something I can do in 2 lines of opt_algebraic :|
18:58 alyssa: IDK. Maybe I want better pattern matching in my backend stuff
18:58 alyssa: Or maybe lots and lots of NIR opcodes really is ok.
20:13 gfxstrand: alyssa: What's imsub?
20:14 gfxstrand: Oh, yeah, ineg is allowed on the src2 of imad
20:14 gfxstrand: I'll figure out how to propagate it somehow.