Drakulix
commented
10 months ago Is there an open wgpu issue for this?
Closed jokeyrhyme closed 9 months ago
Drakulix
commented
10 months ago Is there an open wgpu issue for this?
jokeyrhyme
commented
10 months ago Not yet, I'll raise one when I'm back at a computer
jokeyrhyme
commented
10 months ago jokeyrhyme
commented
9 months ago After being prompted over there, I tested in X11 and other compositors...
I could not reproduce this panic in sway, GNOME wayland, or GNOME x11, so it's likely specific to cosmic-comp ( this commit: https://github.com/pop-os/cosmic-comp/tree/9ce6a871c1ae48778aa10d61dbad7eab943195d3 )
I'd previously encountered an earlier bug in AMDVLK that was breaking wgpu so I incorrectly assumed it was another similar occurrence
ids1024
commented
9 months ago So with AMDVLK, this wouldn't be using Mesa's EGL/Vulkan WSI code, and instead would use AMD's own implementation? Looking at https://github.com/GPUOpen-Drivers/pal/blob/dev/src/core/os/amdgpu/wayland/waylandWindowSystem.cpp, it seems to require wl_drm. (While other drivers have moved to the newer dmabuf protocol.)
So it may be a bug with cosmic-comp's wl_drm implementation.
Logs from running the client with WAYLAND_DEBUG=1 may provide some more information here.
jokeyrhyme
commented
9 months ago Okay, I ran AMD_VULKAN_ICD=AMDVLK WAYLAND_DEBUG=1 RUST_BACKTRACE=1 cosmic-term and captured the stderr
ids1024
commented
9 months ago So the client is trying to use 875713112. That's XRGB8888. Which I think should be supported fine?
But wl_drm::format isn't being sent here, so either the compositor isn't advertising any formats, or the client isn't waiting for the compositor before selecting the format.
ids1024
commented
9 months ago Yeah, I think wl_drm::format should appear in the log right after wl_drm::capabilities. Is the format list empty, or did wl_drm::Format::try_from(*format as u32) fail to convert any formats, somehow?
jokeyrhyme
commented
9 months ago I can add more instrumentation somewhere and recompile to find out?
ids1024
commented
9 months ago I'd probably change https://github.com/pop-os/cosmic-comp/blob/f75d89b4240fb25f6e43443efd18f95c8484a620/src/wayland/protocols/drm.rs#L93-L98 to something like:
for format in global_data.formats.iter() {
dbg!(format);
if let Ok(converted) = dbg!(wl_drm::Format::try_from(*format as u32)) {
drm_instance.format(converted as u32);
}
}I'm not really familiar with AMDVLK, but I should be able to test it, assuming it works with any modern integrated AMD GPU.
jokeyrhyme
commented
9 months ago Hmmm, I've tried compiling cosmic-comp with cargo build --release and cargo build (debug) and neither results in dbg!(...) output ending up in journalctl -xb
I even put a trivial dbg!("cosmic-comp starting up"); in main.rs to confirm, and it doesn't appear in the logs
Do I need to run cosmic-comp or cosmic-session with an environment variable to get this log output?
ids1024
commented
9 months ago Oh yeah. dbg! will just be written to stderr, not journald. Something like ./target/release/cosmic-comp 2>&1 | tee log-file is what I often use to test that sort of thing. Something like tracing::error! will instead write to both journald and stderr.
jokeyrhyme
commented
9 months ago Okay, I instrumented the start of cosmic-comp::main() and cosmic-comp::wayland::protocols::drm::WlDrmState::bind() , as well as the body of the for loop in the latter
I can see that bind() is called multiple times when trying to run cosmic-term, but there is no output from inside the loop, so I assume this means global_data.formats is empty
ids1024
commented
9 months ago Seems AMDVLK recently dropped support for older graphics, including the Renoir APU I have handy, but https://github.com/GPUOpen-Drivers/AMDVLK/releases/tag/v-2023.Q3.3 works.
I am able to reproduce the issue easily with that.
ids1024
commented
9 months ago Ah, so .filter(|f| f.modifier == Modifier::Invalid) ends up filtering out all of the formats. ("Invalid" here means formats that work with an "implicit dmabuf modifier".)
Removing that gives me wl_drm@53: error 2: buffer import failed instead. Presumably Mesa's EGL failed to import the dmabuf.
I could make sense that Mesa is requiring explicit modifiers for import while AMDVLK needs wl_drm which doesn't support them, but then if other compositors work with the same drivers, I'm not sure what they're doing differently.
ids1024
commented
9 months ago https://github.com/Smithay/smithay/pull/1274 seems to fix this.
i509VCB
commented
9 months ago Also an issue to see if amdvlk will implement zwp-linux-dmabuf-v1: https://github.com/GPUOpen-Drivers/pal/issues/96
ids1024
commented
9 months ago Yeah, AMDVLK should move to the dmabuf protocol, and probably make use of explicit modifiers. wl_drm is basically a deprecated API at this point, and Mesa and compositors are interested in dropping support for it once it's no longer needed anywhere.
RADV likely offers overall better Wayland support, though there is still more to improve in Mesa's Vulkan and EGL Wayland WSI support.
ids1024
commented
9 months ago This should be fixed now that the Smithay PR is merged, and cosmic-comp has updated Smithay.
jokeyrhyme
commented
9 months ago I can confirm that this is fixed for me: https://github.com/pop-os/cosmic-epoch/pull/186
cosmic-termto be unable to be launched from anywhere where environment variables are unable to be customised (e.g.cosmic-launcher,cosmic-app-library, etc)launching
cosmic-termorAMD_VULKAN_ICD=AMDVLK cosmic-termresults in the following error:all of these do work, however:
AMD_VULKAN_ICD=RADV cosmic-termworks just finecosmic-launcher, etcI do not expect this to be addressed in wgpu nor
cosmic-term(but awareness may be handy later)