You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
bevy_render: Pass DisplayHandle to wgpu for compositor-aware Instance creation
Multiple community members have asked me to look into persistent
`BadDisplay` crashes on `wgpu` when using its EGL backend in
conjunction with Wayland. Besides realizing that this backend is
quite literally the definition of Undefined Behaviour itself, various
hacks to patch the EGL context - which is compositor-specific - inside
the `Instance`/`Adapter` with the actual `wl_display` handle as soon
as a `surface` is created will not only void any previously created
GL resources, only the `Instance` handles are patched leaving any
previously queried `Adapter`s to reference destroyed EGL objects causing
those `BadDisplay` errors.
Solving that handle lifetime/ownership problem has yet to be done
(and is why crates like `glutin` exist...), but at the very least
we might as well create an `EGLDisplay` and `EGLContext` which is
compatible with the current compositor from the get-go, which is
what gfx-rs/wgpu#8012 allows callers to
do. This is one of the reasons why `raw-display-handle` split out
a `RawDisplayHandle` type and related enums: to know up-front what
compositor is used (telling X11 and Wayland apart, if both could be
used concurrently instead of letting `wgpu` "guess") and to use the same
`wl_display` compositor connection as `winit`.
There are alternatives available, which is why this and the related
`wgpu` PR is a draft to shake out some feedback. Anything that's
involving more complexity inside `wgpu`'s EGL backend should be
attempted incredibly cautiously if it weren't for a full rewrite on top
of a higher-level EGL abstraction.
0 commit comments