OS X support for OpenGL ES 2 (GLES2) using ANGLE

[pem....@gmail.com]

Are there any plans to use ANGLE to allow OpenGL ES 2 support on OS X?

When writing some cross-platform C++ OpenGL ES 2 code from scratch, I found that OS X does not support pure GLES2.  Basically the issue I ran into is that I'm apparently required to use Vertex Array Objects (VAOs) for OS X even though GLES2 core profile does not support VAOs.  Described here ( https://stackoverflow.com/questions/26362232/building-opengl-applications-not-working-in-osx-10-9 )

[pem....@gmail.com]

Another example I ran into is that glGetString(GL_EXTENSIONS) works on GLES2 but not on OS X...  So on OS X I have to use glGetStringi(GL_EXTENSIONS, 0) etc

[pem....@gmail.com]

I'm also confused because OS X supports GL_ARB_ES2_compatibility (which I read is stand for OpenGL 4.1)...  Yet I'm still seeing these differences...

[Mark Callow]

On Sep 25, 2015, at 9:35 PM, pem....@gmail.com wrote:

GL_ARB_ES2_compatibility

All the items you mention are known differences and should be documented in the ARB_ES2_compatibility specification.

The non-working items are items that have been removed from core OpenGL and there was no desire to reinstate them in the compability extension. That these appear on OS X is because OS X only supports core profile. On Windows compatibility profile is the default. If you requested a core profile context, you would see the same issues.

    -Mark

[pem....@gmail.com]

@Mark: thank you for clarifying this

To me it seems very strange (nonsensical, bad design) that desktop OpenGL has an extension "ARB_ES2_compatibility" that does not actually give compatibility with ES2.  In other words, OS X has the extension "ES2 compatibility" but it does not actually have ES2 compatibility.  Sorry for the dumb question, but how could someone possible know that having the extension ARB_ES2_compatibility does not actually mean that the system has ES2 compatibility?

You Here is the specification ( https://www.opengl.org/registry/specs/ARB/ES2_compatibility.txt ).  It's long so I did a find for each of the "glGet" and "GL_EXT" and saw zero matches.  So the extension spec does not document this.

As for requiring a VAO to be bound...  I don't see anything about that either.

I hope I don't sound like a cynical newbie, but this seems broken to me.  The extension is called "ES2 compatibility" so one would assume it means "ES2 compatibility".  But in reality it actually means some subset of ES2 compatibility, and if you want to figure out what that subset is, it's not easy, and the method I've been using is to just try stuff and see what happens and to read message board posts (like stackoverflow.com)...  Rather than relying on the official documentation

[Corentin Wallez]

If you look at the extension's overview section, it is clearly stated that it will "ease the process of porting applications from OpenGL ES 2.0 to OpenGL", it doesn't say it provides full compatibility.

With respect to the Mac port, I'm currently working on porting ANGLE to Mac, but it is still very much work in progress. Issues you'd run into immediately is that the content is flipped and that resizing the window doesn't work.

--
You received this message because you are subscribed to the Google Groups "angleproject" group.
To unsubscribe from this group and stop receiving emails from it, send an email to angleproject...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Shannon Woods]

Regarding searching the extension specification for specific features: all of the GL, GLES, and related extension specifications omit the "gl" prefix to function names, the "GL" prefix to type names, and the "GL_" prefix to enumerants, as those prefixes are assumed to apply to all instances of these items. Searches for "glGet" will not turn up any results in any of the specifications, unfortunately.

For more context on what the differences between OpenGL ES 2.0 and what's provided by the compatibility extension, a good place to start might be the "Issues" section, near the bottom of the extension text. That will give some background on what issues were considered and how the final extension text was decided. Several of the issues concern differences between ES 2.0 and the core profile, and what the problems are with simply adopting the ES behavior.

On Monday, September 28, 2015 at 10:18:00 AM UTC-4, Corentin Wallez wrote:

If you look at the extension's overview section, it is clearly stated that it will "ease the process of porting applications from OpenGL ES 2.0 to OpenGL", it doesn't say it provides full compatibility.

With respect to the Mac port, I'm currently working on porting ANGLE to Mac, but it is still very much work in progress. Issues you'd run into immediately is that the content is flipped and that resizing the window doesn't work.

On Sat, Sep 26, 2015 at 4:50 PM, pem.list wrote:

@Mark: thank you for clarifying this

