Conversation
Closes #17005 Release Notes: - Improved GPU context management: share a single context with multiple surfaces. ### High Level Blade got a proper support for Surface objects in kvark/blade#203. That was mainly motivated by Zed needing to draw multiple windows. With the Surface API, Zed is now able to have the GPU context tied to the "Platform" instead of "Window". Practically speaking, this means: - architecture more sound - faster to open/close windows - less surprises, more robust ### Concerns 1. Zed has been using a temporary workaround for the platform bug on some Intel+Nvidia machines that makes us unable to present - kvark/blade#144 . This workaround is no longer available with the new architecture. I'm looking for ideas on how to approach this better. - we are now picking up the change in kvark/blade#210, which allows forcing a specific Device ID. This should allow Zed users to work around the issue. We could help them to automate it, too. 2. ~~Metal-rs dependency is switched to https://github.com/kvark/metal-rs/tree/blade, since upstream isn't responsive in merging changes that are required for Blade. Hopefully, temporary.~~ - ~~we can also hack around it by just transmuting the texture references, since we know those are unchanged in the branch. That would allow Blade to use it's own version of Metal, temporarily, if switching metal-rs in the workspace is a concern.~~ - merged my metal-rs changes and updated Zed to use the upstream github reference --------- Co-authored-by: Mikayla Maki <mikayla@zed.dev> Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com> Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
|
I bisected the BadNativeWindow issue on gles wayland to this PR using bunnymark. Haven't tested X11 or or my nvidia system yet. Edit: X11 fails as well |
|
Yes, GLES support is a bit more difficult with this new API |
| const EGL_PLATFORM_XCB_EXT: u32 = 0x31DC; | ||
| const _EGL_PLATFORM_WAYLAND_KHR: u32 = 0x31D8; | ||
| const _EGL_PLATFORM_X11_KHR: u32 = 0x31D5; | ||
| const _EGL_PLATFORM_XCB_EXT: u32 = 0x31DC; |
There was a problem hiding this comment.
Is the removal of Wayland / X11 accidental or intentional?
|
Is the removal of Wayland / X11 from GLES accidental or intentional? A bunch of unused variabled in gles/egl: const _EGL_PLATFORM_WAYLAND_KHR: u32 = 0x31D8; blade/blade-graphics/src/gles/egl.rs Lines 11 to 13 in 8cd905b |
|
Some investigation on GLES issue: The engine initialization starts in The critical issue is that EGL display selection happens here, before any window is created. The code only checks what EGL extensions are available (like ANGLE or surfaceless) but has no information about whether the application will use Wayland, X11, or another window system. This lack of window handle awareness during context initialization leads to selecting an incompatible EGL display, which later fails when trying to create actual window surfaces. When the surfaceless platform is available, the code unconditionally selects it, creating a display optimized for offscreen rendering that cannot support window surfaces. This mismatch only manifests later when |
Closes #17005 Release Notes: - Improved GPU context management: share a single context with multiple surfaces. ### High Level Blade got a proper support for Surface objects in kvark/blade#203. That was mainly motivated by Zed needing to draw multiple windows. With the Surface API, Zed is now able to have the GPU context tied to the "Platform" instead of "Window". Practically speaking, this means: - architecture more sound - faster to open/close windows - less surprises, more robust ### Concerns 1. Zed has been using a temporary workaround for the platform bug on some Intel+Nvidia machines that makes us unable to present - kvark/blade#144 . This workaround is no longer available with the new architecture. I'm looking for ideas on how to approach this better. - we are now picking up the change in kvark/blade#210, which allows forcing a specific Device ID. This should allow Zed users to work around the issue. We could help them to automate it, too. 2. ~~Metal-rs dependency is switched to https://github.com/kvark/metal-rs/tree/blade, since upstream isn't responsive in merging changes that are required for Blade. Hopefully, temporary.~~ - ~~we can also hack around it by just transmuting the texture references, since we know those are unchanged in the branch. That would allow Blade to use it's own version of Metal, temporarily, if switching metal-rs in the workspace is a concern.~~ - merged my metal-rs changes and updated Zed to use the upstream github reference --------- Co-authored-by: Mikayla Maki <mikayla@zed.dev> Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com> Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
3 participants
Closes #82
TODO:
Begone the
init_windowedmethod. There is only oneinitnow. The other one is replaced bycreate_surface.