kmsro: driver missing

[notro]

MESA does not support hardware rendering with GUD.

$ journalctl --no-pager --boot /usr/bin/gnome-shell

Nov 23 00:49:11 fedora-1 gnome-shell[1279]: Running GNOME Shell (using mutter 44.6) as a Wayland display server

Dec 07 21:39:55 fedora-1 gnome-shell[2194]: MESA-LOADER: failed to open gud: /usr/lib64/dri/gud_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib64/dri, suffix _dri)
Dec 07 21:39:55 fedora-1 gnome-shell[2194]: kmsro: driver missing
Dec 07 21:39:55 fedora-1 gnome-shell[2194]: Added device '/dev/dri/card2' (gud) using atomic mode setting.
Dec 07 21:39:55 fedora-1 gnome-shell[2194]: g_hash_table_insert_internal: assertion 'hash_table != NULL' failed
Dec 07 21:39:55 fedora-1 gnome-shell[2194]: g_hash_table_steal_extended: assertion 'hash_table != NULL' failed
Dec 07 21:39:55 fedora-1 gnome-shell[2194]: MESA-LOADER: failed to open gud: /usr/lib64/dri/gud_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib64/dri, suffix _dri)
Dec 07 21:39:55 fedora-1 gnome-shell[2194]: kmsro: driver missing
Dec 07 21:39:55 fedora-1 gnome-shell[2194]: Failed to initialize accelerated iGPU/dGPU framebuffer sharing: Not hardware accelerated
Dec 07 21:39:55 fedora-1 gnome-shell[2194]: Created gbm renderer for '/dev/dri/card2'

Example MESA pull request that adds this for UDL among others: gallium: Add more drivers to the list of kmsro drivers

Forum thread that shows how to build MESA and test using Wayfire on Raspberry Pi: [solved] TinyDRM driver for ST7789VW based displays

Excerpt:

git clone https://gitlab.freedesktop.org/mesa/mesa
cd mesa
meson setup --prefix=/usr --libdir=/usr/lib/aarch64-linux-gnu build
meson compile -C build
sudo meson install -C build

