Thoughts on configurable EGL_ANGLE_explicit_context

[Mick Pearson]

I just have a few random ideas about EGL_ANGLE_explicit_context to share...

1) It would be much easier to use it with C++ if the context was the last argument so in can automatically default to a global variable. I don't see that as a problem if it's manually configured that way when building the library.

2) You may read this as nitpicking, but calling on eglGetProcAddress will pull in code from every extension and the lookup table (string table) in proc_table_egl_autogen.cpp, like for instance with /OPT:REF.

For this reason it would be nice to be able to control the behavior of support_egl_ANGLE_explicit_context in https://chromium.googlesource.com/angle/angle/+/refs/heads/main/scripts/gen_proc_table.py to omit one or the other versions. I did a quick test and excluding unused code dropped the debug build from 21MB to 14MB (with some extra non-ANGLE code) and then not calling eglGetProcAddress (but explicitly referencing every non-extension procedure) reduced the EXE by another third, down to 7MB. That reduction includes non-ContextANGLE extensions, but as you can see it's not completely insignificant, although doing optimizations might change the picture (increase or decrease.)

(For the record, dropping "ContextANGLE" from the string table would only save 10KB. Maybe not worth it then.)

P.S. If not for (1) I wouldn't write this letter. I think I would not use this extension without (1) because it would require pretty elaborate wrappers to make it work without explicitly passing the context to every call. Anyway, I hope someone's heard this.

[Geoff Lang]

Overall, I'm thinking that it's time to drop this extension. It doesn't currently have any users I'm aware of and other TLS optimizations we've made have lessened potential performance gains. The binary size alone is a good reason to remove it.

--
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/2f2e679b-5c19-4d49-b758-1a9fd66b2c4an%40googlegroups.com.

[Mick Pearson]

Okay (now I'm sad I even thought about it) but I kind of assumed this was for Google Chrome's WebGL implementation. Is the TLS read to pull the global context prohibitively expensive? I can see objections to why making the context the last argument/default would be undesirable (mainly leading to accidental misuse in multi-thread scenarios) and so it might just be a bloated way to avoid TLS when it 90% makes sense to just not build with TLS in the first place. If it's not for huge projects like Chrome that believe they need it it's probably not worth having.

[Mick Pearson]

Small correction, it seems avoiding eglGetProcAddress doesn't work in a full-fledged app (or probably even in a bare-bones functional app.) Maybe that's more ammunition for removing those doubles (ContextANGLE) outright.

[Hamish Arblaster]

I'm actually using EGL_ANGLE_explicit_context. It's because I like how it lets me specify the context every time. Is there a thread-safe way of not using it (I'm not aware of how it works with threads)? Also my solution to avoid it would probably be having to be call set context every time before another call since I'm using it from another language, would this be terrible for performance assuming calling the method call itself is trivial (ie. does it do nothing quickly when it already has that context)?

[Mick Pearson]

The context you pass has to match the "current context" on the given thread. That means using it is NOT thread-safe. I'm not sure how expensive it is to lookup the context pointer on the current thread for every stupid little OpenGL call (of which there are many) but it seems very extravagant. I wonder if in the 90s OpenGL was meant to support multiple contexts/threads at all, it seems like a poor design, but I think Khronos is still using it with its newer APIs. 

[Hamish Arblaster]

Thanks!

It's probably good (in my case) that it has a different current context for each thread because it means I don't have to worry about the thread changing between calls. I looked into the implementations of glGetError, eglGetError, and eglMakeCurrent and noticed that they were all extremely trivial (I only checked eglMakeCurrent for when it is already current, which will be 99.9% of my cases). So I made these calls use the .NET SuppressGCTransitionAttribute (which is bad for certain native calls, but okay when quick (at most 1ms) and other conditions eg. no I/O) to make the calls be almost instant rather than having to change the Garbage Collector mode for .NET which can take a few nanoseconds (when these calls are almost literally just a read value and return something) which wouldn't be good since I call it for every api call. Sadly I don't see a way to be able to completely avoid calling eglMakeCurrent each time since I can't garuntee that no native code has called it (and checking the thread may be an issue as well since .NET thread ≠ Native Thread). But I had a similar issue before with calling glGetError after every other gl api call as well (and similarly with egl), so now both of these can be faster.