Broken graphics in gpui with the GLES backend of blade-graphics

[lukaslihotzki]

Check for existing issues

• [X] Completed

Describe the bug / provide steps to reproduce it

1. Run zed with RUSTFLAGS="--cfg gles" cargo run --release to select the GLES backend of blade-graphics (on Linux).
2. The window looks like this (on the sway default background):

Environment

Cannot run palette action because of the build error

If applicable, add mockups / screenshots to help explain present your vision of the feature

No response

If applicable, attach your ~/Library/Logs/Zed/Zed.log file to this issue.

No response

[kvark]

I tested this when integrating Blade. The Send/Sync story is solvable on Zed side: OpenGL doesn't like us talking to it from different threads. The bigger issue is the use of storage buffers for the data on all draw calls. This is totally fine in Vulkan/Metal, but GLES would only be happy with it starting with GLES-3.1. And on that version, the shader translation wants to have the defined resource mapping between resource groups/bindings and GLES names. But Blade's EGL backend is not currently providing that mapping, since it's mostly made for WebGL.

So, basically, if we want to run Zed on GLES, we'll need to implement one of these:

1. add API for vertex buffers to Blade. This will slightly increase complexity of the API and affect the Metal backend a bit, but nothing too concerning.
2. make it gather and provide the resource mappings to Naga, similar to how Vulkan/Metal do it. This is simpler to get, and will allow current Zed/Blade code to be largely unchanged.

[kvark]

What is your motivation for this issue? Are you just running on a Vulkan-incapable hardware? Or just curiosity?

[lukaslihotzki]

I want to run this on Asahi Linux, which provides OpenGL ES 3.2, but not Vulkan.

[kvark]

I've finished implementing vertex buffer support in https://github.com/kvark/blade/pull/102. However it will need more groundwork in Zed if we are adopting this approach. We'll no longer be able to map structures one to one to the shader. We'll likely need to define new structures for storage now.

[lukaslihotzki]

In the current state, Zed compiles and some parts of the rendering process seem to work, so I updated this issue. The cause for the current issue may be explained in https://github.com/kvark/blade/pull/105.

[mikayla-maki]

@kvark What kind of Zed changes would be needed to support GLES? It's not a high priority on our side, but I'd like to get an idea of it :)

[kvark]

@mikayla-maki there are two paths here to consider:

1. GLES path for older desktops and phones. We can safely assume GLES-3.2 here with storage buffer support. This shouldn't require any graphics changes in Zed. The only tricky part is ensuring that we are accessing the graphics context on the same thread (which is possibly not the case when dealing with texture atlas...). The visual issues on the screenshots are something to fix in Blade's GLES backend, not Zed side.

2. WebGL2 path. We can only assume GLES-3.0 here. We can no longer rely on storage buffers as a way to get data into vertex shaders. I've implemented support for actual vertex buffers in Blade for this purpose, but it looks like it would be a lot of work on Zed side. We'd no longer be able to trivially use nested structures of data - it will be somewhat pervasive, but possible.

[lukaslihotzki]

I consider the original issue as fixed, now that OpenGL ES 3.2 is supported. Thanks to @kvark for doing this together!

OpenGL ES 3.1 should be supported too, but I haven't tested it. If not, it should be easy to fix. OpenGL ES 3.0 would be more work, replacing the SSBOs with Vertex Attributes. I think vertex attributes could describe the existing buffer structure, so changes would be needed only in the blade renderer to offer vertex attributes and in the shader to use them.

[kvark]

FWIW, I did add support for vertex attributes to Blade, so this path is open if we want to try it. However, it's going to be a pain to do, since Zed's per-instance data is a free-form structure with some depth higher than 1. It would require some proc macro magic to automatically map it to vertex attributes. It's all possible, just a lot of work, and not obviously needed right now.