How to limit function calls to OpenGL ES specification natively?

I would like to limit my function calls to the OpenGLES 2.0 specification only without any proxy libraries (i.e. without using ANGLE).

Currently I have GLFW and glad create the window plus context but am unsure whether I am able to just request an OpenGLES context or if there is a limiting factor I am not considering.

I understand that many desktop GPUs now support OpenGL ES contexts. I also understand that there are extensions to add OpenGLES functionality in the majority of GPUs.

Am I able to request an OpenGLES 2.0 context or an OpenGL context with OpenGLES functions only (non-ES functions removed) to ensure compatibility with mobile?

If not, what is the best way to limit myself to OpenGLES natively without any proxy libraries or middle man?

Thanks!

I also understand that there are extensions to add OpenGLES functionality in the majority of GPUs.

OpenGL ES is strictly less capable than desktop OpenGL. They don’t need to add anything.

Am I able to request an OpenGLES 2.0 context or an OpenGL context with OpenGLES functions only (non-ES functions removed) to ensure compatibility with mobile?

Well, yes; if an implementation supports WGL/GLX_EXT_create_context_es2_profile, then you can request an OpenGL ES context. Whether GLFW will let you do that is something best looked up in the documentation. But implementations can advertise such functionality.

But you should not assume that this means that you have ensured “compatibility with mobile”. Always test your code on the platform in question.

If not, what is the best way to limit myself to OpenGLES natively without any proxy libraries or middle man?

Well, if you’re not willing to use existing tools (I believe that GLAD can generate ES headers), then you have to write your own.

In many ways, yes. However, in general, this isn’t true.

For instance, the latest OpenGL still has yet to support ASTC GPU texture compression in the core spec, while OpenGL ES added this support years ago. Further, you can’t get ASTC support even with extensions on the latest NVidia and AMD GPUs, though many mobile GPUs support this through the GLES spec interface. So if you’re targeting mobile GPUs but testing on desktop GPUs and want to limit yourself to uploading the same precompressed textures to your desktop GPU as you’ll upload to your mobile GPU (without the perf hit of runtime transcoding or precompressing and pre-storing your textures in multiple GPU compressed texture formats), you’re left with the ETC2/EAC support added back in OpenGL ES 3.0 / OpenGL 4.3, which is significantly less capable.

Thanks both for the replies!

To elaborate; I am willing to use tools. I am more concerned with using proxies between my OpenGL calls which convert them to other graphics libraries. For example, Google’s ANGLE converts from GLES to D3D9 on Windows.

Do OpenGL extensions require hardware changes or is it common practice for drivers to implement extensions in software?

Also, I am wondering what the difference between the WGL/GLX_EXT_create_context_es2_profile and ARB_ES2_compatibility extensions are?
I believe, from reading, one allows you to create a literal OpenGL ES context and the other adds some OpenGL ES features to a desktop profile.

https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_ES2_compatibility.txt

https://www.khronos.org/registry/OpenGL/extensions/EXT/WGL_EXT_create_context_es2_profile.txt
https://www.khronos.org/registry/OpenGL/extensions/EXT/GLX_EXT_create_context_es2_profile.txt

It doesn’t seem like a big issue for drivers to implement OpenGL ES compatibility considering the major similarities. It all seems very messy with many abstraction layers.

Is it just WGL that is preventing the contexts from being created (as I don’t see a reason why EGL can’t be added to Microsoft Windows) or are there literal hardware issues with OpenGL ES running on some desktop GPUs?

[QUOTE=BingoBingo;1291561]I am wondering what the difference between the WGL/GLX_EXT_create_context_es2_profile and ARB_ES2_compatibility extensions are?
I believe, from reading, one allows you to create a literal OpenGL ES context and the other adds some OpenGL ES features to a desktop profile.[/QUOTE]

Something like that. The former is supposed to “mask off” GL functionality that isn’t present in the requested GLES version, while the ARB_ES*_compatibility extensions (where * = 2, 3, 3_1, 3_2) selectively add some (but not necessarily all) of the functionality missing from GL but present in that GLES version, to ease the testing of ported GLES code.

