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? 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? -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
