08:01 MrCooper: soreau: *_dri.so is used only by xserver for server-side GLX support anymore, no longer by app-side EGL/GLX code
08:02 MrCooper: daniels: personally not really ATM, somebody else might be interested for mutter though
08:35 mripard: tzimmermann: lumag: if you have a bit of time, could you have a look at https://lore.kernel.org/r/20260519-drm-mode-config-init-v5-0-388b03321e38@kernel.org ?
08:35 mripard: it seems to be close to done, I'd like to merge it soonish if it's all acceptable
08:36 tzimmermann: looking at it...
08:38 mripard: thanks :)
10:39 tzimmermann: airlied, sima, hi. please forward drm-next to -rc5. required for getting the latest fixes into drm-misc-next
11:54 shivamklr: Hey phasta
12:42 tzimmermann: bbrezill1, hi. what exactly is the problem in the regression report at https://lore.kernel.org/dri-devel/20260209133241.238813-1-tzimmermann@suse.de/T/#me89d825e31e90d89dd07793d6445cff7642d64f8 ? my gut feeling is that shmem->pages[page_offset] is NULL: https://elixir.bootlin.com/linux/v7.1-rc1/source/drivers/gpu/drm/drm_gem_shmem_helper.c#L569
13:09 alyssa: oops Alyssa hogged all the labels again
13:10 Hazematman: the label field looks like a bag of skittles
13:11 MrCooper: hehe
13:12 karolherbst: I really just want to copy libclc into mesa and not having to deal with LLVM...
13:20 alyssa: ..I have to say, the fact that the MR's been up for 12 minutes and there's already a merge conflict is a bit scary XD
13:20 bbrezillon: tzimmermann: I don't think that a NULL deref
13:21 tzimmermann: what's your theory?
13:21 bbrezillon: If I had to guess I'd say it's caused by guest or host page imports
13:22 bbrezillon: and either side expecting pages with write-access being mapped writeable immediately
13:22 bbrezillon: but I know near to nothing about KVM or virtio-gpu, so...
13:24 tzimmermann: can we simply clear pfn_mkwrite and be done with it for now?
13:32 bbrezillon: by clear you mean not implement it?
13:33 bbrezillon: I guess we'll have to mark the page dirty as soon as it's accessed instead of when pfn_mkwrite is called
13:33 bbrezillon: only if the mapping is writeable, of course
14:37 tzimmermann: bbrezillon, without pfn_mkwrite, we also have to run record_write https://elixir.bootlin.com/linux/v7.1-rc1/source/drivers/gpu/drm/drm_gem_shmem_helper.c#L597 for single pages, right?
14:49 bbrezillon: tzimmermann: yep, that's what I meant
14:49 bbrezillon: only if the mapping is requested writeable
14:50 bbrezillon: and if we do that unconditionally, we can make the logic the same for huge pages and normal pages
14:51 tzimmermann: bbrezillion, one thing I never understood is why record_write only records the first page for huge-page mappings. shouldn't it touch the whole range of 4k pages?
15:02 tzimmermann: brezillion, gemini told me that kvm explictly does not support PFNMAP for regular system memory (such as gem-shmem). not sure what to make of it. https://etherpad.opensuse.org/p/RqmXopA0Xgx8jlt2BzxR
15:02 tzimmermann: ^ this is the response when I gave it the regression report
15:03 tzimmermann: igor just replied that he doesn't use huge pages
15:04 bbrezillon: tzimmermann: I think we record dirtiness at the folio level
15:04 bbrezillon: and the folio covers all pages in a huge-page
15:05 tzimmermann: i see
15:15 tzimmermann: i'll send out something tomorrow
15:21 phasta: shivamklr: howdy
15:29 shivamklr: phasta I have started working on the locking runqueues todo. The races are clear in the source. Before I start adding locking, I'd like to understand:
15:29 shivamklr: 1. Are any of these lockless reads intentional for performance reasons?
15:29 shivamklr: 2. Would you prefer READ_ONCE/WRITE_ONCE (minimal, documents the intent) or actual spin_lock(&entity->lock) at each read site?
15:29 shivamklr: 3. For the IRQ-context callback (drm_sched_entity_wakeup), locking is tricky- any preference on approach?
16:03 phasta: shivamklr: 1. No one knows. None of the experts and hackers who were there when the code was written and when we discussed it at XDC'25 knows. Looking at that code base's history, though, I think it is likely that they omitted some locks for performance reasons.
16:04 phasta: 2. Locking is the gold standard. ACCESS_ONCE is the silver standard ;)
16:05 phasta: 3. mhm, I can take a closer look tomorrow. Have to go offline soonish. Can you ping me tomorrow?
16:05 shivamklr: Sure, same time?
16:06 phasta: I'm here beginning central european morning. I'll ping you if I remember
16:07 shivamklr: Cool. Have a nice rest of your day.
20:38 alyssa: glehmann: why sorry Intel?
20:38 alyssa: isn't simd32.. standard?
20:40 glehmann: 8x8 workgroups are really common, but yes simd32 might be enough for some
20:40 alyssa: i mean. who else has simd64 then
20:41 alyssa: qcom I guess
20:41 glehmann: yes
20:41 alyssa: 32-wide is the standard subgroup size
20:41 alyssa:shills for Nvidiapple
20:41 glehmann: and nv at least has 32 without a high risk of spilling to death
20:41 alyssa: so does intel on xe3+
20:41 alyssa: which theoretically is available on shelves today
20:42 glehmann: theoretically is doing a lot of work there
20:42 alyssa: legit
20:50 dj-death: If only I theoretically had 3000 euro to spend on a laptop