Don't use VkSurface and EglSurface on supported platforms

[mahkoh]

On android, X11, and wayland it is possible to perform presentation without using VkSurface and EglSurface.

On windows, it might be necessary to not use VkSurface to achieve low latency presentation: godotengine/godot-proposals#5692

On android, AIUI, not using VkSurface and EglSurface is the recommended way to do non-trivial things. I do not have a reference for this at hand.

Removing the use of EglSurface would solve one of the sources of undefined behavior in the opengl backend.

Removing the use of VkSwapachain would remove potential undefined behavior related to swapachain creation. See for example KhronosGroup/Vulkan-Docs#2544 and the discussion in https://registry.khronos.org/vulkan/specs/latest/man/html/VK_KHR_win32_surface.html

Uses of a window object by multiple graphics APIs results in undefined behavior.

VkSurface and EglSurface are abstractions over the underlying platform and since wgpu is itself a much larger abstraction, it would not be unreasonable for wgpu to absorb the VkSurface and EglSurface abstraction layer where possible.

Some additional code would have to be written. I would estimate this to require no more than 5000 loc for android, X11, and wayland combined. Most of that code would be shared between vulkan and opengl. Some of that code would also be required if wgpu ever wants to be useful in surfaceless contexts.

The Mesa wsi and chromium source code can be used as examples. Chromium does not use VkSurface and EglSurface if possible.

[mahkoh]

On android, AIUI, not using VkSurface and EglSurface is the recommended way to do non-trivial things. I do not have a reference for this at hand.

KhronosGroup/Vulkan-Docs#2410 (comment)

[cwfitzgerald]

In general, with the exception of windows on vulkan, I think this is not worth the added complexity.

VkSurface and EglSurface are abstractions over the underlying platform and since wgpu is itself a much larger abstraction, it would not be unreasonable for wgpu to absorb the VkSurface and EglSurface abstraction layer where possible.

I think this is actually a fairly large increase in scope for wgpu. A vast majority of wgpu's code is cross platform some way and adding even more complexity (especially on platforms that few/no maintainers use) is a lot to ask.

On windows, it might be necessary to not use VkSurface to achieve low latency presentation

I've had some desire to have a DXGI/IPresentationManager swapchain on vulkan for these (and presentation timing) reasons, but haven't actually gotten around it. Some of this is documented in #2869. This is fairly straightforward and well defined code with some clear user-facing improvements, so I'm more willing to adopt this.

Removing the use of EglSurface would solve one of the sources of undefined behavior in the opengl backend.

I'm generally less sold on this - surfaces and presentation has always been a bit platform defined behavior and as long as we are using the apis in ways that platforms are happy with, I'm not too worried about strict definitions of defined behavior. I know we do have some issues on wayland, but there are solutions to this that don't involve completely rewriting surfaces (see #5505 and linked issues)

I would estimate this to require no more than 5000 loc for android, X11, and wayland combined.

This is actually a ton, nearly half a backend (and three more code paths) for nebulous gains. We're already pretty strapped for maintainership attention, and linux/gl attention is very sparse. If anything, we would want to use glutin to manage all of our contexts instead of doing it ourselves. GL is notoriously picky and needing to get context creation on many platforms airtight sounds like a total mess. Then we also need to think about platforms that aren't linux/android like OpenHarmony.

[MarijnS95]

Wouldn't this fit nicely with existing "render-to-texture" and texture-import APIs of WGPU, allowing to push that burden of (allocating and) importing and presenting the platform-specific textures on the user?

Same for the linked "extended presentation API" for frame-pacing/present-timing; depending on the platform this either exists on the windowing/platform side (winit) or the graphics side (wgpu). Perhaps we need an in between crate that abstracts this away without burdening winit/wgpu too much?

That said I've seen a lot of unnecessary (presentation-related) burden and overhead pushed to the Windows/Dx12 backend, making it quite painful to read this opposition on the Linux Vulkan/(E)GL side.

AFAICT OpenHarmony is "mostly" Android, i.e. the latter presentation API is already trivially simple and likely copies 1:1 to OpenHarmony.

[cwfitzgerald]

Perhaps we need an in between crate that abstracts this away without burdening winit/wgpu too much?

Yeah I've thought about that. I think I'm going to end up implementing a DXGI swapchain for vulkan so that it can be the default on windows, but doing it inside wgpu is always going to be more complicated than outside.

That said I've seen a lot of unnecessary (presentation-related) burden and overhead pushed to the Windows/Dx12 backend, making it quite painful to read this opposition on the Linux Vulkan/(E)GL side.

What in particular makes you say this, the presentation code in our D3D12 backend is pretty simple iirc.

[cwfitzgerald]

I'm going to close this in favor of #8354 as DXGI is the only platform that I think is reasonable to implement a custom surface for.