00:00 zmike: karolherbst: there, have fun with it
00:01 karolherbst: nice nice nice
00:03 airlied: karolherbst: use c++filt to find out __clc_sw_fma(float __vector(8), float __vector(8), float __vector(8)) after that, it's like something is getting passed to it wrong then
00:05 airlied: karolherbst: looks like a missing parameter in the call
00:05 karolherbst: ahh that's plausible
00:06 karolherbst: maybe
00:07 airlied: call void @_Z12__clc_sw_fmafff(<8 x i32> %242, ptr %callcontext, <8 x i64> <i64 32, i64 32, i64 32, i64 32, i64 32, i64 32, i64 32, i64 32>, <8 x i32> %ssa_25, <8 x i32> %ssa_26, <8 x i32> %ssa_27)
00:07 airlied: seesm to have the 8x64 in it before the actual parameters
00:08 airlied: oh it has a zer0 init one
00:08 karolherbst: but also why are we calling into the libclc sw fma function for lp 🙃
00:09 airlied: don't think lp has any input on that decision
00:10 airlied: I think you'd have to dump the library side to know what it is expecting
00:18 karolherbst: uhh so much code to delete
00:19 karolherbst: I might end up more than the size of clover 🙃
00:20 zmike: how is there no chainsaw emoji
00:20 zmike: or maybe like a hedge trimmer
00:20 karolherbst: the fun part is, that I also remove code in zink 🙃
00:20 zmike: yessss
00:47 karolherbst: uhhh.. why is nv50
00:48 dwfreed: because they wanted to improve nv40?
00:48 dwfreed:ducks
00:51 zmike:shakes fist
00:51 zmike: I asked myself that many times this afternoon
00:52 karolherbst: I'm only at " 46 files changed, 68 insertions(+), 634 deletions(-)" and I'm just getting started
00:52 zmike: fuck yeah
00:54 karolherbst: why am I finding more and more stuff to delete.. this is madness
00:55 FireBurn: Hey I'm getting the following error when trying to build for andorid
00:55 FireBurn: src/egl/meson.build:10:16: ERROR: Unknown variable "libpipe_loader_dynamic".
00:55 zmike: karolherbst: delete that too^
00:56 karolherbst: yeah...
00:56 karolherbst: though
00:56 karolherbst: isn't the new way the gl loading stuff works relying on it?
00:56 zmike: uhhhh I don't think so?
00:57 zmike: but also I'm not sure what you're talking about with "gl loading stuff"
01:00 karolherbst: like it uses the libpipe_loader_dynamic now
01:06 zmike: huh
01:06 zmike: I'd have to look closer I guess
01:06 zmike: a task for tomorrow
06:28 anarsoul: hey folks, I'm working on fixing mipmapping for linear textures for lima. The issue is that texture descriptor allows to specify stride for all the levels globally (i.e. each level has the same stride). As a workaround I'm thinking about an layout that looks like a texture atlas
06:29 anarsoul: is there an existing algorithm to find the optimal dimensions and placement for individual levels? as an additional difficulty individual level dimensions must be aligned to tile boundaries (16x16)
06:29 anarsoul: obviously it won't work for 3D textures, but should be fine for 2D
07:57 phasta: I have to read "Is the bug in the current rc?" as "Is this a new bug that has not yet been in the kernel, but was introduced in the last merge window and that's why it's in the current -rc?", haven't I?
07:57 phasta: https://drm.pages.freedesktop.org/maintainer-tools/committer/committer-drm-misc.html
07:59 phasta: IOW: I have this bug fix here and don't know where to apply it
07:59 phasta: https://lore.kernel.org/dri-devel/20250311060251.4041101-1-liuqianyi125@gmail.com/
07:59 phasta: airlied ^
08:13 phasta: mripard_, ^ :)
08:26 mripard: phasta: I'm confused, how can a bug not be in the kernel, and yet be in the current rc?
08:27 MrCooper: phasta: I think it's about "in -rc (or a release), as opposed to only in some -next branch"
08:27 mripard: yeah, it's about whether the bug can be reproduced on Linus branch, or ours, essentially
08:28 phasta: So if the bug was there in kernel 4.1.0 already, it goes to drm-misc-fixes
08:29 mripard: it's in the current rc, so yes
08:35 phasta: OK, thx
08:44 Company: hrm
08:44 Company: is there a way to read a dmabuf's contents via (E)GL?
08:45 Company: I always assumed there has to be, but I can't find one
08:45 Company: I'm in particular interested in YUV multiplanar formats, ie NV12 and friends
09:07 pq: Company, you mean something than than making a texture and rendering with it?
09:07 Company: yeah
09:07 Company: I want to get the data without rendering
09:08 Company: rendering YUV will convert it to RGB
09:08 pq: unless you lie about the format?
09:09 Company: even then
09:09 Company: NV12 is subsampled
09:09 pq: Weston seems lie about NV12 just fine.
09:10 pq: using R8 and GR88 formats
09:10 Company: oh yeah, that's a trick I could probably do
09:10 pq: it just makes two textures from the same dmabuf
09:10 Company: import the planes as individual textures instead of the whole image
09:11 pq: yeah
09:11 pq: I guess desktop GL might have something as a reverse glTexImage thing, I dunno.
09:11 Company: Vulkan gives me access to the individual image planes so I can copy them into buffers and then read those
09:12 Company: glGetTexImage(), but I think that's not valid for EGLImages
09:12 Company: no clue though, I need a GLES solution because desktop GL can't import NV12 anyway
09:12 pq: right
09:13 pq: I wonder if you could, if the R8 and GR88 textures were renderable, bind them one at a time to an FBO and glReadPixels.
09:23 Company: they are renderable per spec
09:26 pq: Company, but the driver could still disagree, stride requirements and whatnot?
09:28 Company: it could reject the dmabuf import, especially in the case I'm interested in - the one with modifiers
09:28 Company: but I think once it imported a R8 or RG88 texture, it has to work
10:42 jani: PSA: moving from patchwork to lore Link: trailers in commits applied with dim: https://gitlab.freedesktop.org/drm/maintainer-tools/-/merge_requests/74
10:43 emersion: nice
11:10 K900: dcbaker ping for https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33890 (sorry, I really want to get it merged before 25.1)
13:04 zmike: wow this latest refactor actually found a zink bug
13:04 zmike: unbelievable
13:06 pac85: zink can have bugs?
13:06 zmike: I blame gfxstrand
13:06 zmike: it was my understanding that all bugs were fixed
14:32 alyssa: pac85: as a treat
14:33 pac85: alyssa: you are right, it would be too boring without bugs and zink can't afford to be boring
14:34 alyssa: anarsoul: I don't think you're supposed to support mipmapping on linear textures
14:35 alyssa: jani: what's meant to replace patchwork for dri-devel?
14:35 alyssa: or are we just banking on the gitlab-ification of DRM happening long term?
14:42 tzimmermann: javierm, hi. are you around for reviews?
14:53 jani: alyssa: background: https://lore.kernel.org/r/814f9bcb9c7ee22af45bd5278255af247c6664fa.camel@intel.com
14:54 jani: alyssa: our CI moving away from patchwork is a separate matter from keeping patchwork running. but once we move away, it might be a question whether there are users for fdo patchwork anymore.
14:55 alyssa: ahh makes sense
14:55 alyssa: I don't think I realized kernelci consumed patchwork
14:55 alyssa: thx for the link :)
14:55 jani: and regardless of all this, people(tm) have questioned the use of patchwork links in the Link: tag when b4 uses lore links
14:56 jani: oh I don't know about kernelci, this is for intel-gfx-ci
14:57 alyssa: those are different?-- ah yes of course they are
14:58 jani: :)
15:01 jani: we have a lot of historical baggage, and our use of fdo patchwork is one of them. I think it predates gitlab.fd.o by about five years or so
15:01 DragoonAethis: alyssa: yup, kernelci is more like a central database of results driven by some teams, not a CI system by itself
15:02 DragoonAethis: I know of it, and would like to eventually push data there... but um, we have bigger problems for now
15:02 jani: and fdo patchwork is a fork of the original patchwork that never merged back
15:14 alyssa: DragoonAethis: fair enough
15:39 zmike: anyone know how to test svga driver?
16:14 karolherbst: so first pile of patches to remove stuff nobody needs anymore (even before we remove clover): https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34051
16:15 zmike: huge series
16:17 karolherbst: this is nothing compared what I'm gonna do to r600 and radeonsi
16:19 zmike: you teach em a lesson karol
16:48 K900: Massive
16:48 K900: Should distros still ship Clover for 25.1?
16:48 K900: I kinda want to at least disable it
17:09 mattst88: I don't think so. I'm not shipping it in Gentoo for a while now and no one has complained
17:11 karolherbst: it's also pretty broken on radeonsi, so normally if you end up using clover there your system just hangs
17:22 K900: Fun
17:23 mareko: karolherbst: does radeonsi clover hang with main?
17:23 karolherbst: pretty much everytime I accidentally run a CTS test on it
17:29 mareko: then I think we can remove it
18:10 alyssa: I've heard that drm/sched will elide intra-queue syncobj dependencies, can anyone point me to where in the code that's happening?
18:11 alyssa: I.e. if you submit two jobs to the same queue back to back, the first signals a syncobj, the second waits on it, drm/sched will just submit them both together without roundtripping to the cpu in the middle
18:12 alyssa: (It also seems that happens only for binary syncobjs, but not for timeline syncobjs. Judging by a race I've been chasing since yesterday.)
18:15 lynxeye: alyssa: drm_sched_entity_add_dependency_cb is what you want to look at, I believe.
18:16 alyssa: lynxeye: ooh, yeah. thanks :)
18:16 alyssa: now to figure out why this doesn't happen for timeline syncs..
18:17 alyssa: the second-level question there is .. whose bug is it?
18:18 alyssa: If I understand the drm/asahi + apple fw behaviour right, drm/asahi is depending on the following invariant
18:19 alyssa: "Jobs submitted to a queue that only depend on jobs previously submitted to that queue, will be scheduled in finite time after the previous jobs are scheduled"
18:19 alyssa: drm/sched satisfies that when only binary sync is involved
18:20 alyssa: but I'm unsure if it's part of the drm/sched contract.. it does seem that we're depending on this only by chance! (because it's a tricky race to hit otherwise)
18:23 robclark: alyssa: it should all come down to the fence context of the underlying dma_fence.. syncobjs are just syntactic goo on top of fences.
18:26 alyssa: robclark: duly noted. i am so new to seeing behind the goo :(
18:28 robclark: iirc container fences should combine fences that are on the same context/timeline.. I wonder if that doesn't happen for dma_fence_chain?
18:28 lynxeye: alyssa: what makes the firmware depend on those jobs being scheduled in finite time? Isn't a job that hasn't been scheduled simply invisible to the firmware and would thus not cause any harm?
18:30 robclark: looks like dma_fence_chain_init() does try to do this
18:30 lynxeye: job submission to a queue might also be blocked by insufficient credits for that queue in which case the scheduler will not schedule any new jobs until a job from that queue finishes
18:32 alyssa: lynxeye: I think due to a drm/asahi logic bug. But I didn't write this driver and I do not understand the r/e'd firmware yet and it's not like there's docs to consult..
18:32 alyssa: consider this a working theory
18:34 alyssa: this is my first time doing serious work on this driver. not loving it :p
18:37 alyssa: but.. learning lots
18:42 alyssa: lynxeye: credit limit for drm/asahi is impossibly high which would explain that never being hit
18:48 lynxeye: alyssa: Ah okay, just wanted to point this out as one more potential source to violate your invariant.
18:49 alyssa: lynxeye: appreciate that info, will put it in my comment
18:49 alyssa: i'm attempting to rework the drm/asahi logic to not depend on this. seems to fix my hang/race C:
19:59 zmike: jenatali: can you check out https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33946 and make sure the latest version builds on msvc ? I don't want to waste however many CI jobs to get it fixed up
20:00 jenatali: zmike: It's faster for me to click the UI buttons to trigger the pipelines than to pull and build locally, especially while I've got an LLVM build already going...
20:00 zmike: brutal
20:00 zmike: ok
20:00 jenatali: But yeah I'll click those buttons for you :)
20:03 jenatali: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/72861544 - if it needs fixes and you want me to stage them I can do that
20:03 zmike: eh if you can't iterate locally I can push myself
20:03 zmike: but thanks
20:08 jenatali: Can't is a strong word :P
20:09 zmike: I couldn't possibly impose upon your llvm build
20:11 jenatali: Nah it's done. It was just DXC, not full LLVM
20:11 jenatali: Lemme pull
20:11 zmike: ty
20:11 zmike: I started another pipeline anyway
20:16 jenatali: Passed for me
20:17 zmike: nice
20:18 zmike: err
20:18 zmike: hm
20:18 zmike: oh I see, ci has multiple msvc target jobs
20:20 jenatali: 3 containers, one build, and a few tests, yeah
20:44 alyssa: 4/query Lynne
20:44 alyssa: oops