The intention here, long ago, was to ensure that any symbols the DRI
driver needed from libGL were available. We don't have this problem
anymore, libgallium does not import any symbols from the GLX frontend
(or any other one for that matter).
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30417>
It's redundant at this point. The one exception is for GLX_PUBLIC when
building for glvnd, because then we really do want the GLX API to be
hidden.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33623>
Not that meson lets you reach this state yet, but if you did, you'd
still build all of the indirect code but the linker would gc most of it.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33623>
glx/egl "multibuffers" denotes if server side support DRI3
multi plane and modifiers which is version >= 1.2. But now
it returns true just when DRI3 version >= 1.
This causes problem when xserver with amdgpu DDX which only
support DRI3 1.0, so "multibuffers" gets set unexpectedly,
and client send DRI3 >= 1.2 request to server which gets
unimplemented error.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31657>
This caused GLX applications to segfault under zink.
This technically also fixes cleanup when any driver fails init
Signed-off-by: Sid Pranjale <mail@sidonthe.net>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31072>
this existed for historical reasons, but realistically now it should
be possible to build mesa with dri3 always enabled. additionally,
this check was often used as a substitute for having drm functionality,
which is sort of similar but also not really a direct match
this simplifies a bunch of conditionals and prevents users from footgunnning
themselves into orbit
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30952>
Previously the field `event_type` in `GLXPbufferClobberEvent`
was assigned twice in succession with different values.
Removing the first assignment and retaining only the second one.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30836>
all the destroy functions call free, but also the caller function calls
free anyway, so just change destroy -> deinit and let there be one free
call
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30619>
* add an enum of bits for determining which display connections to try
* collect bits and then do all setup in AllocAndFetchScreenConfigs()
in theory no functional changes
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30375>
Commit 7d9ea77b45 ("glx: add automatic zink fallback loading between hw and sw drivers")
added an automatic zink fallback even when the zink gallium is not
enabled at build time.
It leads to unexpected error log while loading drisw driver and
zink is not installed on the rootfs:
MESA-LOADER: failed to open zink: /usr/lib/dri/zink_dri.so
Fixes: 7d9ea77b45 ("glx: add automatic zink fallback loading between hw and sw drivers")
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Reviewed-by: Antoine Coutant <antoine.coutant@smile.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27478>
when set, this disables the use of vk swapchains and lets the dri frontend
manage buffers like any other driver
also document some kopper env vars
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28137>
On MacOS/Apple/Dawin you can only get MESA to forward the GL funtions to
the systems OpenGL.framework or run SWRast directly. There is no way to use a gallium driver, even if they have been compiled.
The two gallium drivers of interest are SWRast and Zink, as the rest are hardware drivers and not relavent on MacOS.
The code changes add a new define GLX_USE_APPLE. This is used in combination with the existing GLX_USE_APPLEGL.
GLX_USE_APPLEGL calls the systems OpenGL.framework, Apple's OpenGL.
GLX_USE_APPLE calls the non-system OpenGL code, i.e. Gallium, hence the subtle naming difference. Apple systems are still used, just not the GL ones.
When GLX_USE_APPLE is defined the code will use the DRI/gallium driver sub-system so SWRast and Zink can selected at runtime on MacOS.
This also allows Zink to be run on MacOS, once it is fixed up.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28205>
The combination of defines used when compile the code on MacOS is hiding variables.
Patch allows basic MacOS build to compile and run.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25992>
This was an ill-advised extension. While we advertised SWAP_COPY support,
we might implement it with a back-copy from the front buffer. And we
never advertised EXCHANGE because we couldn't guarantee it. So, if you
actually used this extension to try to reduce app redraws of the back
buffer, you might actually increase the bandwidth you used. Whoops.
Instead, GLX_EXT_buffer_age and the similar EGL extension give you
feedback on what's left in your back buffer, letting you do minimum
redraws.
This reduces our GLX visual+fbconfig count from 1410 to 940 on an llvmpipe
X server. Reducing visual counts will improve test runtime for
visual-iterating tests like piglit's glx-visuals-*.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25650>