Is OpenGL Supported now?

[zicklag]

With #183 getting closed in wgpu-rs does that mean that OpenGL is now supported here and we can update the checkmark on the README?

[kvark]

GL was removed some time after we added it. Currently, it's not supported.
We'll be happy to accept patches that re-enable it. This may become a priority for us in the future, but it's not the most pressing thing right now.

[zicklag]

Cool, thanks for the clarification. 👍

I'm good with closing this then, unless you think it should be left open. 🙂

[kvark]

Well, we don't have an issue open for GL, so I'm thinking of leaving this one open.

[zicklag]

At this point, would all that is necessary to get this working be to add the GL gfx backend code just like the Vulkan backend code? I was just messing around with it ( I really hardly any idea what I'm doing ) and I think I got everything except wgpu-native to compile on Linux. With wgpu-native I hadn't figured out how to do the window creation for the GL backend yet.

I pretty much just went through and whenever there were feature gates for Linux I added a section that would use the Gl backend instead of the Vulkan backend if the GL feature was enabled. It was a little haphazard and needs to be organized, but as far as I can tell the last step was window creation.

Am I in the right direction or is there more that is going to need to be done?

[kvark]

@zicklag the problem here is to minimize any deviation from the existing paths. Ideally, the code should support GL fully transparently, but this requires gfx-backend-gl to be smarter about its surfaces, i.e. gfx-rs/gfx#3133

You can post your code as a draft PR, and we'll be happy to see if you are moving in the right direction :)

[zicklag]

OK, cool. After looking around more I see how the surface creation is unimplemented!(). I'll do some looking around to see if I can get a better grasp on the API. If I come up with anything I'll draft a PR.

[zicklag]

So, as far as I understand, as shown in the gfx quad example, you can create an OpenGL surface from a context, split from a windowed context, that was built with Glutin, but in wgpu-native I we already have a raw window handle that we want to create the surface for, and I don't know how to create a glutin Context from the raw window handle.

It looks like, if I can get a Context from the raw window handle, I will be able to create the Surface and there shouldn't really be any more code branching for GL at that point, similar to the Quad example.

Where should I look to find out how to go from RawWindowHandle to glutin Context?

[kvark]

The quad example also shows that we don't initialize the surface the same way on GL. It looks like we need something like raw-gl-handle here, so that we don't depend directly on glutin/sdl/glfw. And even with this, there would be a separate entry point like wgpu_create_gl_surface(RawGlHandle).

This is just the start of our problems though. In a typical GL the window is your context. So we wouldn't be able to enumerate adapters and create devices the way we do now, unless we either:

1. diverge the APIs (unfortunate)
2. fix the divergence at lower level by looking into OpenGL surface via surfman gfx#3133

[zicklag]

So I just found build_raw_wayland_context which looks like we could use that in the GL backends Instance.create_surface() to create a headless context that isn't tied to a window.

Then is Instance.enumerate_adaptors() not going to work for that?

As far as I can find that leaves all of the platform specific code in the gl backend and we wouldn't need a separate wgpu_create_gl_surface(RawGlHandle) because it can create the raw wayland context?

[kvark]

The raw wayland context is what you'd want to create (on wayland only) to back the Instance.
Then, when the user creates a surface, you'd want to back it with another context that is not pure and tied to a window, but also shares all resources with the original context of the instance. This is at least the way I could see it working.