Re: mesa on darwin/x11

[Jeremy Sequoia]

Thanks, Duncan. This does help explain some things. I assumed that you were building with APPLEGL=1 + APPLE=1 since that is what meson setup.  Also, there was only one very minor code difference that APPLE enabled when APPLEGL was unset.  Are you sure you build with APPLEGL=0?  APPLE=1 neuters many of the APPLEGL build time branches. My goal is slightly different than yours in that I want to have runtime choices between Gallium and OpenGL.fw.  I just put up a pull request that I think accomplishes that without breaking anyone else.  I'd love it if you could look it over and make sure it works for you as well: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42512 This PR also makes some architectural changes to glx (new vtable and a new capability bit to enable runtime vs build time branching) that I'd like other eyes on before I merge to make sure it isn't offensive to folks. Thanks, Jeremy Sent from my iPhone... On Jun 26, 2026, at 03:17, Duncan Hopkins <duncan.hopk...@foundry.com> wrote:  Hi Jeremy, I will try my best to remember what the details are for this, but it has also been a good few years since I made this mess. :) What we need is to be able to compile mesa with zero `OpenGL.framework` dependencies and have the Gallium drivers (mainly Zink and SWRast) and Kopper kick in. When `OpenGL.framework` and CGL code is used (the GLX_USE_APPLEGL=1 case) the whole of the Gallium and DRI code paths where by-passed and all GL entried points where faast forwarded to `OpenGL.framework`. This is not good as we are trying to produce a solution that works without `OpenGL.framework` to avoid "Apple Depricating OpenGL and OpenCL" issue. Also being able to run against an OpenGL higher than 4.1 would be nice. So falling back to `OpenGL.framework` at runtime was not something we want or seemed easy to do at the time.  The `GLX_USE_APPLE=1` should indicate that we are running on an Apple system (MacOS) and the `GLX_USE_APPLEGL=1` sould indicate that `OpenGL.framework` is good to be used. In our use case we build with `GLX_USE_APPLE=1` `GLX_USE_APPLEGL=0` , we want to use the Gallium drivers and and avoid any use of the `OpenGL.framework` even if Zink or SWRast fail to start up. It has been a minute since we last updated our internal software stack with the latest public mesa version, so there is a good chance the present mesa code might be broken. In the past, mesa has gotten broken because there is no fully testable MacOS build for other developers to check against.  I was trying to push as much code as I could back to mesa, but I got stuck on a Kopper `VkSurface` issue between xQuarts and MoltenVk, one supports only X11 extensions and the other only supports MacOS extensions! Internally we are using these code paths. We also stripped away the X11 dependencies because we are using this in a native macOS application, not through XQuarts. Does this help explain the macro mess? Duncan Hopkins Software Architect Tel: +44 20 7479 4350 Web: www.foundry.com The Foundry Visionmongers Ltd.  -  Registered in England and Wales No: 4642027 Address: 5 Golden Square, London, W1F 9HT  -  VAT No: 945701320 The Foundry Visionmongers Ltd has its registered office at 19 Cornwall Street, Birmingham, England, B3 2DX. This email is intended for the named recipient only and may contain confidential information. If you are not the intended recipient, notify the sender immediately and destroy this email; you must not copy, distribute or take action in reliance upon the email or in any attachment. For information about how we process data and monitor communications please see our Privacy Policy. On Wed, 24 Jun 2026 at 09:54, Jeremy Sequoia <jerem...@freedesktop.org> wrote: Hi Duncan, I haven't been paying much attention to mesa or X11 for a few years.  I'm just now looking back since I have some free cycles on vacation.  I see you did some work in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28205 to get darwin/x11 to use gallium, but the way we go about it with macro definitions is quite confusing to me since we end up having macros that seem not well defined any more Previously, GLX_USE_APPLEGL=1 meant "build a hacky libGL from the mesa sources in a mostly nonstandard way since we never got around to merging things together to make the implementation selectable at runtime" and GLX_USE_APPLEGL=0 meant "build a modern gallium libGL that you can use for swrast or IGLX but that doesn't work with hardware acceleration because we never got around to moving glx/apple into the modern era.  What does GLX_USE_APPLEGL mean now? With the introduction of GLX_USE_APPLEGL=1 GLX_USE_APPLE=1, it seems that we're getting gallium but with some slight differences from the GLX_USE_APPLEGL=0 case. Relatedly, is GLX_USE_APPLEGL=0 GLX_USE_APPLE=1 expected to be a valid configuration?  If so, what does it mean?  It looks like the only difference between it and GLX_USE_APPLEGL=0 GLX_USE_APPLE=0 is at src/glx/glxext.c:1029:   #if !defined(GLX_USE_APPLE)      if (!dpyPriv->has_multibuffer && glx_accel && !debug_get_bool_option("LIBGL_KOPPER_DRI2", false)) {         if (glx_driver & GLX_DRIVER_ZINK_YES) {            CriticalErrorMessageF("DRI3 not available\n");            goto init_fail;         }         glx_driver &= ~GLX_DRIVER_ZINK_INFER;      }   #endif which seems maybe not intentional ... ? Why would we want that for GLX_USE_APPLEGL=1 GLX_USE_APPLE=1 but not GLX_USE_APPLEGL=1 GLX_USE_APPLE=0? So I'm confused as to why we need two variables here.  I'd like to get us down to 0, whereby the OpenGL.framework backend is selectable at runtime rather than build time, and these changes you've made seem to make the build space a bit more complicated than they were before. Can you walk me through the design decisions here?  I'd be happy to chat over Webex / Zoom / whatever if that would be easier. Thanks, Jeremy