Q: Query real platform post EGL_PLATFORM_ANGLE_TYPE_DEFAULT_ANGLE?

[Mick Pearson]

I can't seem to find a way to get the platform type from ANGLE, e.g. via EGL style extension. If EGL_PLATFORM_ANGLE_TYPE_DEFAULT_ANGLE is used I'd like to know what ANGLE decided on.

P.S. It wouldn't be practical to use dynamic_cast (on ANGLE's internals) to solve this problem, however I'm wondering if there's a reason angle::NonCopyable can't add `virtual` to its destructor (~NonCopyable) since that seems to prevent dynamic_cast from working on the classes that inherit from it on Windows. It "segfaults" on "pCompleteLocator was nullptr." which I read is the same result COM classes get because they use __declspec(novtable) on their abstract base. (Without dynamic_cast I just have to blind guess the abstract pointer matches the backend of the current context. It's not unreasonable but it's a bit dicey and not great coding practices maintenance wise.)

[Geoff Lang]

There is no simple query for this right now. You can look at the GL renderer strings though, they contain the backend API information.

On Sun, Jun 27, 2021 at 12:09 AM Mick Pearson <ho...@swordofmoonlight.net> wrote:

I can't seem to find a way to get the platform type from ANGLE, e.g. via EGL style extension. If EGL_PLATFORM_ANGLE_TYPE_DEFAULT_ANGLE is used I'd like to know what ANGLE decided on.

P.S. It wouldn't be practical to use dynamic_cast (on ANGLE's internals) to solve this problem, however I'm wondering if there's a reason angle::NonCopyable can't add `virtual` to its destructor (~NonCopyable) since that seems to prevent dynamic_cast from working on the classes that inherit from it on Windows. It "segfaults" on "pCompleteLocator was nullptr." which I read is the same result COM classes get because they use __declspec(novtable) on their abstract base. (Without dynamic_cast I just have to blind guess the abstract pointer matches the backend of the current context. It's not unreasonable but it's a bit dicey and not great coding practices maintenance wise.)

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/angleproject/e861c3d0-0c00-4139-a7a2-d9b375509efen%40googlegroups.com.

[Mick Pearson]

Thanks for letting me know. Thinking about what GL render strings could mean (I don't know I'm afraid) I wondered if typeid can work... I think the following code would yield a good enough identifier but it runs into the same "pCompleteLocator" problem on Windows, again I believe because ~NonCopyable isn't virtual. I think it would be very helpful to enable typeid and dynamic_cast on these types. I encourage you to consider it. We're at your mercy on the outside.

const char *tid = typeid(*(angle::Subject*)ed).name();  

[Geoff Lang]

Introspecting into ANGLE's internals is not an ideal way to do this.  ANGLE should be treated as an opaque GLES driver.  What is your use case? Why do you need to know the backend chosen?

To view this discussion on the web visit https://groups.google.com/d/msgid/angleproject/03af20c4-7cf8-4803-bd1b-b46e86200a60n%40googlegroups.com.

[Mick Pearson]

A simple explanation, as discussed is changing between ANGLE and opengl32 contexts. If ANGLE chooses OPENGL then the app needs to know ANGLE is making use of OpenGL behind the scenes. Or any of its extensions that query for native handles would be a crapshoot if you don't even know what the backend is. ANGLE could be more feature rich in this area and even offer an API that's separate from ES to deal with interoperability stuff. It's not just a way to like what, simulate mobile devices? It's more manageable for cross-platform games, etc. If it's good enough for browsers it's good enough for things like game systems. It can fill a role like Qt or wxWidgets does for window systems. My product is a game system (https://swordofmoonlight.itch.io/k) so it doesn't feel right to implement it in terms of another game system. Even if there was a good option (I don't think so) it would be a bit of an identity/brand crisis I think. OpenGL is more neutral in that regard. The other alternatives to OpenGL (e.g. D3D, Vulkan) all have tradeoffs. ES seems best to me even though its trade off is being unavailable off mobile devices. ANGLE solves that. So I look at it more like filling a void in this space. P.S. As for why to introspect? If a problem arises, I want to act, not throw up my hands, it's more agile to do that in the app than ANGLE. If I need to interact with the backend in a way that's not accounted for through extensions, in theory I can. When it comes to OpenXR it needs a visual backend, I think it only interacts lightly with them, but I want to be certain I can meet its needs, and if something comes up ES can't express, I would first write code against the underlying GPU interface (e.g. D3D) and if that makes ANGLE's view incoherent, I will write patch code against ANGLE's internals. I think this just comes with any kind of proxy system. Anything like wxWidgets you have to be able to get under the hood or you can't even even use it. What it does is it gives a single paradigm in which to work, and when that paradigm breaks down then you have to write some exception code against the underlying system. It reduces the burden, but it's never perfect. You can't be expected to tie your hands or just give up on using the proxy layer entirely as your alternatives.

[Mick Pearson]

Double-reply: I forgot I should have mentioned, I've been trying to rebuild ANGLE with some different options. I trolled the gn args list again, and one that caught my attention is use_rtti that is false by default. This seems like a more likely explanation for dynamic_cast and typeid failing. So it's pertinent here. [Unfortunately it takes a long time to build ANGLE's massive project space with a new args.gn (everything) and I've been hitting a roadblock when it gets to linking (which maybe it doesn't do before everything is compiled, yikes) that I think is most likely caused by setting angle_shared_libvulkan=false ... so I have to do one more run to see if use_rtti works out. Another good option I found is enable_iterator_debugging that I think will solve the _ITERATOR_DEBUG_LEVEL problem. I was looking for a way to just define these macros, which is something CMake offers that GN seems to not. If you ever add a static build recipe to the build help README  enable_iterator_debugging should be listed in there to be compatible with anything that's not Chromium/GN based.] Either way I do think ANGLE should have a built-in way to query its backend. It can query so many things.