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>
This is achieved by the following steps:
#ifndef DEBUG => #if !MESA_DEBUG
defined(DEBUG) => MESA_DEBUG
#ifdef DEBUG => #if MESA_DEBUG
This is done by replace in vscode
excludes
docs,*.rs,addrlib,src/imgui,*.sh,src/intel/vulkan/grl/gpu
These are safe because those files should keep DEBUG macro is already excluded;
and not directly replace DEBUG, as we have some symbols around it.
Use debug or NDEBUG instead of DEBUG in comments when proper
This for reduce the usage of DEBUG,
so it's easier migrating to MESA_DEBUG
These are found when migrating DEBUG to MESA_DEBUG,
these are all comment update, so it's safe
Replace comment /* DEBUG */ and /* !DEBUG */ with proper /* MESA_DEBUG */ or /* !MESA_DEBUG */ manually
DEBUG || !NDEBUG -> MESA_DEBUG || !NDEBUG
!DEBUG && NDEBUG -> !(MESA_DEBUG || !NDEBUG)
Replace the DEBUG present in comment with proper new MESA_DEBUG manually
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: David Heidelberg <david.heidelberg@collabora.com>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28092>
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>
DRI2 calls are different between Linux and MacOS.
Calling these Linux version on MacOS using xquartz fails with 'unknown' codes.
This patch hardwires a number of the utility DRI2 functions to use the MacOS
specific version that already exist for APPLEGL.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28205>
This patch allows MacOS to compile the dri[2] systems by switching from direct xf86drm.h to
the pre-existing util/libdrm.h.
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28130>
In commit 1396dc1c a new output field was added as a parameter, but this
is a problem since the signature of the function are not versionned.
The flush function didn't have a versionned output struct. So what I'm
proposing here is that if the version of the input argument is new enough
(bumped to 2 here), then we re-use the existing argument, which until now
was directly a pointer to GLsync, and instead use it as a pointer to a
versioned struct.
We're just changing one pointer type to another, so in C, this should
be fine AFAIK.
Fixes: 1396dc1c
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26315>
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>
To get MacOS to build, some extra dependencies need to be added to a couple of build targets.
This mainly shows up when not installing the dependencies in the default prefix locations.
On MacOS, this happens when using a custom build of brew to install the dependencies to 'odd' locations.
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>
if loading the default hardware driver fails, implicitly loading zink
should now be preferable to hitting the software fallback now that zink
has all the same capabilities
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25640>
this is going to be broken, so don't bother trying
also add LIBGL_KOPPER_DRI2 so people can continue to footgun if they
really really want to
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25640>
This is not used anywhere. Been there from the beginning of this
file but with no related code in glxextensions.c
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Acked-by: Antonio Gomes <antoniospg100@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24573>
All the plumbing was added in 8d55fb54b1
but for some reason the top level access method was not ...
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Acked-by: Antonio Gomes <antoniospg100@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24573>
CID 1528170 (#1 of 1): Logically dead code (DEADCODE)
At condition gc, the value of gc cannot be NULL.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Illia Polishchuk <illia.a.polishchuk@globallogic.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20893>
this is a separate patch as it's won't affect the code style
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: David Heidelberg <david.heidelberg@collabora.com>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23577>
The GLX spec for glXMakeCurrent (3.3):
"If ctx is current to some other thread, then glXMakeCurrent will generate
a BadAccess error"
The GLX spec for glXCopyContext (3.3):
"If the destination context is current for some thread then a BadAccess
error is generated"
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7961
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Illia Polishchuk <illia.a.polishchuk@globallogic.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22546>
Unlike the legacy CreateContext path, we would try to send the
GLXCreateContextAttribs request regardless of whether we'd successfully
created the client context state. And there's not a lot on the server
side to go wrong besides BadAlloc, so if the request succeeded but
the client side didn't we'd need to destroy the server context and
synthesize an X error. Since that itself involves more X protocol it's
tricky to get the request number right in the error, and tests and apps
can notice when you get it wrong.
Since we have now fixed client-side validation to generate the right
errors at the right times, this patch does something simpler, we match
CreateContext and fail early if the client-side setup fails. Now there's
no question of what request number to use, because we haven't sent any
protocol, the error is for the request as if it'd been sent.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4763
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12006>
This has no functional change because everyone calling this is
discarding the error code, because we're relying on the server to
generate the right thing for us. But we create the direct context first
and the server isn't going to enforce everything we want it to
(supported GL versions for example). Convert out from DRI error codes to
X/GLX error codes so we can fail the right way on the client side. We're
still throwing the error away in all of the callers but that'll change
shortly.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12006>
Indeed, the unbind function is not called which could lead
to an unbalanced refcount state for the "drawable" object.
For instance, with "piglit/bin/glx-fbo-binding -auto"
while setting GALLIUM_REFCNT_LOG=refcnt.log.
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22024>