Emphasis on the “some”. For instance, the presence of ARB_ES3_2_compatibility doesn’t declare support for ASTC LDR, though GLES 3.2 supports that. You’ve got to check for KHR_texture_compression_astc_ldr to determine whether the implementation supports that. See the extension specs for clear documentation on what they each add (and do not add) support for.

Is it just WGL that is preventing the contexts from being created (as I don’t see a reason why EGL can’t be added to Microsoft Windows) or are there literal hardware issues with OpenGL ES running on some desktop GPUs?

Not sure what you mean. The former extensions just provide a way to create a GLES profile context using the WGL or GLX window system interface layers (common on Windows and Linux, respectively, where EGL is not common).

EGL is another window system interface layer more common on mobile platforms. NVidia’s Linux graphics drivers also support the EGL window system interface layer (on Linux at least). So there you’ve got a choice between creating a GLES profile context via GLX (via GLX_EXT_create_context_es_profile) or creating a GLES context via EGL.

Many thanks, I appreciate the reply!

The only last thing I am wondering if anyone can enlighten me on is:

It says WGL_EXT_create_context_es2_profile has 47% coverage, but the GLX_EXT_create_context_es2_profile equivalent only has 17% (from gpuinfo.org).

Is this because the GLX version only shows on GLX/Linux and the WGL version only shows on WGL/Windows? I am surprised the GLX is such low coverage compared to WGL?


I see that the same GPU, on similar Linux and similar driver versions, says it supports the GLX_EXT_create_context_es2_profile and the other says it does not. Confusing…

[QUOTE=BingoBingo;1291569]The only last thing I am wondering if anyone can enlighten me on is:

It says WGL_EXT_create_context_es2_profile has 47% coverage, but the GLX_EXT_create_context_es2_profile equivalent only has 17% (from gpuinfo.org).

Is this because the GLX version only shows on GLX/Linux and the WGL version only shows on WGL/Windows?[/QUOTE]

Yes, that’s part of it. The coverage percentage is apparently computed based on “all” reports ever collected over all time, even those

[ul]
[li]collected before these extensions were even defined 6 years ago, and/or [/li][li]collected on platforms for which the extension doesn’t even make sense (e.g. GLX on Windows), and [/li][li]counting multiple reports submitted from the same PC/OS install as separate reports. [/li][/ul]
So the coverage doesn’t really tell you as much as you might hope about how pervasive an extension is now, particularly for platform-specific WSI extensions.

You can look at how many Windows and Linux reports there have been (over all time) and compute a coverage for those extensions based upon that (incidentally, it’s 86.32% for the GLX extension on Linux and 61.56% for the WGL extension on Windows). But even that’s not ideal because as I said this statistic still includes reports submitted before those extensions were even defined and counts multiple reports per machine/OS install separately.

Instead, what I do when I’m considering whether to support (or require) an extension is to look back and see when it was first offered in GL drivers for the vendor(s) whose drivers I’m targeting, and base my decision on that (that same site, http://www.gpuinfo.org/, is very useful for that). If it’s been out for years, there’s no good reason in most cases that users can’t just update their GL drivers and get the support they need.

What I think would be really useful to get as a coverage statistic on gpuinfo.org is the percentage of reports submitted in the last 1 or 2 years which supported (or didn’t support) the extension. With that you could get a better feel for how pervasive an extension is nowadays on GL drivers that developers at least have been running lately.

I am surprised the GLX is such low coverage compared to WGL?

I think there are probably multiple reasons for that. Based on personal experience, I can tell you when I was doing full-time GL development on Linux for work, I never Downloaded the gpuinfo.org app and submitted reports. Just never got into it, and don’t even think I knew about the download package. However, when I flipped to doing GL dev on Windows a few years ago, I started submitting reports pretty much whenever I updated my GL driver. Part of the reason is the Windows binary “just works”. No need to go download other packages. Whereas the Linux binary requires shared libraries not delivered with the glcapsviewer executable. If you don’t have them, you need to go get and install them or build them. Yes, you can do that, but not everyone will take the time. Hopefully this illustrates how it might inhibit submission of reports on Linux versus Windows, slanting the report counts toward Windows.