fullscreen egl

[ec1oud]

I wish it was possible to run on the Linux console, without a windowing system, as with Qt's eglfs platform.

On a raspberry pi, I'd probably be using gles in this mode, since vulkan on the pi 4 doesn't actually seem to be working yet (despite the claims) and I want to run a 64-bit OS (like Arch) and also have it working on the pi 3.

[kvark]

I don't know how this is supposed to work. If you can provide code samples and knowledge, we'd be happy to consider this! PRs would even be better :)

[niklaskorz]

This looks like a good reference: https://github.com/astefanutti/kms-glsl

Essentially, wgpu would have to do what a compositor is doing (Direct Rendering Manager -> Generic Buffer Management -> EGL).
Maybe it would be possible to pass a GBM surface to create_surface and initialize EGL on that? Then the initialization of DRM and GBM could be done outside wgpu using drm-rs and gbm.rs.

[niklaskorz]

I think we would also need to adjust Instance::init to use eglGetPlatformDisplayEXT(EGL_PLATFORM_GBM_MESA) for getting the display from GBM.

[niklaskorz]

Thinking about it, this might also be a nice step to allow the implementation of Wayland compositors on top of wgpu :) I think being able to switch between GLES 3 and Vulkan there could be particularly useful

[kvark]

Sounds like an interesting direction! Could you summarize the pros/cons of this?

[niklaskorz]

If you mean the pros and cons of writing a Wayland compositor on top of wgpu, I'm afraid I don't have enough Wayland experience to comment on the usefulness of using wgpu as a renderer there. It looks like https://github.com/Smithay/smithay is currently using OpenGL ES 2, and so does Sway / wlroots, but wlroots is working on Vulkan support. Maybe @PolyMeilex could chime in and give some thoughts about whether this would be interesting for the Smithay project?

Now regarding adding GBM surface support to wgpu, one issue I see is that only EGL supports GBM. Also, GBM is not supported by the proprietary NVIDIA drivers right now, but might be sometime in the future. EGLStreams on the other hand are supported by NVIDIA as an EGL extension (but by no one else).

Vulkan support for DRM would depend on the VK_EXT_physical_device_drm extension instead of EGL + GBM surfaces.

In that sense, it might be more interesting to automatically select between Vulkan+DRM, EGL+GBM or EGL+EGLStreams depending on what is supported by the system, instead of providing a GBM surface to wgpu that could only be used by the OpenGL backend.
Adding support for GBM surfaces would be more straight forward though and enable the described use case of running wgpu applications on a Raspberry Pi using OpenGL ES without Wayland or X11.

[PolyMeilex]

Thanks for a ping, I'm definitely interested in that.
First of all I'm not a maintainer of Smithay, so it's not really for me to decide if this makes sense, but I can share a few thoughts.

• I think that we should let the smithay handle the backend initialization, this part of Smithay is totally Wayland independent so we can use it for non-wayland use cases too, here is a simple example of how to get started with raw_drm: https://github.com/Smithay/smithay/blob/master/examples/raw_drm.rs
• At the moment in my compositor I'm using glow for rendering, so if I got glow running I don't see a reason why wgpu OpenGL backend would not work.
• Smithay has plans to support Vulcan in future too, so we could also use that instead of GLES later down the line.
• I personally would prefer to use wgpu for my rendering instead of glow, this way I could utilize the whole wgpu ecosystem for my needs, and Vulkan support in future would not require any changes in my rendering code.

TLDR: I think that there is no reason to duplicate efforts, we should share as much code as possible, a lot of smithay's backend APIs are Wayland independent, so I don't see a reason to not use them.

Maybe @Drakulix has something to add, he is the author of Smithay's backend code.

[nohenry]

Any update on this? I started implementing some DRM + GBM + EGL code for WGPU but I'm not an expert on any of these apis.

[PolyMeilex]

Any update on this? I started implementing some DRM + GBM + EGL code for WGPU but I'm not an expert on any of these apis.

Those could be interesting for this use case:

• There is ongoing PR to winit to add kmsdrm support: Initial kmsdrm support rust-windowing/winit#2272
• Same for glutin, based on work in winit: Initial kmsdrm support rust-windowing/glutin#1403

One other update would be, NVIDIA is now committed to supporting GBM, and as far as I know all compositors have dropped EGLStreams already. So this simplifies wgpu side a lot, only one API to support.

[nohenry]

Sick. Glad to see these. I'm going to familiarize myself with the wgpu codebase them start proper implementation.

[cwfitzgerald]

Unless interest suddenly spikes again, I'm going to say that we can support this today through importing external GL textures to wgpu - the code to make this happen would be so rarely tested that it wouldn't really be maintainable.