GLOVE: GL Over Vulkan

[Redneckerz]

I came across this when reading that the company behind GLOVE (Hereafter Glove) is working on a RISC-V based GPU that uses this middleware as translation layer for OpenGLES support.

Context for other users:

• GZDoom 4.0.0 introduced an in-progress Vulkan renderer and currently targets OpenGL 3.3 and above.
• LZDoom is a legacy build targeting OpenGL 2.0.

For who this might be for?

• Graf Zahl
• Dr.Frag
• Rachael (Either as something to look into for her experimental testbed QZDoom, or for her Raspberry Pi build.

What this is :



''GLOVE (GL Over Vulkan) is a cross-platform software library that acts as an intermediate layer between an OpenGL ES application and Vulkan.

GLOVE is focused towards embedded systems and is comprised of OpenGL ES and EGL implementations, which translate at runtime all OpenGL ES / EGL calls & ESSL shaders to Vulkan commands & SPIR-V shader respectively and finally relays them to the underlying Vulkan driver.

GLOVE has been designed towards facilitating developers to easily build and integrate new features, allowing at the same time its further extension, portability and interoperability. Currently, GLOVE supports OpenGL ES 2.0 and EGL 1.4 on Linux and Android platforms, but the modular design can be easily extended to encompass implementations of other client APIs as well.

GLOVE is considered as a work-in-progress and is open-sourced under the LGPL v3 license through which it is provided as free software with unlimited use for educational and research purposes.

Future planned extensions of GLOVE include the support for OpenGL ES 3.x and OpenGL applications.''



Pro's:

• It is open source.
• It supports multiple platforms (Android, Linux, Windows) with an emphasis on embedded platforms. Stuff like Raspberry Pi might apply for this.
• Various desktop cards provide support for OpenGLES 2.0 and up. See the Khronos Compatibility list below.
• It may provide a legacy layer on GZDoom for older cards that can support OpenGLES 2.0 to be run through Vulkan. (This may nullify LZDoom somewhat considering the API that is targeted. Given how GZDoom targets OpenGL 3.x (Which isn't supported, see below. Also, if an older card has OpenGLES 2.0 support, it does not mean it can also run Vulkan. GLOVE in GZDoom's case would work best on cards that support both OpenGLES 2.0 and Vulkan. See the ''Tested with the following configurations'' part in the Github link.
• It may provide an additional method on LZDoom to support modern API's (Vulkan) yet still maintain legacy OpenGL(ES) support.

Cons:

• GLOVE as it is currently is still in development, so features may change over time and it may not mesh well with GZDoom's Vulkan renderer.
• It currently is limited to OpenGLES 2.0 and EGL 1.4. These are supported on most graphics cards, but mainstream OpenGL as is in use by GZDoom and LZDoom is currently not supported. )
• LZDoom targets OpenGL 2.0. Cards of this age are definitely not able to run Vulkan and may not have direct OpenGLES 2.0 support (Though AMD seems to have a seperate driver for this) but there might be code present that can be useful.

Conclusion:
I am not presenting this as something that has to be included in any of the ports mentioned, but i do think that as a suggestion it might be useful to look into. Its open source after all, so perhaps there is something there that could help either port. In either case, that was the intent of this thread, to suggest this to the mentioned authors.

Links:

• Github: https://github.com/Think-Silicon/GLOVE
• Think Silicon (Includes further documentation and downloads): https://think-silicon.com/tsi-products/software/glove/
• GLOVE Demo's: https://github.com/Think-Silicon/GLOVE/ ... E_demos.md
• Khronos compatibility list to verify which desktop GPU's support OpenGLES 2.0 and up: https://www.khronos.org/conformance/ado ... s/opengles

[dpJudas]

Porting the OpenGL renderer to OpenGL ES 2.0 to get vulkan support seems pretty silly when we already have a working vulkan renderer. You may call it "in progress", but I call it stable at this point. It has a few outstanding issues (read: bugs that affects some cards/drivers), but so does the OpenGL renderer.

That leaves the only reason for GZD to target OpenGL ES 2.0 the mobile phone market and some exotic ARM things like the raspberry pi. Unfortunately GPU's that only support ES 2.0 generally don't have the horsepower to drive the GZD 4.0 shaders acceptably anyway. They also don't tend to support textures that aren't power of two, which is a problem for Doom.

[Graf Zahl]

OpenGL ES 2.0 means this is a dead end - it's yesterday's technology that's far behind GZDoom's minimum requirement. If they had at least chosen GLES 3.0 or 3.1 it might be interesting, but it seems to me that the makers of this thing either have a different target audience in mind or belong to that particularly annoying group of developers who measure success not by quality but by trying to be as compatible as possible with old shit.

I very much approve the idea of providing a wrapper around Vulkan, but this one falls quite short due to its outdated scope.

[dpJudas]

Wrapping Vulkan makes sense, but basing around any version of OpenGL would be pretty dumb. Maybe 4.5 could be acceptable, but even then its still a pretty awful API.

[Graf Zahl]

4.6 would be ok, if they use the stateless variants, but only if they lifted the no multithreading limitation and added a command buffer API. So no luck there. without a command buffer API Vulkan is mostly pointless.

This thing is clearly meant for porting existing software, not writing new one.

[Redneckerz]

Porting the OpenGL renderer to OpenGL ES 2.0 to get vulkan support seems pretty silly when we already have a working vulkan renderer. You may call it "in progress", but I call it stable at this point. It has a few outstanding issues (read: bugs that affects some cards/drivers), but so does the OpenGL renderer.

I went by GZDoom's 4.0.0 description for that. It likely is outdated since obviously.

That leaves the only reason for GZD to target OpenGL ES 2.0 the mobile phone market and some exotic ARM things like the raspberry pi. Unfortunately GPU's that only support ES 2.0 generally don't have the horsepower to drive the GZD 4.0 shaders acceptably anyway. They also don't tend to support textures that aren't power of two, which is a problem for Doom.

On mobile phones (Or TV boxes) the only current GPU is Mali 400-450 that only has OpenGLES 2.0. The lowest performing Mali OpenGLES 3 equivalent would be Mali T720, so atleast on that side, OpenGLES 2.0 only hardware seems to be on their way out. OpenGLES 3 is becoming increasingly more common, together with Vulkan support.

As for the non power-of-two textures support, I did read that either PowerVR or Mali supported this, but its likely the more recent Mali's like G31 and G5x, which already support Vulkan natively.

I may not have been perfectly clear towards who this might be for, but on the outlook, it does seem to have some benefit - Likely not for GZDoom now due to it supporting OpenGLES 2.0 only, but this is very likely to change anyway. But more for legacy ports, RaspZDoom, and perhaps QZDoom if one would want to experiment with this stuff.

OpenGL ES 2.0 means this is a dead end - it's yesterday's technology that's far behind GZDoom's minimum requirement. If they had at least chosen GLES 3.0 or 3.1 it might be interesting, but it seems to me that the makers of this thing either have a different target audience in mind or belong to that particularly annoying group of developers who measure success not by quality but by trying to be as compatible as possible with old shit.

I very much approve the idea of providing a wrapper around Vulkan, but this one falls quite short due to its outdated scope.

It is still in development, after all. Furter OpenGLES 3 support is definitely planned - And might come as early as next year.

This thing is clearly meant for porting existing software, not writing new one.

Very much a no for GZDoom then and i expected this - It was purely as a ''Hey, perhaps this has something useful'' for that port alone. Given GZDoom's angle i didn't exclusively consider GLOVE for it. But how about LZ or QZDoom?

[Graf Zahl]

Very much a no for GZDoom then and i expected this - It was purely as a ''Hey, perhaps this has something useful'' for that port alone. Given GZDoom's angle i didn't exclusively consider GLOVE for it. But how about LZ or QZDoom?

QZDoom is not a product, it's a testbed fork of GZDoom.
LZDoom has its niche and I doubt that drfrag is interested in redoing the entire renderer. Ultimately it boils down to "why bother?" We already have a working Vulkan renderer and it delivers on what it was primarily made for: Improve performance on non-NVidia hardware by magnitudes.

[Redneckerz]

QZDoom is not a product, it's a testbed fork of GZDoom.
LZDoom has its niche and I doubt that drfrag is interested in redoing the entire renderer. Ultimately it boils down to "why bother?"We already have a working Vulkan renderer and it delivers on what it was primarily made for: Improve performance on non-NVidia hardware by magnitudes.

• Regarding QZ: This is stated in the OP and its partially why i included Rachael into this. Because it isn't a unique edge case for GZDoom and i considered GZ the least likely fit for this because of the OpenGLES 2 support, but OpenGLES 3 seems to be in the pipeline, so i figured it wouldn't do much hurt to make you aware of this port for the time being.
• Regarding the bolded: That isn't what this does. It is a translation layer for GLES to Vulkan, it isn't a renderer as is. If the OP isn't clear enough to distinguish this, please let me know.

[Rachael]

Talk about all the right enthusiasm in all the wrong places.

I'm going to have to side with dpJudas and Graf on this one. We never have, and never will support OpenGL ES 2.0. The only person who would even be remotely interested in something like this is beloko, and that's only if he never upgrades his GZDoom base for his android port.

I see absolutely no point whatsoever in supporting this feature.

LZDoom has its niche and I doubt that drfrag is interested in redoing the entire renderer. Ultimately it boils down to "why bother?" We already have a working Vulkan renderer and it delivers on what it was primarily made for: Improve performance on non-NVidia hardware by magnitudes.

^ And this, too ^

Furthermore, as of my last check, the Raspberry Pi does not yet support Vulkan. Maybe when the Pi5 comes out, but I wouldn't hold my breath. So this project has absolutely no interest there, either.

[Redneckerz]

Talk about all the right enthusiasm in all the wrong places.

I'm going to have to side with dpJudas and Graf on this one. We never have, and never will support OpenGL ES 2.0. The only person who would even be remotely interested in something like this is beloko, and that's only if he never upgrades his GZDoom base for his android port.

I see absolutely no point whatsoever in supporting this feature.

Hmm. Then in all my enthusiasm (in all the wrong places) i didn't connect very obvious dots. Apologies. Though, there is OpenGLES support on desktop cards, but as is then it its defunct.

^ And this, too ^

Furthermore, as of my last check, the Raspberry Pi does not yet support Vulkan. Maybe when the Pi5 comes out, but I wouldn't hold my breath. So this project has absolutely no interest there, either.

I am not sure why you side with Graf on the notion that this is a Vulkan renderer as Graf thinks it is, because it isn't.
Except for the recent Pi4, you are right. It is Vulkan capable, however:

https://preview.redd.it/a7btwoqr0u631.j ... 237733f585

Talking about being a informational dud Again, apologies. Perhaps when this gains Open GL3 of GLES 3 support, it is worth mentioning it again.

[Graf Zahl]

I am not sure why you side with Graf on the notion that this is a Vulkan renderer as Graf thinks it is, because it isn't.
Except for the recent Pi4, you are right. It is Vulkan capable, however:

We are fully aware that this isn't a Vulkan renderer. But the point still stands. We already support Vulkan natively. Why should we support a wrapper targeting an outdated API? It won't have any benefit for GZDoom at all. GZDoom requires OpenGL 3.3 and GLES2 simply doesn't cut it, no matter whether this targets native GLES hardware or Vukan or whatever.

I also don't get what these wrapper developers want. If they want to support modern hardware, an old API is the worst way to go. Most potential customers who aren't involved in mobile will take a hike.

[Redneckerz]

We are fully aware that this isn't a Vulkan renderer. But the point still stands. We already support Vulkan natively.

That's clarified then. I was under the assumption that you considered this a renderer too as per your earlier post.

Why should we support a wrapper targeting an outdated API? It won't have any benefit for GZDoom at all. GZDoom requires OpenGL 3.3 and GLES2 simply doesn't cut it, no matter whether this targets native GLES hardware or Vukan or whatever.

I also don't get what these wrapper developers want. If they want to support modern hardware, an old API is the worst way to go. Most potential customers who aren't involved in mobile will take a hike.

To answer the question:
That was not perse the intent of this thread. It was more an, like i said: ''Hey, perhaps this is useful'' instead of ''Hey Graf, you need to support this, regardless of what its contents are.''.

As per the OP, GLOVE is used to make OpenGLES/Vulkan support possible on their RISC-V GPU, and its also used for easifying porting. As mentioned, Currently they support OpenGLES2 and EGL 1.4, but they are planning to support OpenGLES 3 and OpenGL. Considering the relative infancy of this project and its relatively quick progression, its partially why i linked this. Not because it has uses for GZDoom now, but like i said, more as an ''Hey, perhaps this is useful'' bit, with the idea that more modern API support is on the rise.

Perhaps the last bit should have been clarified further.

[Rachael]

I can understand wanting to be helpful - but you're trying to solve a problem that's already been solved.

Also, if the Pi4 does indeed support Vulkan, than nothing needs to really be done. GZDoom will just compile on it natively.

[Graf Zahl]

Let's phrase it this way: If we could get a Vulkan wrapper that covers all the warts and bumps of a low level API we might be interested, but I don't have much hope here.

[Redneckerz]

I can understand wanting to be helpful - but you're trying to solve a problem that's already been solved.

Also, if the Pi4 does indeed support Vulkan, than nothing needs to really be done. GZDoom will just compile on it natively.

Yes, chalking it off on missing a very obvious point. Still, in the worst case - There is a topic now, if it ever gets useful, atleast its here.

Ill do better next time, promised

Let's phrase it this way: If we could get a Vulkan wrapper that covers all the warts and bumps of a low level API we might be interested, but I don't have much hope here.

That was indeed the original gist, except that this has warts and bumps. And its not tailor made If this gets an update or progression to the point you just mentioned, ill certainly will give you a call.

Thanks to the both of you and dpjudas for all the responses.