Just provide a "(null)" literal in case driverName is NULL.
In file included from ../src/glx/dri3_glx.c:76:
../src/glx/dri3_glx.c: In function ‘dri3_create_screen’:
../src/glx/dri_common.h:70:36: error: ‘%s’ directive argument is null [-Werror=format-overflow=]
70 | #define CriticalErrorMessageF(...) dri_message(_LOADER_FATAL, __VA_ARGS__)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/glx/dri3_glx.c:1002:4: note: in expansion of macro ‘CriticalErrorMessageF’
1002 | CriticalErrorMessageF("failed to load driver: %s\n", driverName);
| ^~~~~~~~~~~~~~~~~~~~~
../src/glx/dri3_glx.c:1002:50: note: format string is defined here
1002 | CriticalErrorMessageF("failed to load driver: %s\n", driverName);
| ^~
cc1: some warnings being treated as errors
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We were caching only the value set with glXSwapIntervalSGI(), missing out
on the default setting of the swap interval by the loader. This fixes
glxgears's warning about being vblank synchronized by default.
Fixes: 9777c4234b ("loader: drop the [gs]et_swap_interval callbacks")
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
v2: Only reject no-error contexts for too-old GL if we're actually
trying to create a no-error context (Adam Jackson)
v3: Fix share contexts (Adam Jackson)
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
The only thing you do with a dri driver handle is get the extensions
pointer, so just fold it in to simplify the callers.
v2: Add the declaration of driGetDriverExtensions() that got lost in a
rebase.
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> (v1)
Reviewed-by: Emil Velikov <emil.velikov@collabora.com> (v1)
The version passed to QueryVersion requests is the version that the
client supports. We were just passing in whatever version of XCB was
present on the system, which may not be a version that Mesa actually
explicitly supports, e.g. it might bring unwanted semantics.
Set specific protocol versions which we support, and only pass those.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Fixes: 7aeef2d4ef ("dri3: allow building against older xcb (v3)")
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
The previous commit to make DRI3 modifier support optional, breaks with
an updated server and old client.
Make sure we never set multibuffers_available unless we also support it
locally. Make sure we don't call stubs of new-DRI3 functions (or empty
branches) which will never succeed.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Fixes: 7aeef2d4ef ("dri3: allow building against older xcb (v3)")
If PresentCompleteNotify event says the pixmap was presented
with mode PresentCompleteModeSuboptimalCopy, it means the pixmap
could possibly have been flipped instead if allocated with a
different format/modifier.
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Add support for DRI3 v1.1, which allows pixmaps to be backed by
multi-planar buffers, or those with format modifiers. This is both
for allocating render buffers, as well as EGLImage imports from a
native pixmap (EGL_NATIVE_PIXMAP_KHR).
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Drivers on virtual hardware don't want to expose this extension to
GLX compositors, similarly to GLX_OML_sync_control, since that significantly
increases latency.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>
deviceName string is declared, assigned and freed but actually
never used in dri3_create_screen() function.
Fixes: 2d94601582 ("Add DRI3+Present loader")
Signed-off-by: Vadym Shovkoplias <vadym.shovkoplias@globallogic.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
This should be safe as these backends already support the EGL version of
this extension. DRI1 is not affected because it does not support
GLX_ARB_create_context anyway. DRI-Windows is not prepared to implement
this as there's no equivalent WGL extension, and wglCreateContextAttribs
seems to really want the HDC's pixel format to be set.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
The code was relying on us always having a current context for client local
image blit operations. Otherwise the blit would be skipped. However,
glxSwapBuffers, for example, doesn't require a current context and that was a
common problem in the dri1 era. It seems the problem has resurfaced with dri3.
If we don't have a current context when we want to blit, try creating a private
dri context and maintain a context cache of a single context.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
It's not very usable since in the rare, but definitely existing case that
we don't have a current context, it will return NULL.
Presumably it will always be safe to use the dri screen the drawable was
created with for operations on that drawable.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Having two callbacks to manage a single int seems like an overkill.
Use a cached copy and update that when needed.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
---
Might want to look if the dimensions dance in .query_surface ...
speaking of which close to nobody implements that ...
With GLX_EXT_buffer_age turned on, gnome-shell will use full-screen damage
with GLX, which severely hurts performance with architectures that emulate
page-flips with copies. Like vmware. We would like to be able to turn off that
extension. Similarly, typically the GLX_OML_sync_control doesn't make much
sense on a virtual architecture since we don't really sync to the host's
vertical retrace. We'd like to be able to turn it off as well.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
A number of internal VMware apitrace traces image comparisons fail with
dri3 because the viewport transformation becomes incorrect after an X
drawable resize. The incorrect viewport transformation sometimes persist
until the second draw-call after a swapBuffer.
Comparing with the dri2 glx code there are a couple of places where dri2
invalidates the drawable in the absence of server-triggered invalidation,
where dri3 doesn't do that. When these invalidation points are added to
dri3, the image comparisons become correct.
v2:
Addressed review comment by Michel Dänzer.
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-and-tested-by: Michel Dänzer <michel.daenzer@amd.com>
v2:
bump version
v3:
Add code comment
s/IsGlThread/IsThread/ (and variation)
v4:
DRI3 doesn't hit X through GL call so it is always safe
Signed-off-by: Gregory Hainaut <gregory.hainaut@gmail.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
The GLX specification says about glXDestroyPixmap:
"The storage for the GLX pixmap will be freed when it is not current
to any client."
So arguably, functions like glXSwapIntervalMESA can be called after
glXDestroyPixmap has been called for the currently bound GLXPixmap.
In that case, the GLXDRIDrawable no longer exists, and so we just skip
those calls.
Cc: 17.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
With a subsequent patch, we might see NULL loaderPrivates, e.g. when
a DRIdrawable is flushed whose corresponding GLXDRIdrawable was destroyed.
This resulted in a crash, since the loader vs. DRI3 drawable structures
have a non-zero offset.
Fixes glx-visuals-{depth,stencil} -pixmap
Cc: 17.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
In OpenGL 3.0 and later it is legal to make a context current without
a default framebuffer.
This has been broken since DRI3 support was introduced.
Cc: "13.0 12.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reminiscent from the pre-loader days, were we had multiple instances of
the loader logic in separate places and one could build a "GALLIUM_ONLY"
version.
Since that is no longer the case and the loaders (glx/egl/gbm) do not
(and should not) require to know any classic/gallium specific we can
drop the argument and the related code.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
The EXT spec has been updated to:
- logically combine the es2_profile and es_profile exts
- allow any legal version to be requested
dEQP tests request a specific ES version when using GLX, so this allows
dEQP upstream to run against GLX with the appropriate X server patch
(which had similar disabling logic).
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Matt Turner <mattst88@gmail.com> (v1)
Reviewed-by: Adam Jackson <ajax@redhat.com> (v3)
v1 -> v2:
- distinguish between DRI_API_GLES{,2,3}
- add GLX_EXT_create_context_es_profile client-side support
v2 -> v3:
- fix error in computing mask
v2: From Martin Peres
- convert to the new drawable interface
- delete dead code after the dropping of some vfuncs
- delete the width and height attributes since they are found in the helper
Signed-off-by: Boyan Ding <boyan.j.ding@gmail.com>
Signed-off-by: Martin Peres <martin.peres@linux.intel.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.co.uk>
Checks blitImage is implemented.
Initially having the __DRIimageExtension extension
at version 9 at least meant blitImage was supported.
However some implementation do advertise version >= 9
without implementing it.
CC: 10.5 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Axel Davy <axel.davy@ens.fr>
This should make it more obvious in bug reports while also removing
any sort of guesswork for developers.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Martin Peres <martin.peres@linux.intel.com>
glXSwapBuffersMscOML() with target_msc=divisor=remainder=0 gets
translated into target_msc=divisor=0 but remainder=1 by the mesa
api. This is done for server DRI2 where there needs to be a way
to tell the server-side DRI2ScheduleSwap implementation if a call
to glXSwapBuffers() or glXSwapBuffersMscOML(dpy,window,0,0,0) was
done. remainder = 1 was (ab)used as a flag to tell the server to
select proper semantic. The DRI3/Present backend ignored this
signalling, treated any target_msc=0 as glXSwapBuffers() request,
and called xcb_present_pixmap with invalid divisor=0, remainder=1
combo. The present extension responded kindly to this with a
BadValue error and dropped the request, but mesa's DRI3/Present
backend doesn't check for error codes. From there on stuff went
downhill quickly for the calling OpenGL client...
This patch fixes the problem.
v2: Change comments to be more clear, with reference to
relevant spec, as suggested by Eric Anholt.
Cc: "10.3 10.4" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Eric Anholt <eric@anholt.net>
Restores proper immediate tearing swap behaviour for
OpenGL bufferswap under DRI3/Present.
Cc: "10.3 10.4" <mesa-stable@lists.freedesktop.org>
v2: Add Frank Binns signed off by for his original earlier
patch from April 2014, which is identical to this one, and
Chris Wilsons reviewed tag from May 2014 for that patch, ergo
also for this one.
v3: Incorporate comment about triple buffering as suggested
by Axel Davy, and reference to relevant spec provided by
Eric Anholt.
Signed-off-by: Frank Binns <frank.binns@imgtec.com>
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Eric Anholt <eric@anholt.net>
