01:18zmike: tarceri: awesome thanks
01:46tarceri: zmike: did the mr you made hide the issue in the trace?
01:46zmike: tarceri: I think it still happens, just less immediately
01:47zmike: so if you revert that MR it should happen right away
01:49tarceri: ok thanks
07:35dolphin: sima, airlied: no fixes picked up by dim, so no drm-intel-fixes PR this week
07:52sima: aye
10:10mlankhorst: tzimmermann: it seems you might have created a regression on ptl https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14874 ?
10:22imre: mlankhorst, tzimmermann: maybe https://dpaste.com/6D3BH8RRG ?
10:24imre: or rather https://dpaste.com/D2UGE2F3S
10:26tzimmermann: mlankhorst, imre, i know. could you review https://lore.kernel.org/dri-devel/20250826145044.954396-1-tzimmermann@suse.de/ it's the patch resolving the problem
10:26tzimmermann: ?
10:28imre: tzimmermann: don't you want to keep the atomic change, using the old crtc/plane state seems to be the correct thing to me..
10:29imre: haven't tested it, but I suppose the new plane state's CRTC is NULL, but the old plane state should have a non-NULL crtc
10:29tzimmermann: imre. no. there's no crtc_state when disabling. the old format mightbe nonsense. but the format in sysfb is always correct
10:36tzimmermann: i apparently didn't think of this case when i wrote the patch. (and i swear i also tested it.) the format in sysfb is the format in hardware. so it's always the correct one. the format in crtc might be 'adapted in a compatible way' to implement palette features.
10:42mlankhorst: Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.linux.com> -- can you add a fixes line too?
10:43mlankhorst: erm bugzilla line to the issue
11:27tzimmermann: mlankhorst, will do. thanks for the r-b
11:33karolherbst: zmike: mhhh.. could we turn fence_server into actual gpu waits inside zink?
11:33zmike: no
11:33karolherbst: oof
11:34karolherbst: that's.... kinda annoying tbh
11:34karolherbst: what's the biggest problem there so it can't be done?
11:35karolherbst: ehh wait.. it does a gpu wait bug on the queue submission thread.. nah, that's fine
11:35zmike: well
11:35zmike: let's go back
11:35karolherbst: what's annoying is the CPU wait there
11:35karolherbst: I have a nasty dead-lock
11:35zmike: what cpu wait?
11:35zmike: fence_server is not an api
11:35karolherbst: `util_queue_fence_wait(&bs->flush_completed);` inside `zink_fence_server_signal`
11:36zmike: ah
11:36zmike: yes
11:36zmike: that cannot change
11:36karolherbst: yeah.. it's causing a dead-lock
11:36karolherbst: but why would you have to wait for completion there?
11:36zmike: I guess you could add a wait bool and set it to true from GL
11:36zmike: the GL external objects spec requires that this call submits to the gpu before returning
11:36zmike: I'd be surprised if the CL one isn't equivalent
11:36karolherbst: sure
11:36karolherbst: but that doesn't meaan you have to wait
11:37zmike: it does though
11:37zmike: because otherwise it isn't submitted to the gpu
11:37karolherbst: mhhh
11:37karolherbst: not sure if that's an issue
11:37zmike: ...?
11:37karolherbst: like you do submit, that's fine
11:37karolherbst: but why do you need to wait until the flush completes?
11:38zmike: I don't understand what you're asking
11:38zmike: flush does not mean submit
11:38karolherbst: just dropping the `util_queue_fence_wait` basically
11:38zmike: yes
11:38zmike: that I understand
11:38zmike: and am telling you it is impossible
11:39karolherbst: mhhh
11:39zmike: you are conflating gallium pipe_context::flush with vkQueueSubmit
11:39karolherbst: maybe I should explain the dead-lock and maybe you come up with a better solution
11:39zmike: they are not the same
11:41karolherbst: I see
12:01karolherbst: ohh mhh.. maybe I can fix this issue on my side
12:05karolherbst: yeah.. maybe I should try harder to make sure the fence_server_signal actually reaches the hardware/vulkan driver before I submit the fence_server_wait. I think the dead-lock is caused by a race between thoes two operations (on two different pipe_contexts) and things go south sometimes
12:05zmike: signal is REQUIRED to reach hardware before it returns
12:05zmike: if it doesn't then that's a driver bug
12:16karolherbst: yeah.. but this happens on two different pipe_contexts and I currently I assume that they are independent enough
12:16karolherbst: but I should probably make sure the queue submitting the signal actually finish it before I submit the wait
12:17zmike: like I said, so long as the server_signal call returns, it has finished submitting
12:17zmike: ...unless it's a driver bug
12:18karolherbst: I think that depends on what we want gallium to expect from drivers
12:18zmike: that is what gallium expects
12:18karolherbst: I meant it differently
12:18karolherbst: like context 1 does fence_signal, context 2 does fence_wait. frontend flushes 2 before 1, but flushes both
12:18karolherbst: is that expected to work?
12:19zmike: fence_signal does not need a flush
12:20karolherbst: okay, but would it be valid to call fence_wait on context 2 before fence_signal on context 1?
12:20zmike: no
12:20karolherbst: so I need to ensure strict ordering here
12:20zmike: yes
12:20karolherbst: probably want to document it
12:21karolherbst: there is documentation on having to flush, but should probably also require ordering there
12:21karolherbst: anyway, that helps, guess I'll just do that then
12:22zmike: maybe I forgot to document when doing external object updates
12:22zmike: idk
12:23karolherbst: it's not here at least: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/docs/gallium/context.rst
12:23zmike: feel free to add a note
12:24karolherbst: yeah will do
12:24karolherbst: I should also document semaphore_create there
13:40jani: airlied: sima: there's a small refactoring series to iopoll.h from vsyrjala https://lore.kernel.org/all/20250826121859.15497-1-ville.syrjala@linux.intel.com/
13:41jani: airlied: sima: it's been sent before about a month ago, but iopoll.h is not in MAINTAINERS, and there were no replies from the usual suspects
13:41jani: airlied: sima: are you cool with me just merging this via drm-intel-next? this appears to have been the SOP for previous changes to the file
13:43mlankhorst: mripard: ping?
13:47mripard: mlankhorst: pong
13:49sima: jani, I guess there's more patches that will land through d-i-n?
13:49sima: and yeah looks reasonable, a-b: me
13:53jani: sima: yes. I wrote https://lore.kernel.org/r/cover.1751023767.git.jani.nikula@intel.com but vsyrjala disliked how the read_poll_timeout() looks, and he's not wrong. with the iopoll changes I can rebase that on the new stuff, and make it all around nicer. and reduce our dependency on custom wait hacks
13:54jani: sima: and thanks for the ack
14:22sima: jani, yay for your patchset :-)
16:56Swung0x48: Hello everyone
16:58Swung0x48: I’m attempting to integrate Kopper on Android, so that it (with Zink) will appear as an EGL+desktop GL userland driver for Android
16:59Swung0x48: I guess I should hook up Mesa’s egl front end to Android Vulkan WSI?
17:02zmike: Swung0x48: I had started this a bit with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30766
17:03zmike: you can probably start there
17:03zmike: though I'd guess by now it needs some rebasing
19:51karolherbst: zmike: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36007/diffs?commit_id=e4c08135e02e697fdc8d136fef636d8b1b095218