port:mesa & port:libepoxy : provide and support EGL

[RJVB (René Bertin)]

A couple of patches to enable the building of (support for) EGL in port:mesa and port:libepoxy .

Not actually tested yet, but libEGL builds with only a source-level patch to replace some clock_gettime() functionality with (close) equivalents. Which may not even be required on 10.12 and up .

[RJVB (René Bertin)]

update for mesa 17.1.6

[RJVB (René Bertin)]

I've attached an update for Mesa 17.1.6 which also adds +llvmXY variants allowing to build the gallium swrast driver.

The main interest here is probably that this allows certain X11 applications to render to remote displays despite the Xquartz lack of GLX support. For instance, after building Qt5 for xcb, applications that require shared OpenGL contexts or similar less common features will fail on startup with a "failed to initialise GLX" error. When using EGL instead they will run normally.

[kencu (Ken)]

a duplicate request for EGL support here:

#70338

[RJVB (René Bertin)]

Replying to RJVB:

The main interest here is probably that this allows certain X11 applications to render to remote displays despite the Xquartz lack of GLX support.

Another potential (and maybe mostly academic) interest: running code that requires newer OpenGL versions than the venerable 2.1 version that Apple apparently never updated.

[kencu (Ken)]

the problem is there is no hardware acceleration for EGL like there is for GLX, so last time I enabled EGL, which is now trivially-easy to do, and built some things against it, it was absolutely dog-slow and (IMHO) seemed unusable.

The Apple video driver is not open-source, I read in the mesa mailing list, and so adding such support is apparently not trivial.

I heard there was some interest in the mesa groups about reverse-engineering the needed calls…not sure how far they got.

[kencu (Ken)]

Apple abandoned OpenGL for Metal, as you know, and puts their resources there.

[RJVB (René Bertin)]

Yes, the performance penalty can be cruel for demanding applications but doesn't have to be with modern CPUs if it is only for, say, some UI effects.

The trade-off between "doesn't work/unsupported" and "works but [tool] slowly" is up to users to make... (esp. if as you say enabling EGL support has become trivially easy).

EDIT: getting reasonable performance does require using the LLVM-based pipeline/whatever; last I upgraded my Mesa port it wasn't exactly trivial to set that up (but partly because of wanting to support the LLVM port of choice of course).

[kencu (Ken)]

I also ran into software that would check for EGL and use it if available, otherwise would fall back to GLX.

So things that currently work OK for us (via GLX) would actually suffer if macports enabled EGL.

As I recall, I checked through all this when creating the gtk4 port…. which has that behaviour.

[RJVB (René Bertin)]

That sounds like something that could be patched out, but it would make sense to hide Mesa EGL support in a +egl variant.

[Behinder (behinder)]

Thanks Rene Bertin I should rather contact you than Ken who is a moron :( This video ​https://www.youtube.com/watch?v=pZ_Ckgm0AVc suggest Apple Silicon have support for 4.6 and Ken is talking about ancient 2.1 ANd yet again conversation about "if macports add something then others will suffer..." attitude.

The whole point of MESA is to provide support for something that Apple haven't done. Also point of Vulkan is to create intermediate layer to translate OpenGL to Metal. Open source software was always about solving problems by community thanks to the code being open and easily modified and I see it's not the case here,so my point is valid - because Qemu is not able to provide on SIlicon Macs (which more and more people own) native acceleration in x86 mode it should be hidden and masked (similar as it is done on Gentoo) - let people intrested build stuff themselves and Macports focus on Intel like it always did.

Anyway I'm done - it is probably cheaper to get X86 device that making arguments nobody here listen to.

[RJVB (René Bertin)]

To be clear: I don't have any personal interest in "Apple Silicon" and more in "retro-computing" than in providing/supporting the latest/greatest/whatever.

Also, the idea that the point of Vulkan is to translate OpenGL to Metal is news to me. I wonder why it exists on Linux or MSWin at all in that case...

[kencu (Ken)]

Not much of what Behinder espouses is based in reality, so you can mostly pass on that.

As far as being a moron, I’ve been called worse… but emailing insults to my personal email is going to get you a suitable reaction, so you shouldn’t have been surprised by that.

[RJVB (René Bertin)]

I indeed wasn't surprised by your suitable (lack of) reaction ;)

As for the Mesa devs looking into EGL support on Mac: can one think of EGL as extended OpenGL and would it be feasible (and justifiable) to implemented it as such on top of the native OpenGL 2.1 layer?