05:55 javierm: tzimmermann: got it. Thanks for the clarification
05:57 K900: I'm sorry to once again bump https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33890
06:32 tzimmermann: javierm, better don't ask me about this
07:17 daniels: K900: how urgent is it that you’re in here asking every day for someone to review and merge it?
07:17 daniels: no-one’s forgotten, it’s just not at the top of everyone’s to-do list
07:18 K900: Sorry, I will stop
07:36 mlankhorst: tzimmermann, mripard: Looks like it's my turn on drm-misc-next again?
07:37 tzimmermann: mlankhorst, i'll take over drm-misc-fixes this week
07:38 tzimmermann: drm-misc-next is yours
13:20 mlankhorst: I even compile tested against x86 and arm this time!
13:21 mlankhorst: mostly because it would be emberassing if it broke again
13:48 alyssa: now that the kernel is merged, would be great to get formal acks (and not just rocketship emoji reacts :P) on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33984
13:48 alyssa: thanks ^^
13:48 alyssa: eric_engestrom: ^
13:49 zmike: added my rocket
13:50 alyssa: zmike: appreciate it
13:50 zmike: sorry for tardiness
13:51 alyssa: all good
13:51 alyssa: you were busy making memes, i get it
13:51 zmike: tbh I haven't had time to make any memes in a long while
14:30 ccr: but what is wrong with rocketship emojis? :( :P
14:45 gfxstrand: Do we have a good and easy way to compile a SPIR-V compute shader? Like if someone attaches a .spv to a bug report?
14:45 pendingchaos: fossilize-synth might be useful
14:48 gfxstrand: Fossilize ERROR: Overlap in descriptor type for binding (2, 0) (was 6, now 7).
14:48 gfxstrand: waaaaa
14:51 gfxstrand: I'm just gonna comment out that check...
14:53 mairacanal: sima, tzimmermann, hey, i've noticed something odd about one of my patches (https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1fe1c66274fb80cc1ac42e0d38917d53adc7d7a3). the code introduced in this commit was reverted in this merge commit
14:53 mairacanal: (https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=91dae758bdb854367bf0811d97acb84e791764d9) last year. was it intentional? i would like to have this commit, otherwise multiple CTS test will be broke
14:57 jani: mairacanal: likely just an accidental botched merge conflict resolution
14:58 jani: mairacanal: it's also possible the conflict resolution came from our shared rerere
14:58 mairacanal: i imagined. can i push the patch again?
14:59 jani: mairacanal: if it's been that long, I think it's preferrable to resend it to the mailing list with an explanation and Fixes: the merge
14:59 jani: it's unfortunate, but sometimes it happens :(
14:59 mairacanal: sure, thanks jani! i'll sent it to the mailing-list again
15:01 gfxstrand: pendingchaos: How do I disable fossilize's crash handler?
15:05 gfxstrand: Hrm... Maybe it's actually Rust that's changed.
15:15 alyssa: robclark: Is there a (security etc) reason we can't expose host GEM handles to the guest?
15:16 alyssa: the "pass resource ID then get the resource by ID to get the handle to stuff into the ioctl" dance is annoying
15:17 alyssa: obviously the host GEM handles won't match guest GEM handles, but if we had both handles in the guest we could at least avoid all the fixups in virglrenderer
15:22 sima: mairacanal, what jani said and yeah with messy history this can happen
15:23 sima: and defo new patch which explains it all and cc: stable since we need to backport I guess?
15:23 sima: mairacanal, also sorry for the mess since this was my merge commit :-/
15:25 sima: mairacanal, I looked a bit at this, no idea how I managed to screw this up
15:37 robclark: alyssa: more of a performance reason than a security reason.. res_id's are created in the guest before gem handles are created in the host. If you used host handles in guest then allocation would be a synchronous round trip. I made that mistake in early iterations of msm nctx
15:39 alyssa: robclark: ugh, ok. yeah, that would do it :/
15:39 alyssa: thanks
15:39 robclark: np
15:40 robclark: would be kinda clever if gem gave us a sane way to have userspace allocated gem handles, I suppose.. but mostly the dance isn't too annoying, and with vm_bind you don't even have to do it that often
15:42 alyssa: yeah, i'm asking in context of needing to fixup vm_bind payloads which is a little invasive
15:42 alyssa: but not a big deal
17:32 jani: sima: it's quite possible you got the resolution from rerere
17:33 jani: sima: i.e. that's your excuse ;D
17:34 sima: yeah but I'm supposed to check these :-/
17:34 jani: you said that, I didn't
17:34 jani: ;)
19:08 mairacanal: sima, np :)
21:17 eric_engestrom: reminder to mesa devs: the 25.1 branchpoint is next wednesday (april 16) :)
21:17 HdkR: \o/
21:18 eric_engestrom: it will happen just after europe lunchtime (I'm going out in the evening), so don't wait until the end of the day ^^
21:18 eric_engestrom: as always, if there are MRs or issues that need to be merged/fixed for 25.1.0 final, please add them to the milestone: https://gitlab.freedesktop.org/mesa/mesa/-/milestones/50
21:18 alyssa: eric_engestrom: I don't usually put anything in the relnotes but perhaps there's something this time..
21:19 alyssa: (:
21:19 eric_engestrom: yeah, I'll mention that asahi has been fully mainlined \o/
21:20 psykose: congrats!
21:20 alyssa: well, in Mesa
21:20 alyssa: still need our kernel :p
21:23 HdkR: Woo!