To me it seems very strange (nonsensical, bad design) that desktop OpenGL has an extension "ARB_ES2_compatibility" that does not actually give compatibility with ES2.  In other words, OS X has the extension "ES2 compatibility" but it does not actually have ES2 compatibility.  Sorry for the dumb question, but how could someone possible know that having the extension ARB_ES2_compatibility does not actually mean that the system has ES2 compatibility?

You Here is the specification ( https://www.opengl.org/registry/specs/ARB/ES2_compatibility.txt ).  It's long so I did a find for each of the "glGet" and "GL_EXT" and saw zero matches.  So the extension spec does not document this.

As for requiring a VAO to be bound...  I don't see anything about that either.

I hope I don't sound like a cynical newbie, but this seems broken to me.  The extension is called "ES2 compatibility" so one would assume it means "ES2 compatibility".  But in reality it actually means some subset of ES2 compatibility, and if you want to figure out what that subset is, it's not easy, and the method I've been using is to just try stuff and see what happens and to read message board posts (like stackoverflow.com)...  Rather than relying on the official documentation

--
You received this message because you are subscribed to the Google Groups "angleproject" group.

To unsubscribe from this group and stop receiving emails from it, send an email to angleproject+unsubscribe@googlegroups.com.

[pem....@gmail.com]

MetalGL now provides GLES2 support for OSX.  MetalGL is similar to ANGLE in that ANGLE translates Windows GLES2 to (the Windows native API DirectX), while MetalGL translates GLES2 to (the OSX native API Metal).  This makes (ANGLE for Windows) and (MetalGL for Mac OSX) complementary since they both map GLES2 to the OS's native API.

Meanwhile ANGLE might get ported to Mac OSX?  If that happens, then ANGLE and MetalGL will be competing in terms GLES2 support on OSX.

Meanwhile, OpenGL 4.3 provides "full compatibility" with OpenGL ES 3.0, so as everything transitions to OpenGL 4.3 and GLES3, so neither MetalGL nor ANGLE will be required for full compatibility of GLES3 on OpenGL 4.3 systems (eg OSX).

Meanwhile Vulkan is intended to replace OpenGL...

[Corentin Wallez]

Good analysis, but note that ANGLE will also provide OpenGL ES 2 for OSX "legacy" systems running an OSX version before 10.11 and OpenGL 4.3 (if that ever gets shipped on Mac). Also ANGLE deals with working around driver bugs.

--
You received this message because you are subscribed to the Google Groups "angleproject" group.

To unsubscribe from this group and stop receiving emails from it, send an email to angleproject...@googlegroups.com.

[Peter List]

Despite being called MetalGL, it also provides OpenGL ES 2 for OSX "legacy" systems where Metal is not available.  I'm checking out MetalGL largely just because ANGLE currently is not shipped on OSX.

[Mark Callow]

> On Sep 29, 2015, at 8:13 AM, Peter List <pem....@gmail.com> wrote:
>
> Despite being called MetalGL, it also provides OpenGL ES 2 for OSX "legacy" systems where Metal is not available. I'm checking out MetalGL largely just because ANGLE currently is not shipped on OSX.
>

What about OpenGL ES 3?

Regards

-Mark

[pem....@gmail.com]

GLES3 support seems to be lacking in terms of platform software.  GLES3 is supported by (Android, iOS), and I read GLES3 is supported on Windows (which is weird since GLES2 requires ANGLE?) (I haven't actually tried this).  However, I read GLES3 support is currently missing from (Windows ANGLE, OSX MetalGL, Linux Mesa3D, web Emscripten & Google Native Client).  In the case of  GLES3 Emscripten & Google Native Client, better WebGL 2 support is needed by browsers.

So at this time, GLES2 seems to have broader cross-platform support than GLES3.  I want to use GLES3 for a cross-platform project, but I'm finding that right now GLES2 seems to have broader cross-platform support than GLES2.

[pem....@gmail.com]

@Shannon or anyone: Is it stated it layman's terms anywhere that GL_ARB_ES2_compatibility does not actually provide full OpenGL ES 2.0 compatibility?  Having to interpret this very high-level thing from the low-level details described in the "issues" section of a long wordy spec seems circuitous.  I guess the "Overview" section does say "will ease the process of porting applications from OpenGL ES 2.0 to OpenGL", but I guess I would've liked something a bit more blunt :-p

Do you happen to know if GL_ARB_ES3_compatibility provides full OpenGL ES 3.0 compatibility?  Wikipedia makes the statement "OpenGL 4.3 provides full compatibility with OpenGL ES 3.0".  However the spec says "ease the process of porting applications from OpenGL ES 3.0 to OpenGL"...  So this makes me think wikipedia might be wrong?

[Mark Callow]

> On Oct 3, 2015, at 11:45 AM, pem....@gmail.com wrote:
>
> @Shannon or anyone: Is it stated it layman's terms anywhere that GL_ARB_ES2_compatibility does not actually provide full OpenGL ES 2.0 compatibility? Having to interpret this very high-level thing from the low-level details described in the "issues" section of a long wordy spec seems circuitous. I guess the "Overview" section does say "will ease the process of porting applications from OpenGL ES 2.0 to OpenGL", but I guess I would've liked something a bit more blunt :-p
>
> Do you happen to know if GL_ARB_ES3_compatibility provides full OpenGL ES 3.0 compatibility? Wikipedia makes the statement "OpenGL 4.3 provides full compatibility with OpenGL ES 3.0". However the spec says "ease the process of porting applications from OpenGL ES 3.0 to OpenGL"... So this makes me think wikipedia might be wrong?
>

Extension specs are written for OpenGL implementers not laymen or even users of the API.

“Ease the process” is indeed the key here. The issue of deprecated features is #1 in the issues list, so not that difficult to find. It’s resolution says:

> RESOLVED: No, these will not be brought back into OpenGL 4.x Core. Apps
> written for OpenGL-ES 3.0 that want to also be compatible with OpenGL
> should make sure they don't use these features.
That seems blunt and plain enough to me.

Wikipedia is wrong. You only get something like full compatibility when running on a "compatibility profile” OpenGL context. Even then there are issues. See Issue #2 in the spec. It’s resolution states

> RESOLVED: If the application needs a strict OpenGL ES 3.0
> implementation, it should not attempt to use a desktop GL context
> with the ES3_compatibility extension supported. Instead, use the
> {GLX|WGL}_EXT_create_context_es_profile extensions to request an
> actual OpenGL ES 3.0 context, which will not have these caveats.
Unfortunately not all implementations support {GLX|WGL}_EXT_create_context_es_profile.

I recommend you do what the resolution to Issue #1 recommends: avoid any of the listed features in your application. They are all deprecated and not the way forward for the future.

Regards

-Mark

[pem....@gmail.com]

What's the ETA on a desktop OpenGL rendering backend for OS X that allows me to run OpenGL ES 2.0 (GLES2) on OS X?

This page ( https://code.google.com/p/angleproject/wiki/Update20150105 ) mentions plans as of Jan 2015 for "additional rendering backends, allowing ANGLE to enable OpenGL ES not just over Direct3D 9 and 11, but also desktop OpenGL" ... "Work will now begin within ANGLE to add a desktop OpenGL renderer, and EGL implementations compatible with OS X and Linux."

GL_ARB_ES2_compatibility does not give full GLES2 support, so even simple GLES2 code requires modifications to run OS X.  I can run the same GLES2 code on (Windows ANGLE, Linux, Android, iOS, Emscripten) (and probably Windows 10 Mobile with ANGLE?), but on OS X I have to make aforementioned changes (eg use VAOs).  Btw I'm using C++, SDL2.  I'm excited about this possible option to write cross-platform GLES2 code (and maybe someday cross-platform GLES3 code) :-)

[Corentin Wallez]

We're hoping to have Chrome being able to render using ANGLE on OSX around the end of the year, it might however be using ANGLE-specific extension for the window-system integration. The OpenGL backend is already capable to run OpenGL ES 2.0 on core OpenGL.

[pem....@gmail.com]

On Windows for my (C++, SDL2, CMake, GLES2) project I did (git clone https://code.google.com/p/angleproject/) and my CMake build links to "angleproject\lib\Release\libGLESv2.dll".  I'd like to do this for OS X too, but I don't think ANGLE for OS X is ready yet?

[pem....@gmail.com]

PS: for windows-system integration I'm using SDL2 (Simple DirectMedia Layer)

[Corentin Wallez]

SDL2 will not support ANGLE on Mac yet as there has never been an EGL implementation on Mac ever (for example the native EGL type equivalent are not defined in the headers yet).

[Andrey Dj]

Good news!

I have proposed a patch here:

https://bugzilla.libsdl.org/show_bug.cgi?id=3975

среда, 21 октября 2015 г., 23:42:38 UTC+3 пользователь Corentin Wallez написал:

[Geoff Lang]

Very nice, let us know if you find any issues (and file a bug)

[Andrey Dj]

https://hg.libsdl.org/SDL/rev/bc7ca7cfa6ca

вторник, 28 ноября 2017 г., 18:25:10 UTC+2 пользователь Geoff Lang написал: