EGL BadDisplay when using Wayland

[valaphee]

Description
When running any example on Wayland using WGPU_BACKEND=gl it crashes with:

[2024-04-07T11:57:37Z ERROR wgpu_hal::gles::egl] EGL 'eglMakeCurrent' code 0x3008: eglMakeCurrent
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: BadDisplay', wgpu-hal/src/gles/egl.rs:305:14

Repro steps
WGPU_BACKEND=gl cargo run --bin wgpu-examples

Expected vs observed behavior
Running like it does on GL/Vulkan on X11 and Vulkan onWayland

Extra materials
backtrace.txt

Platform

[2024-04-07T11:57:37Z DEBUG wgpu_hal::gles::adapter] Vendor: AMD
[2024-04-07T11:57:37Z DEBUG wgpu_hal::gles::adapter] Renderer: AMD Radeon RX 6900 XT (radeonsi, navi21, LLVM 17.0.6, DRM 3.57, 6.8.2-arch2-1)
[2024-04-07T11:57:37Z DEBUG wgpu_hal::gles::adapter] Version: OpenGL ES 3.2 Mesa 24.0.4-arch1.2
[2024-04-07T11:57:37Z DEBUG wgpu_hal::gles::adapter] SL version: OpenGL ES GLSL ES 3.2

[AuthorityFX]

I'm getting a similar issue.

Surface isn't supported by the adapter.

[Friz64]

Okay I THINK I have acquired the arcane knowledge of what wgpu-hal/src/gles/egl.rs is trying to do.

I got it working, but I have committed some very cursed crimes in the process.

proof

Essentially the problem is exactly what the error is saying: BadDisplay. On Wayland, get_platform_display is currently fed with khronos_egl::DEFAULT_DISPLAY, here. When I use some "special unsafe debugging tricks" to get the winit window's display handle in there, that error disappears. And then when you completely disable this specialty here, it runs!

By "special unsafe debugging tricks" I mean I stored the display handle in a static beforehand, to be able to access it there. Obviously, a proper solution remains to be found.

I also tried modifying DisplayRef::Wayland to hold the display handle from test_wayland_display(), and then using that to get the platform display, but I think that behaves the same way as khronos_egl::DEFAULT_DISPLAY.

Sooo... I'm thinking the play might be to delay get_platform_display until we have access to the correct display handle in create_surface? Does that make sense? I don't know, I'm going to bed.

[tombh]

I'm sure this must be obvious to most, but I got the examples working with: WGPU_BACKEND=vulkan cargo run --bin wgpu-examples bunnymark

I'm on Asahi Linux (ie ARM64 and no Vulkan support) and just wanted to see the examples running, even though they're merely being emulated on the CPU (device_type: Cpu, driver: "llvmpipe").

My own wpgu project works fine using OpenGL, it's just the majority of the examples that seem to have a problem.

[BartBM]

Bump ^^

Same issue

[2024-09-02T17:32:10Z ERROR wgpu_hal::gles::egl] EGL 'eglMakeCurrent' code 0x3008: eglMakeCurrent
thread 'main' panicked at wgpu-hal/src/gles/egl.rs:298:14:
called `Result::unwrap()` on an `Err` value: BadDisplay

[2024-09-02T17:32:10Z INFO  wgpu_core::instance] Adapter AdapterInfo { name: "AMD Radeon RX 7900 XTX (radeonsi, navi31, LLVM 17.0.6, DRM 3.57, 6.8.0-41-generic)", vendor: 4098, device: 0, device_type: Other, driver: "", driver_info: "4.6 (Core Profile) Mesa 24.0.9-0ubuntu0.1", backend: Gl }
[2024-09-02T17:32:10Z INFO  wgpu_examples::framework] Using AMD Radeon RX 7900 XTX (radeonsi, navi31, LLVM 17.0.6, DRM 3.57, 6.8.0-41-generic) (Gl)

[jimblandy]

@MarijnS95 I don't want to distract you from the good work you're doing with #6152 and related topics, but: do you have any idea how we could make progress on this?

Is this just an upstream winit problem that we can't do anything about?

[MarijnS95]

@jimblandy I can surely take a look and comment on the implementation, when booted back into Linux in the coming days. It sounds like @Friz64 already grasped the problem in that passing DEFAULT_DISPLAY is not valid since the implementation now has no clue what Wayland "display connection" to use.

