Enable OpenGL software rendering on macOS

Wed May 4 12:21:26 UTC 2022

Thank you all for your answers.

Alyssa : I agree that Linux is easier to tackle, but I unfortunately can't ask to my clients to drop macOS support :) Do you mean that you finally stopped trying running Mesa on macOS?

Jose : I was indeed thinking of MoltenGL to keep OpenGL working on Apple GPU. My thought about Mesa/macOS is only for CPU rendering. JOGL architecture assume that the OS can provide a GL shared library so I would not build JOGL with Mesa but rather ensure that a GL shared library is available, either MoltenGL+Metal for GPU rendering, either Mesa tweaked to display a CPU processed image.

Envoyé avec la messagerie sécurisée ProtonMail.
------- Original Message -------
Le mercredi 4 mai 2022 à 13:34, Alyssa Rosenzweig <alyssa at collabora.com> a écrit :

> Having spent enough time wrangling Mesa/MacOS on Arm Macs....
>
> the correct solution is to migrate to Linux. everything else is pain.
>
> On Wed, May 04, 2022 at 12:38:55AM +0000, Jose Fonseca wrote:
>
> > I'm not sure exactly what Homebrew provides, and I'm not able to
> > investigate it now.
> > Yes, using Mesa software rendering to fill the void left by Opengl
> > deprecation makes some sense. But note is still software rendering, not
> > GPU accelerated. And one needs to consider the x86 -> arm.
> > You could consider somehow integrating jogl with osmesa -- offscreen
> > rendering -Mesa -- which builds and runs pretty much anywhere Mesa builds
> > -- thereby bypassing the headaches of integrating with mac specifics
> > technologies such as CGL and Cocoa
> > There are also other alternatives with considering, such
> > as https://moltengl.com/moltengl/
> > Jose
> > Get Outlook for Android
> >
> > ----------------------------------------------------------------------
> >
> > From: Martin Pernollet martin.pernollet at protonmail.com
> > Sent: Monday, May 2, 2022 1:31:43 AM
> > To: Jose Fonseca jfonseca at vmware.com
> > Cc: mesa-dev at lists.freedesktop.org mesa-dev at lists.freedesktop.org
> > Subject: Re: Enable OpenGL software rendering on macOS
> >
> > ** External Email
> >
> > Hi Jose,
> > Many thanks for your answer.
> > JOGL classes enabling GL binding macOS all refer to CGL, so yes, I think I
> > want to rely on CGL (there is however in JOGL a couple of classes allowing
> > to work with X11, but they're used on Linux only).
> > I can't access the Apple M1 on which I built Mesa right now, but homebrew
> > on another macOS provides libGL and not libGLX.
> >
> > ls /usr/local/Cellar/mesa/21.1.2/lib
> >
> > dri libGL.dylib libGLESv1_CM.dylib libGLESv2.dylib libglapi.dylib
> >
> > libGL.1.dylib libGLESv1_CM.1.dylib libGLESv2.2.dylib libglapi.0.dylib
> > pkgconfig
> >
> > One motivation for enabling Mesa on macOS is actually the deprecated
> > status of OpenGL. I would expect this software implementation of GL to
> > simply provide an image to be copied to a native window/frame, without
> > having to rely on CGL. Hence, one could continue working with simple
> > OpenGL even if macOS doesn't provide such API.
> > Does it sound reasonable?
> > Martin
> > Envoye avec la messagerie securisee ProtonMail.
> > ------- Original Message -------
> > Le vendredi 29 avril 2022 a 16:08, Jose Fonseca jfonseca at vmware.com a
> > ecrit :
> >
> > The difficulty with OpenGL on macOS is that all driver interfaces are
> > both undocumented and deprecated.
> > If you want to override the system OpenGL, you can use apitrace code as
> > reference. There are two approaches:
> > 1. DYLD_FRAMEWORK_PATH https://github.com/apitrace/apitrace/blob/master/cli/cli_trace.cpp
> > 2. DYLD_INSERT_LIBRARIES https://github.com/apitrace/apitrace/tree/dyld-interpose (experimental
> > branch)
> >
> > AFAIK, Mesa build for macOS generates a ibGLX which depends on X11,
> > which is probably not what you want. You want to use Mesa for macOS
> > apps which use CGL as opposed to GLX, right?
> > So, if one wants to have a SW renderer on macOS with llvmpipe without
> > depending on X11, then one would need to implement:
> > * a new Gallium frontend that implements CGL API (equivalent to the
> > WGL frontend that exists for Windows)
> > * a new SW renderer winsys that draws pixels to Cocoa window somehow
> > (equivalent to the GDI winsys that draws to a Windows GDI surface)
> > It's not a matter of just integrating existing components together --
> > there's lot of new code that would be need here -- I'd reckon 2 months
> > for somebody familiar with Mesa/macOS, 6 - 12 months for somebody more
> > novice. And let's be frank, given mac deprecation of OpenGL and
> > migration away from Intel to Arm, the usefulness of this in the long
> > term is dubious.
> > Jose
> >
> > ----------------------------------------------------------------------
> >
> > From: mesa-dev mesa-dev-bounces at lists.freedesktop.org on behalf of
> > Martin Pernollet martin.pernollet at protonmail.com
> > Sent: Friday, April 29, 2022 12:32
> > To: mesa-dev at lists.freedesktop.org mesa-dev at lists.freedesktop.org
> > Subject: Enable OpenGL software rendering on macOS
> >
> > ** External Email
> >
> > TLDR : I failed using Mesa software rendering on macOS. I am looking for
> > advice to invoke mesa's libGL.dylib without relying on macOS's system
> > GL.
> > Hi everyone,
> > I am building (java) software involving Mesa for CPU rendering. I use
> > CPU rendering as fallback when JOGL (OpenGL binding for Java) fail to
> > use the GPU natively. This is sometime the case for old Linux
> > distributions, this will certainly be frequent on macOS in the future
> > due to Apple's OpenGL deprecation.
> > Mesa CPU rendering is working great on Ubuntu (by enabling
> > LIBGL_ALWAYS_SOFTWARE=true) and Windows (by simply loading Mesa's DLL
> > instead of system DLL, no need to ask for software mode).
> > I however thrive to use Mesa's software rendering on macOS for the
> > following reasons
> > * Spying dynamic library load sequence shows that whenever Mesa's
> > libGL.dylib is loaded, Apple Metal and libGL.dylib are loaded
> > before, even when using DYLD tricks to ensure Mesa get loaded before
> > any other library (except the Java VM) [1] Someone says that Mesa's
> > macOS implementation relies on system GL [4]. I noticed that when
> > enabling LIBGL_ALWAYS_SOFTWARE=true, this activates Apple software
> > rendering but not Mesa's software rendering [5]. I wonder how I
> > could avoid this and use a pure Mesa's OpenGL implementation in this
> > situation.
> > * When getting out of the java World
> > * Running a pre-built glxgear/glxinfo installed through MacPorts
> > only allows using Apple's libGL.dylib but not Mesa's
> > libGL.dylib [2].
> > * Building glxinfo myself by linking explicitely to Mesa's GL +
> > X11 lead to an X11 error that I am not able to depict [3].
> > This has been discussed already on Khronos community [1] but I have no
> > clue how to go further. I hope some experts here can help me solve this!
> > Thanks in advance,
> > Martin
> > [1] https://community.khronos.org/t/failing-to-load-mesa3d-on-macos-instead-of-macos-provided-opengl-library/108408
> > [2] https://community.khronos.org/t/failing-to-load-mesa3d-on-macos-instead-of-macos-provided-opengl-library/108408/14
> > [3] https://community.khronos.org/t/failing-to-load-mesa3d-on-macos-instead-of-macos-provided-opengl-library/108408/19
> > [4] https://community.khronos.org/t/how-to-use-opengl-on-zink-mesa-moltenvk-and-macos/108160/18
> > [5] https://community.khronos.org/t/failing-to-load-mesa3d-on-macos-instead-of-macos-provided-opengl-library/108408/17
> >
> > ----------------------------------------------------------------------
> >
> > ** External Email: This email originated from outside of the
> > organization. Do not click links or open attachments unless you
> > recognize the sender.