tauri-apps / tauri

Build smaller, faster, and more secure desktop and mobile applications with a web frontend.
https://tauri.app
Apache License 2.0
83.94k stars 2.52k forks source link

[docs] Documenting Nvidia problems in Tauri #9394

Open ImUrX opened 6 months ago

ImUrX commented 6 months ago

I'm making an issue so a document exists that includes problems seen in WebkitGTK2. I will be listing the errors I have found and fixes for them, and also problems that I find that are weird.

1. The most common one, not having nvidia_drm.modeset=1

This one is mostly needed in Nvidia versions that are < 545, I need to test but there is a new flag since then that is nvidia_drm.fbdev=1 which actually enables simpledrm once again, but I don't know if it works.

2. In newer WebkitGTK versions since WebGL2 was implemented, WebGL doesn't work

There a simple bypass for this, it's using Wayland, for some reason this actually only happens on X11. It really seems like a weird upstream error, but it's probably not gonna get fixed anytime soon as GNOME's efforts are mostly on Wayland nowadays


The next issues are more recent and require flags on the environment that make the behavior of WebkitGTK not use hardware acceleration or not DMABUF, I find this pretty bad tbh.

3. AcceleratedSurfaceDMABuf was unable to construct a complete framebuffer

Requires to have WEBKIT_DISABLE_DMABUF_RENDERER=1 in the environment, it seems to only happen on X11

4. The webview just dies on resize, there is no weird error output

Requires to have WEBKIT_DISABLE_COMPOSITING_MODE=1 in the environment, if it's happening in Wayland, your Webview is running on X11

5. WebGL no longer works even in Wayland

Your Webview is running on X11, try using xeyes if it can follow your cursor inside the Tauri window, then yeah, it's on X11


4 and 5 are weird as they both happen to me in EndeavourOS GNOME Wayland in latest version but when using an AppImage from Ubuntu 22.04 (Github Actions Image) and using Tauri 2 Beta 14. If I use a development build with the libraries that Arch Linux ships, it runs on Wayland perfectly. I don't know why, it probably needs to be another issue as it's a problem with the AppImage packaging not using Wayland

lincolnthalles commented 4 days ago

I stumbled upon this while trying to package a Flatpak with device=dri enabled. The issue doesn't happen when running the deb or AppImage.

Environment:

There's a janky way to prevent the issue by setting the environment variable WEBKIT_DISABLE_DMABUF_RENDERER before calling the Tauri constructor:

#[cfg(target_os = "linux")]
{
    if std::path::Path::new("/dev/dri").exists()
        && std::env::var("FLATPAK_ID").is_ok() // remove for non-Flatpak
        && std::env::var("WAYLAND_DISPLAY").is_err()
        && std::env::var("XDG_SESSION_TYPE").unwrap_or_default() == "x11"
    {
        // SAFETY: There's potential for race conditions in a multi-threaded context.
        unsafe {
            std::env::set_var("WEBKIT_DISABLE_DMABUF_RENDERER", "1");
        }
    }
}

A better way would be to use the WGPU crate 1 2 to make sure the output device is an Nvidia GPU.

Disabling the acceleration altogether also works.

Extra information

This seems to be related to the GNOME version. Flatpak allows you to set the runtime version. The issue doesn't happen with GNOME runtime 42 and 43 (both EOL) but happens from 44-47.