Hi
Am 24.10.25 um 18:49 schrieb Michel Dänzer:
On 10/24/25 14:48, Jocelyn Falempe wrote:
On 24/10/2025 13:53, Tvrtko Ursulin wrote:
On 24/10/2025 12:04, Jocelyn Falempe wrote:
On a lenovo se100 server, when using i915 GPU for rendering, and the
ast driver for display, the graphic output is corrupted, and almost
unusable.
Adding a clflush call in the vmap function fixes this issue
completely.
AST is importing i915 allocated buffer in this use case, or how exactly is the
relationship?
I think it's mutter/gnome-shell who copy the buffer from i915 to ast, here is
the logs:
gnome-shell[2079]: Failed to initialize accelerated iGPU/dGPU framebuffer
sharing: Do not want to use software renderer (llvmpipe (LLVM 19.1.7, 256
bits)), falling back to CPU copy path
FWIW, the code which logged "falling back to CPU copy path" was removed in
mutter 42. Can you still reproduce the issue with a newer version of mutter, ideally 49?
A lot has changed over the last 3.5 years.
gnome-shell[1533]: Created gbm renderer for '/dev/dri/card0'
gnome-shell[1533]: GPU /dev/dri/card1 selected as primary
card0 is ast and card1 is i915
Do you think there is something missing in mutter?
Not that I can see offhand.
After logging "Failed to initialize accelerated iGPU/dGPU framebuffer sharing", mutter
tries to export a dma-buf from the i915 BO, import it into the AST device, create an KMS FB for
the imported BO and assign the FB to the primary plane of a CRTC. If this path works (which seems
to be the case in this scenario, or you wouldn't see BOs shared between i915 & AST), mutter
doesn't do any copies between different BOs. It's between the AST & i915 drivers to correctly
handle access to the shared BO.
Does the AST driver wait for the i915 GPU to finish drawing to the shared BO,
by waiting for the exclusive fence of the dma-buf synchronization object,
before reading from the BO?
Yes, ast waits for all the plane fences here:
https://elixir.bootlin.com/linux/v6.17.5/source/drivers/gpu/drm/drm_atomic_helper.c#L2762
Best regards
Thomas
P.S. If the path described above didn't work, mutter would fall back to reading
the i915 BO contents with glReadPixels and copying them to a dumb BO allocated
from the AST device, so you wouldn't see BOs shared between the drivers. With
current mutter, you can force this fallback with the environment variable
MUTTER_DEBUG_MULTI_GPU_FORCE_COPY_MODE=primary-gpu-cpu . Does that avoid the
issue?
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
