Enable OpenGL software rendering on macOS

Wed May 4 11:34:16 UTC 2022

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.