GL Backend Integration Attempt With Bevy

[zicklag]

Hey there!

I'm trying to see if I can get the GL backend working with Bevy. So far I've gotten Bevy compiling with WGPU master and the vulkan backend can run the Bevy PBR examples. When I run with the GL backend, though, I get an error:

wgpu error: Validation Error

Caused by:
    In Device::create_buffer
    parent device is lost

I've traced the failure to this point in code:

wgpu/wgpu-hal/src/gles/device.rs

Lines 380 to 382 in e5142b3

	Ok(crate::BufferMapping {
	ptr: NonNull::new(ptr).ok_or(crate::DeviceError::Lost)?,
	is_coherent,

It seems to be trying to create a buffer and getting a null pointer instead, at which point it concludes that the device has been lost.

I was wondering whether it might be possible that the error is related to Bevy's multithreading. Looking around a little bit in the new GLES backend implementation it seems like there isn't anything stopping you from using Instance and Surface from different threads, but lots of OpenGL isn't actually thread safe right?

In the older gfx GL backend we had this Starc type that would wrap !Sync + !Send types and make them Sync + Send, but would panic if you tried to use them across threads. It seems like that isn't in there anymore. Does the OpenGL backend currently only work if you don't multithread?

If that's the case, could we have the GL backend spawn a thread that it would use to completely manage the GL context and then make the Instance and Surface structs handles of sorts that would contain senders to a channel that is used for commands to the GL context management thread? That way Instance and Surface could be legitimately Sync + Send because all they contain is a crossbeam_channel::Sender and all of the GL commands would actually happen in one thread and therfore be safe.

Not sure if that makes sense or if I'm misunderstanding something or maybe this is another issue entirely.

[kvark]

Hi! You are correct, the GL backend currently assumes that the device, buffers, and the queue are used on one thread, at least one at a time.

Do you have env_logger hooked up? By default, we route GL's debug logging to log, so it would tell us what went wrong with buffer mapping that returned NULL.

Your idea with a dedicated thread is worth considering. It's not clear, for example, how would a method like create_texture return a texture if the actual execution happens on another thread. Rolling out the full client-server ID management (like wgpu does in Gecko, for example), is a bit too heavy handed of a solution.

It's possible that EGL would be fine with us accessing the context from different threads at least as long as this access is externally synchronized. In this case, we'd add wrap the context in a Mutex, and that would be one way to proceed.

Finally, the last way to proceed would be to just document the multi-threading restrictions on the GLES backend. Maybe even turn it into a downlevel feature?..

[zicklag]

Do you have env_logger hooked up? By default, we route GL's debug logging to log, so it would tell us what went wrong with buffer mapping that returned NULL.

I do have logging hooked up, but unfortuntately there's nothing before the error other than the initialization logs. The immediately preceeding log is the list of downlevel flags supported by the backend.

It's possible that EGL would be fine with us accessing the context from different threads at least as long as this access is externally synchronized. In this case, we'd add wrap the context in a Mutex, and that would be one way to proceed.

After looking at the EGL spec I it looks like you have to make an EGL context current from whatever thread you use it on, so what I'm assuming happened with Bevy is that it tried to create a buffer from a different thread than it created the instance on, and on that thread, there is no current EGL context so the call just returned a null pointer, which cause the GLES backend to return the device lost error.

My next try, then, was to wrap the GL context in a struct that would call egl.makeCurrent on the GL context on dereference so that every attempt to use the GL context would make sure the EGL context was current for that thread. This worked fine in the single-threaded example, but then trying Bevy again ran into an EGL BadAccess error.

Checking the error against the spec says that you aren't allowed to make a context curent for one thread while it is current in another thread.

My next attempt will be to try and wrap the GL context in a mutex combined with a wrapper that will make the context current for that thread while the guard is alive and then make it not current when the guard goes out of scope. That way, not only do we have only one thread accessing the context at a time, but we make sure that the EGL context is only ever current for whoever holds the lock.

[zicklag]

I got the Bevy PBR example to run on OpenGL!!

We're not necessarily out of the woods yet, though, because the load_gltf example won't work. It fails with a BadAccess error from EGL when either creating a buffer or a texture and I'm not sure why yet. Hopefully it won't be too big of a problem.

---

Edit: All of the 3D examples seem to be running fine other than the load_gltf one ( and wireframe, due to missing downlevel features which is expected ) which is a good sign I think.

[zicklag]

#1729 and gfx-rs/naga#1144 make the final example work!