Have you installed all the dependencies? The easiest way is to uncomment the "deb-src" lines from /etc/apt/sources.list and /etc/apt/sources.list.d/*, "sudo apt update", and "sudo apt build-dep mesa".

[samcday]

I started looking into this, I think it's not so simple.

I came up with a simple patch similar to the one you originally linked.

Once built, I confirmed the presence of /usr/lib/dri/gud_dri.so. I then confirmed that running this build of mesa resulted in the absence of the ESA-LOADER: failed to open gud: /usr/lib64/dri/gud_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib64/dri, suffix _dri) error.

However, the Failed to initialize accelerated iGPU/dGPU framebuffer sharing: Not hardware accelerated error is still present.

I think I know why. It's not enough to build a kmsro shim for gud, because kmsro requires some glue for each host driver.

My first clue was the fact that kmsro only gets built if one of a specific set of allow-listed drivers is also enabled. I worked around this by patching in an explicit --gallium-kmsro=true build flag.

Here's the glue: https://gitlab.freedesktop.org/mesa/mesa/-/blob/a29443dc/src/gallium/winsys/kmsro/drm/kmsro_drm_winsys.c#L83-123 ... So for each supported driver, when the kmsro shim thingie loads, it checks the driver name of the main GPU and calls into the appropriate thedriver_drm_screen_create_renderonly function.

Those renderonly functions only exist for the supported drivers. I'm not at all familiar with the mesa codebase in any capacity, so I have no idea how feasible it is to add the appropriate drm_screen_create_renderonly functions to i915 and amdgpu drivers, which I'd expect to be the typical drivers in use on a GUD host. And of course this whole thing would never work for the NVIDIA proprietary drivers I suppose. But also, "Fuck Nvidia" :)

[samcday]

Some brave soul attempted to add renderonly support to the Iris driver a couple of years ago: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9592

A lengthy and lively discussion ensued. The MR never landed.

I was already a huge Internet Fan of @alyssarosenzweig thanks to her superhuman and existential-dread-inducing awe-inspiring Asahi/AGX work. She suggested that the ideal approach would be to implement something in core Gallium so that the current explicit glue is not necessary (and thus i915/radeonsi drivers would support renderonly scanout shenanigans Automagically™). I agree and now I'm an even bigger Internet Fan of Alyssa Rosenzweig.

At any rate, given how niche a GUD display output is, it doesn't seem particularly feasible to accomplish what is scoped out in this issue. As of now, it would require per-driver code jiu-jitsu for each host driver. That needs someone with some serious Mesa codebase experience, and the chances of it making it through review seem poor.

Maybe the kmsro-generification magic will happen, which ought to pave the way for this.

In the meantime, I would imagine that a GUD display plugged into a Apple Silicon machine running Asahi Linux and using this ghetto Mesa patch I made this afternoon would have amazing hardware-accelerated performance. Though I don't have one of those around to test with...

Personally, my use case for GUD is to use it as a way of temporarily interacting with a headless machine for diagnostic porpoises. It would have been nifty if the display is also h/w accelerated, but I don't want it enough to wade any further into this!

[trapexit]

given how niche a GUD display output is

I think it could be a lot less niche with the right support. The DisplayLink space is not huge but I've seen a number of random folks with DisplayLink based tech. Even if only for Linux a USB based plug and play secondary display could be pretty handy.

[samcday]

I think it could be a lot less niche with the right support.

Absolutely agree. Didn't mean to sound dismissive of GUD, or to diminish it. What I meant was the i915 and radeonsi mesa drivers are deployed and running right now on like ... 10s of millions of desktops and laptops. kmsro was shipped back in 2019 and since then it seems that (other than the MR I linked previously) nobody has had a need for it to support those drivers. I wouldn't expect GUD to ever have more than a couple of orders of magnitude less users than i915/amdgpu, so it seems like it's gonna be a tough sell to make such a complex change, if the only use case is to support GUD.

Even if only for Linux a USB based plug and play secondary display could be pretty handy.

Funny you should say that. I've had this idea in the back of my head since I first discovered GUD: I wonder if it would be possible to implement the host side as a GOP protocol in UEFI land...

[notro]

Yes there are two parts to kmsro, the display and the gpu/render side. I was a bit suprised that amd and intel are not supported. kmsro driver: src/gallium/winsys/kmsro/drm/kmsro_drm_winsys.c

I just tried this on a Raspberry Pi 4: MESA_LOADER_DRIVER_OVERRIDE=vc4 wayfire-pi This did succeed in creating buffers. Then I enabled kmsro for gud in Mesa 24.1.0-devel which worked, BUT I was getting artifacts, "random" white pixels following the cursor. Going back to software rendering fixed it.

I didn't get the artifacts on Mesa 23.2.1-1~bpo12+rpt3 when setting the env variable. But I was getting these in youtube fullscreen on chromium:

EE 07-03-24 18:16:59.406 - [backend/drm/renderer.c:95] Failed to import source buffer into multi-GPU renderer

I haven't got much time to spend on this and given that intel and amd is not supported I'll just come back to this later and see if things have improved. I can't enable kmsro on gud without solving the artifact problem.

[samcday]

I went a little further in testing also.

In particular, I have a device (Samsung A5) running Linux 6.6 and Mesa 24.0.2. Freedreno is fully operational on this device, I confirmed with glxgears hitting vsync limit in fullscreen under phosh (Wayland compositor).

With a USB OTG adapter and a custom build of the kernel (to enable CONFIG_DRM_GUD) I was able to get another device (my Steam Deck) to show up as a GUD device.

With standard upstream Mesa, I was able to run glxgears on the GUD display:

sudo XDG_RUNTIME_DIR=$HOME/cage WLR_DRM_DEVICES=/dev/dri/card1 cage -- glxgears -fullscreen

It ran okay, around 30fps with lots of complaining from Mesa about the fallback to swrast.

I then patched Mesa to enable GUD kmsro and tried the above command again. This time, I got a blank screen :( I didn't debug any further though.

[samcday]

Also, I was curious just how hard it might be to support kmsro in radeonsi. I managed to hack something up that compiles and links correctly ... but segfaults as soon as it's used xD

Maybe it'll be useful to someone who actually knows wtf they're doing or has more energy to push it further: https://github.com/samcday/mesa/compare/insanity?expand=1

I think the way I patched the various parts of amdgpu init are (somewhat) sound? I don't really understand the existing radeonsi get_resource logic though. I just cargo-culted what the asahi AGX driver is doing. Problem is, all existing usages of kmsro are in drivers that are only renderonly. So the get_handle logic in those drivers is wildly different to radeonsi.

(Also if there's someone who is good at mesa and open to mentoring I'd maybe be interested in pursuing it further)