Fix defect reported by Coverity Scan CID-1490794
Fixes: 0d42033b26 ("glx/dri2: Require the driver to support v4 of __DRI_DRI2")
Signed-off-by: Sergii Melikhov <sergii.v.melikhov@globallogic.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12563>
GLX_ARB_create_context_profile has some clever language that sets the
default to core profile but silently degrades back to compat for pre-3.2
GLs. We can just do that, rather than track whether the user specified a
profile.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12456>
We only end up with one DRI provider per screen, so the only way the
context vtable can differ is if they're not the same directness. Rewrite
the test in those terms to help us unify some of this code away in the
future. Also apply the same logic to the indirect context creation path.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12456>
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>
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>
Since commit f39fd3dce7 a new GLX error is issued in case context creation
fails. This broke wine on certain hardware: While wine installs an error handler
to ignore this kind of error, it does not function because it expects the
dpy->request serial number of the error to be incremented since the installation
of the handler.
Workaround this by artificially increasing the request number. This also
guarantees a unique serial number for the error.
Fixes: f39fd3dce7
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3969
Signed-off-by: Bastian Beranek <bastian.beischer@rwth-aachen.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10565>
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>
Patch workarounds the problem like commit eec904d29c did, this fixes
compilation on older distributions that still use old header.
Fixes: 01ba8a8d02 ("glx: Implement GLX_EXT_no_config_context")
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10447>
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>
The initialization we're doing for it in __glXExtensionsCtr is trivial,
and this is only to make glGetString(GL_EXTENSIONS) work in indirect
contexts anyway.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10223>
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>
We've never read any of this out. The transparency stuff we've never
implemented and the shift/mask stuff doesn't vary independently enough
to need to match on.
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
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>
Again, NVIDIA supports this on every fbconfig, Mesa alternates it on and
off for some reason but only on some drivers, and in particular llvmpipe
doesn't try to create sRGB-ful fbconfigs. Nerf it out of the fbconfig.
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/1648>
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>
For hardware drivers we've never set this to anything interesting so
there's no benefit to validating it. For drisw we're at the mercy of
whatever the X server sent to us anyway, and it's not like any server is
going to vary two fbconfigs by _just_ these values.
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/1648>
One, only applegl needs this. Two, this isn't a function of the context
in any way so it doesn't belong in the context vtable. Just special-case
applegl for now, we can revisit applegl's dispatch later.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9690>
The client-side implementation of this operates entirely in terms of the
GL and X client APIs. There's nothing DRI-specific about it, evidenced
by apple and windows using it unchanged. Save a little code size by
handling the direct/indirect difference directly.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9690>
When mesa gets a DRI2 1.1 connection (as experienced with
vmwware DDX) we don't get a pointer for this.
Don't explode just keep going.
Fixes: 60ebeb4608 ("glx: Implement GLX_EXT_swap_control for DRI2 and DRI3")
Reviewed-by: Adam Jackson <ajaX@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9184>
Starting with GL 3.0 it's legal to have no drawable bound to the current
context. GLX_SGI_video_sync doesn't take a drawable for an argument so
it implicitly operates on... something. NVIDIA's driver throws
GLX_BAD_CONTEXT for GetVideoSync, but WaitVideoSync seems to actually
wait for the next MSC on the context's screen. We could work around this
by internally creating/destroying a GLXWindow for the root window, but
for Xwayland there's not necessarily a good answer it can return.
Just throw GLX_BAD_CONTEXT for both.
Fixes: mesa/mesa#1207
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8334>
When using glvnd, this function needs to be exposed through
getDispatchAddress or libglvnd will not find it.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Fixes: 60ebeb4608 "glx: Implement GLX_EXT_swap_control for DRI2 and DRI3"
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8621>
It's a little unclear from the GLX_ARB_create_context spec whether the
list of supported extensions means what the client supports at all, or
what it knows an indirect GLX encoding for. You'd think it could only
really matter for indirect, since the only way the server would know
about GL commands (as opposed to GLX commands) is if the context was
indirect. And indeed for Xorg's GLX it doesn't matter, because it
doesn't check this, assuming that anything a direct client says works
works, and clamping the GL version based on the protocol it has code
for.
But if you're NVIDIA, apparently, you check this even for direct
contexts. And since drisw creates a nominally "direct" context, this
means llvmpipe and friends get clamped to 3.0 for desktop GL (since
that's as far as the protocol is defined) and can't do GLES at all.
So, whatever, just go ahead and claim to support everything. The wire
representation of the supported versions is strange (see comments in the
code) but it matches what NVIDIA does.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7369>
This is Sort Of handled by nerfing GL_VERSION in __indirect_glGetString,
but that doesn't cover GLES contexts which we also don't have any
indirect support for. Xorg's GLX would reject this for us since it has
the same limitation, but NVIDIA's GLX seems to interpret a request for
ES 2.0 as desktop, despite having the ES2 profile bit set, leading to a
very confusing GL_VERSION string and probably not the ES2-compatible
context you were hoping for.
Since we may now return NULL from indirect_create_context_attribs for
reasons other than malloc failure, we need to reasonably handle the case
where gc == NULL by the time we get to the XCB call. We rely on the
server to generate correct return values in this case, but if it
succeeds despite our client-side failure we just throw GLXBadFBConfig
(chosen to keep piglit/glx-create-context-core-profile happy, since
nothing else seems to hit it).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7369>
When the server doesn't support indirect contexts it will generate a
BadValue error, since the CreateContext request's isDirect field will
have specified an unsupported value of False. We attempt to verify that
context creation succeeded by asking whether the context's XID is direct
or not after we create it. Due to the details of XCB error handling, if
the context wasn't successfully created, the GLXBadContext error from
the GLXIsDirect request will get raised first, hiding the BadValue from
the application.
To fix this, we change the behavior of __glXIsDirect based on the
`error` outparameter. If it is NULL we still raise the error generated
from the GLXIsDirect request, but if it is non-NULL we now just inform
the caller that the request failed and silently eat the error. By doing
this the BadValue (or whatever else) from the CreateContext request will
bubble up to the application as expected.
This is admittedly a bit subtle but it's the simplest way to get to the
fix here. A better solution would be to convert all of CreateContext to
XCB, but XCB doesn't have protocol for GLX_SGIX_fbconfig yet so we'd
lose glXCreateContextWithConfigSGIX.
Fixes: mesa/mesa#3907
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7859>
The GLXIsDirect request will throw GLXBadContext for us if it needs to,
so we can avoid synthesizing an error on the client side.
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7859>
For the DRI backends we factor this out to a dri_common_create_context
method. Indirect gets the same transformation but doesn't use the common
method since it can't rely on DRI being built.
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7660>
Most of the legacy CreateContext paths already did this, this is just
aligning the two so we can implement one in terms of the other.
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7660>
Now that we introduced the generic glx_extension_override option,
we can remove the glx_disable_oml_sync_control,
glx_disable_sgi_video_sync, and glx_disable_ext_buffer_age ones.
It seems like the only user for them was the vmwgfx, and only for
Gnome and Compiz which are covered by the default mesa driconf. This
means that it is unlikely for a user to have these options set in
their local driconf file.
Suggested-by: Timothy Arceri <tarceri@itsqueeze.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Signed-off-by: Martin Peres <martin.peres@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7252>
Support for DRI1 is not implemented, but who still uses that?
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Martin Peres <martin.peres@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7212>
Support for DRI1 is not implemented, but who still uses that?
v2:
- Add the option to the list of new features
- Drop overriding the Xorg-exposed extensions
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Martin Peres <martin.peres@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7212>
This can be useful for debugging or working around bugs involving
indirect GL.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Martin Peres <martin.peres@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7212>
This can be useful for debugging or working around bugs such as
Mesa#106 where Wine is expecting to find a visual that isn't
available.
v2:
- split the indirect GL extension override to its own commit
- memset the bitfields to 0 in __glXExtensionsCtrScreen
Reviewed-by: Adam Jackson <ajax@redhat.com>
v3:
- slight rework necessary after splitting the computation of usable
extensions (Ian)
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Martin Peres <martin.peres@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7212>
Replicate the solution used for OpenGL extensions by introducing
__GLX_EXT_BYTES.
Suggested-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Martin Peres <martin.peres@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7212>
An upcoming commit will require to find an extension in a list. Rather
than duplicating part of the code from set_glx_extension, split it into
find_extension and set_glx_extension.
NOTE: set_glx_extension is a bit of a misnomer since it is also used
for gl extensions. This is why the find function is named
find_extension rather than find_glx_extension.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Martin Peres <martin.peres@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7212>
This is a minor bugfix, in that the prior code required that the server
expose either XFree86-DRI or DRI2 to get the name; Xwayland exposed
neither, just DRI3. Now, for DRI2 and DRI3, we just ask the loader. It
also means we report "swrast" for the driver name when that's what we're
using, which is probably a good thing.
v2: Trust the driver name from the server for DRI2 (Michel Dänzer)
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7219>
This is a slight generalization of the existing SGI and MESA swap
control extensions, and a prerequisite for GLX_EXT_swap_control_tear.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6671>
Adam Jackson
Corentin Noël
Vinson Lee
Sergii Melikhov
Yogesh Mohanmarimuthu
Emma Anholt
Bastian Beranek
Pierre-Eric Pelloux-Prayer
Tapani Pälli
Jeremy Huddleston Sequoia
Dave Airlie
Keith Packard
Eric Anholt
Andrii Simiklit
Martin Peres
Andrii Simiklit
Ian Romanick