I did run raw-gles on Wayland successfully though (#6176 (comment)), but it uses its own initialization path and surface.

[MarijnS95]

Theoretically DEFAULT_DISPLAY is allowed, which simply creates a new socket as documented. But as also noted in "the specialty" linked by @Friz64, that wouldn't be compatible with a Surface created / "imported" from a different socket, hence this hack replaces the context in create_surface() 🤔

On a side-note, it's equally strange that eglMakeCurrent() is called with self.pbuffer = None, from Device::desotry_buffer() (while it lock()s/currents the context) during startup.

---

All in all it looks like wgpu got EGL/WGL context handling wrong. There is a reason raw-window-handle separated out RawWindowHandle from RawDisplayHandle, yet wgpu somehow only passes the latter around when a surface is created? This makes it impossible to correctly initialize a context API that is relevant to the current display connection (set up by winit or otherwise) and requires ugly hacks like fn open_x_display(), fn test_wayland_display() and recreating/overwriting the context.

To whomever is planning to fix these bugs, I recommend starting by deleting the entire gles module and using glutin to implement the context API going forward. A good starting point is its example which clearly highlights important platform differences.

---

EDIT: Just above the hack there's a call to ANativeWindow_setBuffersGeometry(). I equally don't understand why that's necessary, as the config/surface internally will make sure the backing buffer format of the buffer producer is selected/updated. From some testing very long ago (this may have been wrong), calling this function limits the available EGL configurations for that surface on future queries.

[BartBM]

Accessing the raw texture for sharing via DMA-BUF would still be possible after rewriting the gles module?
In this poc I export the raw WGPU OpenGL texture via DMA-BUF and use it in Slint or Glutin:
https://github.com/BartBM/wgpu-dma-buf/blob/main/src/texture_export_wgpu.rs

Some poc code for what I am using it

pub fn export_to_opengl_texture(texture: &Texture) -> Option<NativeTexture> {
    let mut native_texture: Option<NativeTexture> = None;
    unsafe {
        texture.as_hal::<hal::api::Gles, _, _>(|hal_texture| {
            if let Some(hal_texture) = hal_texture {
                if let wgpu_hal::gles::TextureInner::Texture { raw, target: _target } = hal_texture.inner {
                    native_texture = Some(raw);
                }
            }
        });
    }
    return native_texture;
}

pub fn export_to_dma_buf(adapter: &wgpu::Adapter, native_texture: NativeTexture, width: u32, height: u32) -> (TextureStorageMetadata, RawFd) {
    unsafe {
        adapter.as_hal::<hal::api::Gles, _, _>(|hal_adapter| {
            match hal_adapter {
                Some(adapter) => {
                    let raw_display = adapter.adapter_context().raw_display().unwrap().as_ptr();
                    let raw_context = adapter.adapter_context().raw_context();
                    let egl_instance = adapter.adapter_context().egl_instance().unwrap();

                    let fn_egl_create_image_khr = egl_instance.get_proc_address("eglCreateImageKHR");
                    let egl_create_image_khr = fn_egl_create_image_khr.expect("eglCreateImageKHR not present!");
                    let egl_function = std::mem::transmute_copy::<_, PFNEGLCREATEIMAGEKHRPROC>(&egl_create_image_khr);
                    let egl_image_khr: EGLImageKHR = (egl_function.unwrap())(
                        raw_display,
                        raw_context,
                        EGL_GL_TEXTURE_2D_KHR,
                        native_texture.0.get() as EGLClientBuffer,
                        std::ptr::null()
                    );
                    assert!(!egl_image_khr.is_null(), "eglCreateImageKHR failed");
...

[MarijnS95]

@BartBM the gles module has to be rewritten from scratch is what I'm saying :)

Depending on what your needs are, DMA-BUF sharing is also possible with Vulkan. Note that your repository appears to be private, I cannot access it.

[BartBM]

@MarijnS95 yes rewriting it is what I meant. Slint only supports displaying textures via GL, not Vulkan: https://releases.slint.dev/1.7.0/docs/rust/slint/struct.borrowedopengltexturebuilder that's why I was asking.. The other option is copying data via a SharedPixelBuffer but this is slow.

[grovesNL]

I'm not sure if this is helpful, but for context some of the original workarounds were attempting to support surfaceless/headless GL contexts for initial queries, then being able to optionally associate the context with a surface afterwards through whatever context-specific APIs were available for that platform (e.g., context sharing). The implementation may have drifted over time but that was the original intent at least.

glutin and surfman didn't support this use case at the time, so wgpu would have needed a separate API for GL to fit glutin's API. Maybe glutin supports this now though?

Some other background:

• Idiomatic OpenGL context directly on EGL gfx#3468
• OpenGL surface via surfman gfx#3151
• Is OpenGL Supported now? #450