| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: <[email protected]>
Signed-off-by: Thomas Hellstrom <[email protected]>
Reviewed-and-tested-by: Michel Dänzer <[email protected]>
(cherry picked from commit 1253d58983b2b6ba4ed16444a344327e8117f333)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Together with some fixes to xdriinfo this fixes xdriinfo not working
with glvnd.
Since apps (xdriinfo) expect GetDriverConfig to work without going to
need through the dance to setup a glxcontext (which is a reasonable
expectation IMHO), the dispatch for this ends up significantly different
then any other dispatch function.
This patch gets the job done, but I'm not really happy with how this
patch turned out, suggestions for a better fix are welcome.
Cc: Kyle Brenneman <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
Cc: [email protected]
(cherry picked from commit 84f764a7591715104b28c035c837ce9fd86157ad)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code itself has nothing to do with shared glapi, thus having it
behind GLX_SHARED_GLAPI is misleading. Use GLX_INDIRECT_RENDERING
instead.
The latter macro is set at global scope by the Autotools and Scons build
systems.
Cc: [email protected]
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
(cherry picked from commit 6177d60a374a3d48969fcb062ac1d82465850cb4)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new interface mostly just sits on top of the existing library.
The only change to the existing EGL code is to split the client
extension string into platform extensions and everything else. On
non-glvnd builds, eglQueryString will just concatenate the two strings.
The EGL dispatch stubs are all generated. The script is based on the one
used to generate entrypoints in libglvnd itself.
v2: [Kyle]
- Rebased against master.
- Reworked the EGL makefile to use separate libraries
- Made the EGL code generation scripts work with Python 2 and 3.
- Change gen_egl_dispatch.py to use argparse for the command line arguments.
- Assorted formatting and style cleanup in the Python scripts.
v3: [Emil Velikov]
- Rebase
- Remove separate glvnd glx/egl configure toggles
Signed-off-by: Emil Velikov <[email protected]>
|
|
|
|
| |
Signed-off-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
| |
We're not using anything in it, and we don't want to inherit struct
definitions from some other package anyway.
Signed-off-by: Adam Jackson <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Recent change to use drmGetDevices2() made me realize that
build configured using
PKG_CONFIG_PATH=my_drm_lib_path/pkgconfig ./autogen.sh
considers the libdrm path gotten from pkgconfig only during
make. When invoking "make install" the relink command puts
system library ahead of the path gotten from pkgconfig
(and starts to fail as system libdrm isn't new enough).
This change forces the relink command to respect pkgconfig
settings.
It looks to me that in
https://bugs.freedesktop.org/show_bug.cgi?id=100259
with Emil et al considering it a libtool bug.
Signed-off-by: Topi Pohjolainen <[email protected]>
[Emil Velikov: add inline comment]
Signed-off-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
v2: Marek: Add DRI3 support.
v3: (Timothy Arceri) use C99 initializers.
Acked-by: Timothy Arceri <[email protected]>
Acked-by: Marek Olšák <[email protected]>
Tested-by: Dieter Nützel <[email protected]>
Tested-by: Mike Lothian <[email protected]>
|
|
|
|
|
|
| |
Used/applicable to only dri1 drivers.
Signed-off-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
| |
Otherwise we'll fail at `make distcheck'
Fixes: 3cc33e76401 ("glx: add GLXdispatchIndex sort check")
Signed-off-by: Emil Velikov <[email protected]>
|
|
|
|
| |
Signed-off-by: Eric Engestrom <[email protected]>
|
|
|
|
|
|
|
| |
Previously, only the last error code was returned.
Using `set -e` makes the script quit on any unhandled error.
Signed-off-by: Eric Engestrom <[email protected]>
|
|
|
|
|
|
|
| |
Requirement was removed just before pushing, but it's actually needed
for heredocs (`<<<`).
Signed-off-by: Eric Engestrom <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Eric Engestrom <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 8bca8d89ef3b ("glx/glvnd: Fix dispatch function names and indices")
fixed the sorting of the array initializers in g_glxglvnddispatchfuncs.c
because FindGLXFunction's binary search needs these to be sorted
alphabetically.
That commit also mostly fixed the sorting of the DI_foo defines in
g_glxglvnddispatchindices.h, which is what actually matters as the
arrays are initialized using "[DI_foo] = glXfoo," but a small error
crept in which at least causes glXGetVisualFromFBConfigSGIX to not
resolve, breaking games such as "The Binding of Isaac: Rebirth" and
"Crypt of the NecroDancer" from Steam not working and possible causes
other problems too.
This commit fixes the last of the sorting errors, fixing these mentioned
games not working.
Fixes: 8bca8d89ef3b ("glx/glvnd: Fix dispatch function names and indices")
Cc: "13.0" <[email protected]>
Cc: "17.0" <[email protected]>
Cc: Adam Jackson <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
| |
DRI2DriverPrimeShift was added in dri2proto-2.8, which we now require
as of the previous commit.
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
| |
The two symbols referenced were introduced with v2.2 and 2.3 of
the dri2proto package and we require dri2proto >= 2.6.
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
| |
Cc: 17.0 <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
| |
Analogous to previous commit.
Cc: "12.0 13.0" <[email protected]>
Cc: Jon Turney <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Analogous to previous commit.
Cc: "12.0 13.0" <[email protected]>
Cc: Jeremy Huddleston Sequoia <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Jeremy Sequoia <[email protected]>
|
|
|
|
|
|
|
| |
Analogous to previous commit.
Cc: "12.0 13.0" <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
No point in having an identical code in two places.
Not to mention that the Apple one incorrectly uses GLXDrawable as pbuf
type. This change is both API and ABI safe since the header uses the
correct GLXPbufferSGIX and both types are a typedef of the same
primitive XID.
Cc: Jeremy Huddleston Sequoia <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Jeremy Sequoia <[email protected]>
|
|
|
|
|
|
| |
Use the macro, rather than open-coding it.
Signed-off-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
We must make sure that xserver has an equivalent one-line
change to its configure.ac as the glx/glapi headers get copied over.
Then again, xserver does _not_ seem to set HAVE_ALIAS to begin with so
one might want to look into that first.
Cc: Adam Jackson <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
| |
Quick search through git history (of both mesa and xserver) hows no
instances where this was ever set.
Signed-off-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
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" <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Changes since v1:
- removed not needed includes
- use the loader version of the helper
v2 [Emil Velikov]
- Keep the includes - they are required.
Signed-off-by: Christian Gmeiner <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
| |
This reverts commit 1a21d21580965eff751414d140b3c176eeee2eb3.
Pushed the wrong version of the patch.
|
|
|
|
|
| |
Signed-off-by: Christian Gmeiner <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This was broken when the GLAPI use was removed from mesa_glinterop.h.
Cc: 12.0 13.0 <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Otherwise it won't be picked in the tarball and the build will fail.
Fixes: 533b3530c12 ("direct-to-native-GL for GLX clients on Cygwin
("Windows-DRI")")
Cc: "13.0" <[email protected]>
Signed-off-by: Andreas Boll <[email protected]>
Reviewed-by: Jon Turney <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Eric Engestrom <[email protected]>
Signed-off-by: Adam Jackson <[email protected]>
|
|
|
|
|
|
|
|
|
| |
As this array was not actually sorted, FindGLXFunction's binary search
would only sometimes work.
Cc: "13.0" <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
Signed-off-by: Adam Jackson <[email protected]>
|
|
|
|
|
|
| |
Cc: "13.0" <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
Signed-off-by: Adam Jackson <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Axel Davy <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit cf804b4455fac9e585b3600a8318caaced9c23de
('glx: fix crash with bad fbconfig') introduced a check
in glXCreateNewContext() if the given config is a valid
fbconfig.
Unfortunately the check always checks the given config against
the fbconfigs of the DefaultScreen(dpy), instead of the
actual X-Screen specified in the config config->screen.
This leads to failure whenever a GL context is created
on a non-DefaultScreen(dpy), e.g., on X-Screen 1 of
a multi-x-screen setup, where the default screen is
typically 0.
Fix this by using config->screen instead of DefaultScreen(dpy).
Tested to fix context creation failure on a dual-x-screen setup.
Signed-off-by: Mario Kleiner <[email protected]>
Cc: "11.2 12.0" <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This allows querying the current active screen from the
loader's common code.
Cc: [email protected]
Reviewed-by: Emil Velikov <[email protected]>
Signed-off-by: Martin Peres <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The function deals with fb (style) configs, thus using "visual"
in the name is misleading. Which in itself had led to the use of
fbconfig_style_tags argument.
Rename the function to reflect what it does and drop the unneeded
argument.
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Return GL_FALSE if we fail to find any fb/visual configs, otherwise we
end up with all sorts of chaos further down the GLX stack.
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
The comment/spec says - only for pbuffer drawables, while the code
clears the window/pixmap bit. Practise what you preach and apply the
trivial tweak. In practise this should not cause functional change.
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Structurally, this is very similar to the existing Apple-DRI code, except I
have chosen to implement this using the __GLXDRIdisplay, etc. vtables (as
suggested originally in [1]), rather than a maze of ifdefs. This also means
that LIBGL_ALWAYS_SOFTWARE and LIBGL_ALWAYS_INDIRECT work as expected.
[1] https://lists.freedesktop.org/archives/mesa-dev/2010-May/000756.html
This adds:
* the Windows-DRI extension protocol headers and the windowsdriproto.pc
file, for use in building the Windows-DRI extension for the X server
* a Windows-DRI extension helper client library
* a Windows-specific DRI implementation for GLX clients
The server is queried for Windows-DRI extension support on the screen before
using it (to detect the case where WGL is disabled or can't be activated).
The server is queried for fbconfigID to pixelformatindex mapping, which is
used to augment glx_config.
The server is queried for a native handle for the drawable (which is of a
different type for windows, pixmaps and pbuffers), which is used to augment
__GLXDRIdrawable.
Various GLX extensions are enabled depending on if the equivalent WGL
extension is available.
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, due to the inverse order, strcmp will produce negative result
when the needle is towards the start of the haystack. Thus on the next
iteration(s) we'll end up further towards the end and eventually fail to
locate the entry.
Cc: "12.0" <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's no guarantee that there is one, and we don't need one anyway.
Fixes piglit tests:
glx@glx-fbconfig-bad
glx@glx_ext_import_context@import context, multi process
glx@glx_ext_import_context@import context, single process
Fixes: 2e3f067458e4 ("glx: fix error code when there is no context bound")
Cc: "11.2" <[email protected]>
Reviewed-by: Tapani Pälli <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Tapani Pälli <[email protected]>
Reviewed-by: Jeremy Huddleston Sequoia <[email protected]>
Cc: Jeremy Huddleston Sequoia <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
v2: change all related NULL checks to check against dummyContext
v3: really check for dummyContext *only* when ctx was from
__glXGetCurrentContext
v4: cover more checks, add dummyBuffer, dummyVtable (Emil)
Signed-off-by: Bernard Kilarski <[email protected]>
Signed-off-by: Matt Roper <[email protected]>
Signed-off-by: Tapani Pälli <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
Cc: "11.2" <[email protected]>
|
|
|
|
|
|
|
|
| |
Compilers are perfectly capable of generating efficient code for calls
like these to memcpy().
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|