MultiRenderer silently drops frames on texture-reimport miss instead of erroring (NVIDIA multi-GPU, compressed block-linear buffers)

[4snt]

I think I found what's actually causing this failure mode (and maybe related to #2119/#2122/#2123, though I'm not 100% sure they're the same thing): MultiFrame::render_texture_from_to in src/backend/renderer/multigpu/mod.rs swallows a real failure and reports success anyway.

texture.reimport::<R>(...).map_err(Error::Render)?;

if let Some(texture) = texture.get::<R>(&render_id) {
    // normal draw path
} else {
    warn!(
        "Failed to render texture {:?}, import for wrong devices {:?}? {:?}",
        Arc::as_ptr(&texture.0), self.node, texture.0.lock().unwrap(),
    );
    Ok(())
}

reimport() returns Ok, but the texture.get::<R>(&render_id) right after it still doesn't find a texture for that render_id. Instead of erroring, it just logs a warning and returns Ok(()). So the compositor thinks the frame rendered fine, but nothing was actually drawn for that surface. No crash, no visible error — the client's window just never shows any content.

I hit this on Pop!_OS 24.04 + cosmic-comp (0.1178466532724.04~4d370cd), RTX 4060 Laptop GPU (driver 595.84) + Intel iGPU. Only the NVIDIA card drives any output (eDP-1/HDMI-A-1 both on card1); Intel shows up under /dev/dri but isn't attached to a display at all, and that's apparently still enough to put smithay on the MultiRenderer path. Reproduces with only the laptop's own display too, no external monitor involved.

Repro: launch any Chromium build with native Wayland Ozone (default, no --ozone-platform override) — window never becomes visible, process runs fine otherwise. journalctl _COMM=cosmic-comp shows the warning above firing on the client's first accelerated frame:

Failed to render texture 0x..., import for wrong devices DrmNode { dev: <renderD129's dev_t>, ty: Render }? MultiTextureInternal { textures: {}, size: Size<smithay::utils::geometry::Buffer> { w: 1920, h: 1080 }, format: Some(DrmFourcc(AB24)), buffer_format: DrmFormat { code: DrmFourcc(AB24), modifier: Unrecognized(216172782128496660) } }

Same warning fires repeatedly through a normal session (11 times in one boot) on small buffers too (80x28, 129x28, 244x28 px) — looks like tooltips/popups from other native-Wayland apps, so it's not Chromium-specific.

The modifier in that log isn't garbage, just unnamed by drm-fourcc: 0x0300000000e08014 decodes as DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D(c=1, s=1, g=2, k=8, h=4) — a valid NVIDIA modifier, compressed block-linear.

Workaround for anyone hitting this in an app: force it onto XWayland instead of native Wayland (e.g. Chromium's --ozone-platform=x11), which avoids MultiRenderer entirely. Confirmed that fixes rendering/fullscreen, screenshot-verified.

At minimum, that else branch should probably return an error instead of Ok(()), so this stops failing silently. Whether the real fix is retrying with another transfer format (like the WIP branch on #2122) or something about how reimport()/get() share a render_id, I don't know this code well enough to say — happy to test a patch or grab more logs if useful.