This means the drawable was already destroyed. This can happen during
diplay teardown, destroying the context will make it current first so it
can flush rendering and destroy textures and such, and if the drawable
is already destroyed then flushing to nowhere would crash.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11423>
The created DRI screen can be used to allocate VRAM memory from
display GPU in case of prime.
v2: add comments to make code readable (Pierre-Eric)
remove driver name match check
v3: keep old path for non-mesa driver (Michel Dänzer)
v4: fallback if driver not found for display GPU (Michel Dänzer)
fallback if create screen fail for display gpu (Michel Dänzer)
Signed-off-by: Yogesh Mohanmarimuthu <yogesh.mohanmarimuthu@amd.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10595>
We'd like to avoid __glXInitialize as much as possible since it involves
taking a global lock. This means converting internal APIs to operate as
much as possible in terms of something other than a Display *, since if
that's all you have then you're forced to call __glXInitialize to get to
the glx_display.
The contortions in DRI2 displease me, but DRI2 displeases me, so.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10418>
This code would work for GLXWindows but not for bare Windows, which I
guess you could argue is a server bug but which we can fix on the client
side with a little effort. We change __glXGetDrawableAttribute to
additionally return false if we failed to find the requested attribute
(which is safe, all the other callers discard the return value). Then
when inferring the fbconfig, if the attribute wasn't found, we ask for
the window attributes to find the visual ID and use that to find the
fbconfig.
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10381>
These are rare enough to not be worth tracking separately. Especially
since after this change all the known_gl_extensions have N for both
direct_support and direct_only (unsurprising, since that's only used to
compute usable indirect extensions).
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10223>
... at least as far as libGL is concerned, because they'd work just fine
if you tried. The only thing the ATI extension seems to add (I can't
find an official spec, this is inferred from the registry XML) is
selecting the GLX_RENDER_TYPE, which we don't validate before putting on
the wire. The only thing the NV extension adds is an additional fbconfig
attribute, and that only known by glXGetFBConfigAttrib; our
implementation of that just reads the value the server sends, if any,
and doesn't try to filter out unknown attributes.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10223>
The "left here but disabled" comment dates to 2004! The idea here is to
add extensions implied by a particular GL version to the GL extension
string, but nothing useful is accomplished by doing so, and this is all
only used in the case of indirect rendering anyway.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10223>
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>
Move the macros defining the expected number of attributes into the same
file as their consumer, remove a pointless maximum, and allocate more
space for attribs on the stack to avoid malloc in the common case.
glxext.c knows about 46 config attribs, 46 - 18 = 28, round up to 32 to
future proof a bit.
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9992>
Mesa marks accumful fbconfigs as slow (for no especially good reason,
it's only accum operations that aren't accelerated, and we could fix
that). NVIDIA doesn't. All that mismatching on this attribute can do is
prevent a config from working exactly as well as it possibly can.
Trust the server's opinion here (but warn if you ask for warnings).
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/1648>
Adam Jackson