Since we know we're loading this Mesa build, we know that no_error is
always supported (the renderer query always returned true).
Reviewed-by: Adam Jackson <ajax@redhat.com>
Acked-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20069>
All DRI loaders in Mesa (EGL, GLX, gbm) now require this ext and that the
driver come from a matching build. This will let us use Mesa-internal
types and enums across the loader-driver bounary inside of Mesa.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Acked-by: Eric Engestrom <eric@igalia.com>
LOL-YESed-by: Kristian Høgsberg <krh@bitplanet.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20069>
This reverts commit 31b04e420b which
is also breaking KDE in some ways.
Fixes: #7674
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Acked-by: Tapani Pälli <tapani.palli@intel.com>
Acked-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19972>
This reverts commit 768238fdc0 which
is not only leading to memory leaks, but also reportedly breaks KDE
pretty badly.
Fixes: #7674, #7435
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Acked-by: Tapani Pälli <tapani.palli@intel.com>
Acked-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19972>
It's pulled too much system dependent headers before this commit
when #include <vulkan/vulkan.h> directly,
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19491>
So that we do not need define GLAPIENTRY repeatedly, always using the
GLAPIENTRY macro comes from GL/gl.h
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Brian Paul brianp@vmware.com
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19472>
Replace tabs with spaces. Fix up function pointer calls (don't use
the old style (*foo)(arg) syntax).
Signed-off-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19329>
glx_direct and glx_accel are guard by #if defined(GLX_DIRECT_RENDERING) && !defined(GLX_USE_APPLEGL)
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18749>
This swaps the function names with aliased names that don't have those
suffixes.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18199>
if the driver attemping to load is not zink and not software, then
attempt a zink fallback on failure
this conservatively handles the case of "only zink is built", though it
is going to be noticeably slower at startup than loading zink directly
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16168>
The config matched by visual ID will have the right fbconfig ID set, you
don't need to go looking for it, so long as you look in the list of
fbconfigs as opposed to the list of visuals (which do not have
GLX_FBCONFIG_ID filled in).
It's sort of broken that we have two lists here, when the only real
distinction is that glXChooseVisuals needs to filter out non-window-
capable configs from its view. That's a bigger cleanup for another day.
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18473>
They are empty stub functions now so have no need call to them
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Acked-by: Jose Fonseca <jfonseca@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17814>
Error message on OSX:
../src/glx/tests/fake_glx_screen.cpp:101:20: error: thread-local declaration of '__glX_tls_Context' with dynamic initialization follows declaration with static initialization
thread_local void *__glX_tls_Context = &dummyContext;
^
../src/glx/glxclient.h:655:36: note: previous declaration is here
extern __THREAD_INITIAL_EXEC void *__glX_tls_Context;
Fixes: be00a7c8ac ("glx: using C++11 keyword thread_local")
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17784>
dri3_glx.c includes xshmfence and glxcmds.c includes xf86vm, neither of
which are listed as dependencies of the glx lib in the meson.build file.
Consequently, those files would fail to compile on machines that did not
have xshmfence and xf86vm installed globally. This commit rectifies the
issue by adding the missing dependencies
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17585>
driFetchDrawable is only ever called from the MakeCurrent path, which
means it has to handle the case of pre-GLX-1.3 Windows being named as
the drawable. When it finds the drawable in the hash, it increments its
refcount before returning it, so for a GLXWindow it would be 2 on first
return, one from glXCreateWindow and one from glXMakeCurrent. But when
it does not find the drawable and creates one for the naked Window, the
reference count on first return would only be 1. As a result, if this
context was then ever bound to a different drawable, the old Window's
DRI drawable state (like the back buffer) would be destroyed.
Fixes piglit's glx-multi-window-single-context and glx-make-current for
a variety of drivers.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6713
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17479>
We were defaulting to a swap interval of 1, but we can follow dri2/dri3's
lead and respect the driconf var.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17470>
Compare to dri2SetSwapInterval() and dri3_set_swap_interval()
implementations of the same method.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17470>
This hasn't actually been exported for a while. I think I probably broke
this in
commit 63a6b719d9
Author: Adam Jackson <ajax@redhat.com>
Date: Tue Dec 5 11:10:09 2017 -0500
glx: GLX_MESA_multithread_makecurrent is direct-only
in which I made it no longer default to having client support, but
failed to instruct dri{2,3,sw} to enable it. In any case, it was never
widely used, there is no EGL equivalent, and we've had zero complaints
about it getting nerfed.
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17473>
We want to release the drawables of the context we're coming from, but
we were releasing them from the context we're switching to. This is
probably not a big deal normally because both contexts are likely to be
on the same display, which is all that driReleaseDrawables is really
sensitive to. But if the contexts are on different Displays this would
go quite wrong.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17176>
