02:47 tarceri: Anyone with a freedreno vulkan setup able to dump the nir or tell me where the driver is crashing in the cts test from the failed pipeline in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32473
02:48 tarceri: ?
07:34 tomba: pinchartl: I think patch 4 still needs an ack from a DT maintainer
07:53 pinchartl: tomba: you're right of course
08:50 tzimmermann: javierm, i have a major fix for fbdev-dma, which i'd like you to review. but it's large and needs to go in one piece. shall i split if up into smaller patches for the review?
08:51 tzimmermann: javierm, it's this patch: https://lore.kernel.org/dri-devel/9c902ac0-a94d-4465-98ff-840132e482b1@suse.de/
09:17 jfalempe: tzimmermann: I will push drm_log to drm-misc-next this afternoon, if no other comments until then. Thanks for the reviews.
09:18 tzimmermann: jfalempe, of course, go ahead
09:30 javierm: tzimmermann: it's OK to have it as a big patch. It's basically a partial revert then or the patch you are going to post is different ?
09:30 javierm: jfalempe: it's OK for me too. I didn't review because was too busy with internal stuff but also because you already got tzimmermann's review
09:31 tzimmermann: javierm, it's the one i linked to, but with commit message and tags
09:32 tzimmermann: it (1) refactors the code for a better split between direct mmap and deferred I/O, and (2) adds shadow buffering to the deferred-io case
09:32 tzimmermann: i'll try to give you a good descriptino in the commit message
09:32 javierm: tzimmermann: right, but you mention in the thread that restores the fbdev handling as it was before the regression, does this mean that we didn't get to the root cause of the issue ?
09:33 javierm: ah, "fbdev-dma: Add shadow buffering for deferred I/O" I see now
09:33 tzimmermann: 'restore' in the sense that some drivers switch back to shadow buffering.
09:34 javierm: tzimmermann: yeah, makes sense. It's OK to have it in a big patch for review
09:35 tzimmermann: deferred i/o tracks pages. i suspect that not all architectures provide pages for their dma areas (?)
09:35 tzimmermann: but IDK how to test this
09:35 tzimmermann: something at runtime should tell whether the buffer is backed by struct page or not
09:36 tzimmermann: on rpi, the current fbdev-dma works. on the reporter's system apparently not
09:36 tzimmermann: if you know how to detect this, let me know
09:49 javierm: tzimmermann: I do not know, but maybe jfalempe does? ^
09:50 jannau: jfalempe: are there plans to host https://github.com/kdj0c/panic_report on fedora or kernel.org servers? I consider enabling it for fedora-asahi-remix where the rust dependency is not an issue since the GPU driver requires it anyway
09:51 jfalempe: javierm, tzimmermann: no I'm still learning about dma areas for graphics drivers ;)
09:52 javierm: same :)
09:56 jfalempe: jannau: Not yet, but I would like to have it on Fedora in the future. I'm currently trying to get more GPU support first.
09:57 tzimmermann: jfalempe, javierm, i've found virt_addr_valid(). not sure how reliable that is. https://elixir.bootlin.com/linux/v6.12.4/source/arch/arm64/include/asm/memory.h#L425
09:57 jfalempe: jannau: I don't think the asahi GPU driver has support for drm_panic yet.
09:59 jfalempe: jannau: Also I want to update the QR code binary encoding, before having real users of the feature, see https://patchwork.freedesktop.org/series/142175/
10:11 jannau: jfalempe: I added support: https://social.treehouse.systems/@janne/113613682204970732
10:12 jannau: I can pull the patches with the new encoding into our downstream fork
10:16 javierm: jannau: cool :)
10:16 jfalempe: jannau: oh nice work!
10:22 jannau: if you want early tester for the fedora infrastructure we can do that via the fedora-asahi-reemix kernel. In the meantime I've asked to host it on asahilinux infrastructure since that's more familiar than a "random" github.io page
10:22 sima: tzimmermann, I think if you have a carveout instead of cma for contig dma allocations, then it's not struct page backed
10:22 robmur01: tzimmermann: not sure of the context, but virt_addr_valid() only means a struct page exists, i.e. virt_to_page() will give a valid result. It still doesn't let you assume anything about what that page might represent
10:22 sima: but I'm also not sure you're ever allowed to interact with the struct page, even if it's there
10:23 tzimmermann: sima, so i always have to use shadow buffering with fbdev-dma if the driver requires it?
10:24 tzimmermann: (requires eq framebuffer_funcs.dirty != NULL)
10:24 sima: if you use the fbdev defio stuff, yes
10:25 sima: I think if you rely only on pfn dirty tracking instead, it should be ok, but that's an entire different mess
10:25 tzimmermann: sima, i'd rather like to simplify :)
10:26 sima: I dont think that's an option without us pulling the fbdev dirty tracking into the drm helpers
10:26 tzimmermann: some of the panel drivers use shmem-dma. i thought about convertig them to shmem. but noralf mentioned that not all platforms suport shmem. right?
10:26 sima: NOMMU ones die on shmem
10:26 sima: iirc
10:27 tzimmermann: that's what i also heard
10:27 tzimmermann: it's all not so great
10:28 sima: I think if you really want to unify as much as possible then with somewhat low confidence I think a drm helper dirty tracking that only uses pte dirty and vm_insert_pfn and entirely ignores struct page (so need a bitarray for tracking instead) could work
10:28 sima: since iirc touching struct page is also no-go for ttm backed buffers, at least ttm has gotten really pissed about that in the past
10:29 sima: but low confidence only because I have no idea what other corner case we might hit with that
10:29 tzimmermann: sima, it doesn't seem worth the effort
10:29 sima: yeah it's just fbdev
10:29 sima: that's also why I never pushed for this more than occasionally mentioning it
10:30 sima: iirc willy from mm also brought up that the current fbdev dirty tracking is somewhat fishy
10:30 sima: but I forgot why
10:30 tzimmermann: oh, ok
10:32 sima: tzimmermann, I think just being aware that this is an option, in case we ever hit a corner where it's the last one we can try, is enough for now
10:32 tzimmermann: sometimes i think we should just alloc an fbdev framebuffer with vmalloc and use that for all hardware. that's the only generic solution. would be slower on some machines, but who really cares
10:32 sima: unless you get really motivated to learn a lot about pte semantics or arcane architectures and want to give it a shot :-)
10:33 sima: tzimmermann, I think having both for now is ok
10:34 tzimmermann: sima, thanks for the help
10:48 jani: tzimmermann: https://lore.kernel.org/r/87y10pyv8m.fsf@intel.com
11:31 tzimmermann: jani, ack
12:08 jani: tzimmermann: thanks!
14:07 DragoonAethis: Hey, do you know if ARM-related GPUs (Adrenos, Mali, VideoCore, etc) always show up as PCI devices, or are there cases where they end up connected with something platform-specific and don't have a PCI addr?
14:21 sima: DragoonAethis, pretty much always platform devices, but they're enumerated in /sys still
14:22 DragoonAethis: sima: Okay, thanks!
14:27 lumag: vignesh, another ping, do you have any plans to uprev IGT?
14:27 lumag: If not I'll have to spend some time on running the CI, but I'd really like not to duplicate your job
15:17 misyl: nowrep: Thanks for pointing that out, I feel stupid now >.<
15:21 nowrep: no problem, hope it works now
15:31 misyl: yep seems to work fine
15:54 leandrohrb: hwentlan_: hi! are the existing IGT tests from the color pipeline proposal passing on AMD and VKMS? I'm seeing some issues with writeback format, and also some other failures/skips
16:36 alyssa: jenatali: please look at https://gitlab.freedesktop.org/mesa/mesa/-/jobs/67998286 , I can't run the tests on Linux
16:38 jenatali: Looking
16:38 alyssa: thanks
16:38 alyssa:running cl cts on rusticl in case she broke that too
16:41 vignesh: lumag: I'm working on it and will send a patch after I update the expectation files
16:43 alyssa: now I can't even test rusticl, that's.. exciting
16:48 jenatali: alyssa: I don't see anywhere that you adjusted how the printf buffer is read for rusticl
16:48 alyssa: jenatali: It should be compatible, is the thing
16:48 alyssa: (I mean, should is a strong word, but)
16:48 alyssa: the size of the header is controlled by the frontend, so if you're writing 4 as the initial size value, then that's that no change
16:49 jenatali: How do you figure?
16:49 jenatali: Oh right I forgot about that part
16:52 jenatali: Hmmmmm test passed for me
16:53 alyssa: ..
16:53 alyssa: karolherbst: rusticl+kmsro doesn't seem to work anymore, any idea what's happening?
16:53 alyssa: (kmsro: driver missing)
16:54 karolherbst: not aware of any issues there
16:55 alyssa: none of GALLIUM_* macros are defined in drm_helper.h so idk what that means
16:55 alyssa: i don't understand how this is supposed to work tbh
16:57 alyssa: adding driver_kmsro as a dependency for rusticl seems to make that go away but im still not getting devices. what
16:57 jenatali: Hm, fails when I run everything but passes in isolation. That's fun
16:58 alyssa: oof
17:00 jenatali: Fun, seems it's due to the printf buffer being uninitialized in this test framework
17:01 jenatali: alyssa: Patch pushed that fixed it for me locally
18:19 alyssa: thanks :)
18:27 alyssa: jenatali: It's not really clear to me why that would be loadbearing, though
18:28 jenatali: Yeah I would've expected the fresh allocation to be zeroed but I guess it wasn't
18:28 jenatali: Idk, the failure was that printf returned that the buffer was full
18:28 alyssa: I guess it's just differently uninitialized now?
18:28 alyssa: (now = with my MR without your fixup)
18:29 alyssa: because on paper, the MR has no functional change on microsoft cl
18:29 jenatali: Probably the signedness difference, yeah
18:29 alyssa: hmm. ok.
18:29 alyssa: Well, if you're not bothered by it I'm not I guess
18:29 alyssa:assigns marge
18:29 alyssa: thanks for the debug
18:30 jenatali: Yeah I'm not particularly bothered by it. Wasn't worth the time to bottom out on the problem
19:59 emersion: has anyone time to review this? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32535
19:59 emersion: fixes a crash on wayland on systems without modifiers
20:04 lumag: vignesh, ack, thank you!
22:31 lumag: krh, gfxstrand, let me try pinging you here. Is there a chance of landing https://github.com/krh/vkcube/pull/61?