08:54 jani: anyone heard of Ashutosh Desai before? am I being too suspicious? https://lore.kernel.org/r/a4f659636fbf9558252197ec3b89ee0dab8290c7@intel.com
10:07 javierm: jani: no, I think you are spot on. A quick search shows me that has also been doing the same for at least net/ and kerne/time/
13:44 CounterPillow: Also curiously absent proper Fixes: tags
13:52 alyssa: "This branch couldn't be merged: Manual Step encountered with run-manual-jobs set to False"
13:52 alyssa: ..that's a new one
13:54 alyssa: robclark: btw https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40853 is waiting for marge's.. review ;)
13:54 glehmann: alyssa: you remove the part-of message from a commit iirc
13:55 robclark: alyssa: heh, fixed.. somehow the gitlab ui makes that annoyingly easy to do
13:56 glehmann: I think it's happening if you changed the commits, the part-of is still there, and the branch is up to date with latest main
13:56 alyssa: glehmann: hmm interesting
13:56 alyssa: well i'll let the turnip thing merge first
13:56 alyssa: and then it should solve magically
13:56 glehmann: basically, marge tries to push but there are no changes, so the script breaks
13:57 alyssa: fun
14:03 sumits: hello! dim/git help requested: I pushed a simple patch to drm-misc-next-fixes (its a single line one, so it shows up correctly on https://cgit.freedesktop.org/drm-misc/log/?h=drm-misc-next-fixes as [dma-buf: fix htmldocs error for dma_buf_attach_revocablefor-linux-nextdrm-misc-next-fixes Sumit Semwal 1 -0/+1]
14:03 sumits: but if I look at the details here (https://cgit.freedesktop.org/drm-misc/commit/?h=drm-misc-next-fixes&id=dc6d51959ec0c08366d5aaeb5b8fb02d814d1e4b) - it shows as deletion of the file itself (
14:03 sumits: -rw-r--r-- drivers/dma-buf/dma-buf.c 1848 )
14:04 sumits: wierdly, if I look at the same patch automerged here https://cgit.freedesktop.org/drm-misc/log/?h=for-linux-next, it shows up correctly: (https://cgit.freedesktop.org/drm-misc/commit/?h=for-linux-next&id=dc6d51959ec0c08366d5aaeb5b8fb02d814d1e4b) - [-rw-r--r-- drivers/dma-buf/dma-buf.c 1 ]
14:04 sumits: any thoughts?
14:45 linkmauve: Hi, I’m writing a new DRM driver, which is currently render-only waiting for the new KMS Rust abstractions, but it currently creates only a /dev/dri/card0 and no render node, what should I do to make it do so?
14:47 glehmann: I would like to land https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40872 before the branch point next week, but I still need an rb for the intel and aco changes
14:51 alyssa: android /o/
14:51 alyssa: /o\
14:51 alyssa: glehmann: oh, r-b on intel there, sorry
14:51 alyssa: i forgot i reivewed that commit
14:52 alyssa: linkmauve: ..what hw? do I want to know?
14:54 alyssa: apparently not android's fault, clang being dumb
14:55 alyssa: ../src/intel/compiler/jay/jay_builder.h:465:19: error: assigning to 'enum jay_type' from incompatible type 'int'
14:55 alyssa: 465 | info->type_0 = p.src_type[0] ?: I->type;
14:55 alyssa: int? what int? those are all jay_type (:
14:56 alyssa: builds locally (with clang), maybe old llvm issue
14:57 jannau: linkmauve: the rust drm bindings in upstream do not set FEAT_RENDER and provide no means to allow the driver implemenation to set that bit
14:57 jannau: look at tyr's or asahi's downstream drivers
14:57 glehmann: alyssa: does it work without the compiler extension ternary op?
14:58 alyssa: glehmann: we'll find out in a couple hours when I get marge next
14:59 glehmann: you can manually trigger just the clang jobs for testing
14:59 jannau: linkmauve: asahi downstream does https://github.com/AsahiLinux/linux/commit/13fc5b9ebc0edcdec393ecc75facdeef74871c15
15:03 jannau: tyr is probably closer to mainline w.r.t. to other missing bits if you want to use one of those downstream branches as base
15:06 linkmauve: alyssa, I’ve started writing a driver for the GameCube GPU. :)
15:06 alyssa: glehmann: ah fair. he's running now.
15:06 alyssa: linkmauve: ...Checks out :p
15:06 linkmauve: Not sure how much of userland will work on it, atm I’m testing against apitrace-like traces from Dolphin.
15:06 alyssa: why GC and not Wii?
15:07 alyssa: (isn't it basically the same just marginally less good?)
15:07 linkmauve: It has the exact same GPU. :)
15:07 linkmauve: I’m actually testing on a Wii atm, but it’ll support both of course.
15:07 alyssa: Fair
15:09 glehmann: can that thing even support GLES1?
15:10 linkmauve: I’m compiling on my G4 iBook though, because the Wii has too little memory for rustc.
15:10 linkmauve: glehmann, I know very little about GLES 1, I’m going to go for OpenGL 1.5 I think.
15:11 linkmauve: There are some projects exposing an OpenGL-like API on top of GX, Nintendo’s proprietary API.
15:13 alyssa: glehmann: it's the most advanced fixed-function gpu ever shipped iirc (:
15:14 alyssa: glehmann: and yeah seems fine without the elvis operator
15:14 alyssa: so something wonky with ?: with enums on old clang
15:14 alyssa: (i use ?: elsewhere with ints & pointers and that's fine, ci passed)
15:14 alyssa: ah well
15:16 linkmauve: It almost supports fragment shaders! It supports 16 successive instructions which can each compute from the previous output or from other sources.
15:19 glehmann: anything without at least GLES2 is borderline useless on linux today though
15:21 linkmauve: I’m aware of that, and even GLES 2.0 is starting to get dropped here and there.
15:24 MoeIcenowy: saying about PowerPC Mac laptops, I remembered my PowerBook G4 12" 867 (Al), which cannot work with nouveau properly because of some flat panel table quirk
15:24 MoeIcenowy: (and it's difficult to even find someone careful for nouveau on legacy Mac systems
15:25 MoeIcenowy: with legacy GPUs
15:26 linkmauve: Mine has an ATI RV350 which has tiling gone completely wrong atm, on Mesa 24.1 (the latest version supporting this GPU “correctly” according to ArchPOWER maintainers).
15:27 MoeIcenowy: my laptop has a NV17, which is only dirty plain framebuffer card in the programmable shader era
15:37 linkmauve: I can run my custom ioctl()s! The data they receive is incorrect, but still, progress. :)
15:38 Hazematman: linkmauve: that sounds like a really neat project! good luck with it!
15:39 linkmauve: Thanks. :)
15:40 linkmauve: I only started it last night, no idea how far I’ll go.
16:49 alyssa: Moana.mp3
18:58 linkmauve: alyssa, congrats on the jay merge!
18:59 alyssa: thank u!
19:02 zmike: big day
19:34 dj-death: anybody would have an idea of why everything on zink is crashing ? : https://gitlab.freedesktop.org/mesa/mesa/-/jobs/97240148
19:34 dj-death: only on zink-anv-adl but not zink-anv-tgl
19:35 dj-death: when as far as mesa is concerned is pretty much the same GPU
19:56 zmike: maybe different env vars
19:56 zmike: iirc I enabled descriptor buffer on one of them at some point
20:01 linkmauve: To allocate a large (~256 KiB) physically contiguous memory area, is the best solution to use reserved-memory in the device-tree, or is it something I can do in the driver too?
20:12 dj-death: zmike: I guess I'll run commit by commit until I find the culprit...
20:13 zmike: I've had to do that on adl before
20:13 zmike: something is very very very weird about that job/hw
20:19 dj-death: experimental kernel driver