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>
First, move a few early-out checks up since they don't need to take the
GLX lock. Second, move garbage collecting deleted contexts up to
immediately after they are unbound. This fixes a memory leak, albeit a
difficult one to hit, in the case where you switch away from a deleted
context but switching to the new one errors out. In that case we would
leak the deleted context, since it's been unbound from all threads and
there's no longer an XID for it.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20549>
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>
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>
This updates many places where 0 is used as NULL pointer.
There are a few warnings left when I build the default
configuration but they either relate to code
outside of mesa or where "None" is used instead.
Found with static analysis (smatch)
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12174>
I'm going to add another case for Android shortly, and then we can keep
the logic all in one spot.
Reviewed-by: Roman Stratiienko <r.stratiienko@gmail.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10389>
Somewhat terrifyingly, we never sent this for direct contexts, which
means the server never knew the context/drawable bindings. To handle
this sanely, pull the request code up out of the indirect backend, and
rewrite the context switch path to call it as appropriate. This
attempts to preserve the existing behavior of not calling unbind() on
the context if its refcount would not drop to zero.
Of course, you can't just do this indiscriminately, because this is GLX
and extant X servers have bugs and everything is terrible. To wit:
- For 1.20.x prior to 1.20.6, you can bind a direct context once, but
the second time you try to modify the context's binding you will get
GLXBadContextTag. This includes unbinding the context. And "deleting"
the context will leak memory, because it will still appear to be
current.
- For 1.19 and earlier, glXMakeCurrent(dpy, None, ctx) should be legal
for GL 3.0+ contexts, but the server will throw BadMatch.
To guard against this, we only send the request for indirect contexts
unless the server is known good, and only mention one context at a time
in such a request; if switching between contexts, we first unbind the
old, and then bind the new. Note that the second VendorRelease() version
is to catch XFree86 4.x and Xorg [67].x, which almost certainly have the
above bugs. Other servers might report different version numbers here,
but we can't do direct rendering against them, so this should be safe.
Fixes: mesa/mesa#4418
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9992>
Somewhat terrifyingly, we never sent this for direct contexts, which
means the server never knew the context/drawable bindings. To handle
this sanely, pull the request code up out of the indirect backend, and
rewrite the context switch path to call it as appropriate. This
attempts to preserve the existing behavior of not calling unbind() on
the context if its refcount would not drop to zero.
Of course, you can't just do this indiscriminately, because this is GLX
and extant X servers have bugs and everything is terrible. To wit:
- For 1.20.x prior to 1.20.6, you can bind a direct context once, but
the second time you try to modify the context's binding you will get
GLXBadContextTag. This includes unbinding the context. And "deleting"
the context will leak memory, because it will still appear to be
current.
- For 1.19 and earlier, glXMakeCurrent(dpy, None, ctx) should be legal
for GL 3.0+ contexts, but the server will throw BadMatch.
To guard against this, we only send the request for indirect contexts
unless the server is known good, and only mention one context at a time
in such a request; if switching between contexts, we first unbind the
old, and then bind the new. Note that the second VendorRelease() version
is to catch XFree86 4.x and Xorg [67].x, which almost certainly have the
above bugs. Other servers might report different version numbers here,
but we can't do direct rendering against them, so this should be safe.
Fixes glx-make-context, glx-multi-window-single-context and
glx-query-drawable-glx_fbconfig_id-window. Sufficiently old piglit will
regress on glx-make-glxdrawable-current (throwing BadMatch), which is
fixed by mesa/piglit!116.
Drawable and readable need to either both be None or both be non-None.
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This also fixes a bug, the error path through MakeCurrent didn't
translate the error code by the extension's error base.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
For each indirect context the indirect vertex array state must be initialised
by __glXInitVertexArrayState in indirect_vertex_array.c. As noted in the
routine header it requires that the glx context has been setup prior to the
call, in order to test the server version and extensions.
Currently __glXInitVertexArrayState is called from indirect_bind_context in
indirect_glx.c, as follows:
state = gc->client_state_private;
if (state->array_state == NULL) {
glGetString(GL_EXTENSIONS);
glGetString(GL_VERSION);
__glXInitVertexArrayState(gc);
}
But, the gc context is not yet usable at this stage, so the server queries
fail, and __glXInitVertexArrayState is called without the server version and
extension information it needs. This breaks multi-texturing as
glXInitVertexArrayState doesn't get GL_MAX_TEXTURE_UNITS. It probably also
breaks setup of other arrays: fog, secondary colour, vertex attributes.
To fix this I have moved the call to __glXInitVertexArrayState to the end of
MakeContextCurrent in glxcurrent.c, where the glx context is usable.
Fixes a regression caused by commit 4fbdde889c. Fixes ARB_vertex_program
usage in the arbvparray Mesa demo when run with indirect GLX and also
the tex-skipped-unit piglit test when run with indirect GLX.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Acked-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61907
With reference to the libglvnd branch:
https://cgit.freedesktop.org/mesa/mesa/log/?h=libglvnd
This is a squashed commit containing all of Kyle's commits, all but two
of Emil's commits (to follow), and a small fixup from myself to mark the
rest of the glX* functions as _GLX_PUBLIC so they are not exported when
building for libglvnd. I (ajax) squashed them together both for ease of
review, and because most of the changes are un-useful intermediate
states representing the evolution of glvnd's internal API.
Co-author: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Implicitly required for a while, although commit 9385c592c6 (mapi:
remove u_thread.h) was the one that put the final nail on the
coffin.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Left over from commit 18db13f5865(mapi: THREADS was always defined,
remove it)
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Implicitly required for a while, although commit 9385c592c6 (mapi:
remove u_thread.h) was the one that put the final nail on the
coffin.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Define GLX_USE_APPLEGL, as config/darwin used to, to turn on specific code to
use the applegl direct renderer
Convert src/glx/apple/Makefile to automake
Since the applegl libGL is now built by linking libappleglx into libGL, rather
than by linking selected files into a special libGL:
- Remove duplicate code in apple/glxreply.c and apple/apple_glx.c. This makes
apple/glxreply.c empty, so remove it
- Some indirect rendering code is already guarded by !GLX_USE_APPLEGL, but we
need to add those guards to indirect_glx.c, indirect_init.c (via it's
generator), render2.c and vertarr.c so they don't generate anything
Fix and update various includes
glapi_gentable.c (which is only used on darwin), should be included in shared
glapi as well, to provide _glapi_create_table_from_handle()
Note that neither swrast nor indirect is supported in the APPLEGL path at the
moment, which makes things more complex than they need to be. More untangling
is needed to allow that
v2: Correct apple/Makefile.am for srcdir != builddir
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
It was really only used in the radeon driver for a debug printf.
And evidently, libGL.so referenced it just to work around some sort
of linker issue.
This patch removes the two calls to the function and the function
itself.
Fixes undefined _glthread_GetID symbol in libGL reported by 'nm'.
Though, the missing symbol doesn't cause any issues on my system but
it does cause glxinfo to fail on one of our test systems.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
For a few reasons.
1: In the (current) common case, these conditionals are never true. All
we're doing by checking them is slowing down MakeCurrent. The server
does these checks already anyway.
2: GLX >= 3.0 contexts may legally be made current without a bound
framebuffer.
This does not fix piglit/glx-create-context-current-no-framebuffer, but
is a prerequisite for fixing it.
Cc: "9.1 9.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
We want to bind to our context before calling __glXSetCurrentContext or
messing with the gc rect in order to properly handle error conditions.
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
The current dri context unbind logic will leak drawables until the process
dies (they will then get released by the GEM code). There are two ways to fix
this: either always call driReleaseDrawables every time we unbind a context
(but that costs us round trips to the X server at getbuffers() time) or
implement proper drawable refcounting. This patch implements the latter.
Signed-off-by: Antoine Labour <piman@chromium.org>
Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The gc var would be NULL if called from line 238. Instead, get
the opcode from __glXSetupForCommand(dpy) as done in other places.
And remove the unused gc parameter.
Fixes a bug reported by "John Doe" on 3/9/2011.
NOTE: This is a candidate for the 7.10 branch.
This extension allows a client to bind one context in multiple threads
simultaneously. It is then up to the client to manage synchronization of
access to the GL, just as normal multithreaded GL from multiple contexts
requires synchronization management to shared objects.
Doesn't work for pixmaps, was looking up the GLX XID and was never thread
safe. Instead, just destroy the client side structures when the
drawable is no long current for a context.
This reverts 6a6e6d7b0a and initializes
dummyContext with an all NULL vtable. The context vtable pointer is
supposed to always be non-NULL, but the vtable entries can be NULL.
