| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 35fc7bdf0e6ad6547e39099e7060a3d89539b56d.
Unfortunately mentioned commit introduced a memory leak because
`driwindowsMapConfigs` and `createDriMode` functions allocate
small memory portions for each element:
21,576 (232 direct, 21,344 indirect) bytes in 1 blocks are definitely lost in loss record 1,411 of 1,414
at 0x483A7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x5D4AA09: createDriMode (dri_common.c:291)
by 0x5D4ABF5: driConvertConfigs (dri_common.c:310)
by 0x5D58414: dri3_create_screen (dri3_glx.c:945)
by 0x5D39829: AllocAndFetchScreenConfigs (glxext.c:815)
by 0x5D39C57: __glXInitialize (glxext.c:941)
by 0x5D3290A: GetGLXPrivScreenConfig (glxcmds.c:174)
by 0x5D34F38: glXQueryExtensionsString (glxcmds.c:1307)
by 0x4F83038: glXQueryExtensionsString (in /usr/local/lib/libGL.so.1.7.0)
by 0x4F2EA6B: ??? (in /usr/lib/x86_64-linux-gnu/libwaffle-1.so.0.6.0)
by 0x4F2A0D7: waffle_display_connect (in /usr/lib/x86_64-linux-gnu/libwaffle-1.so.0.6.0)
by 0x498F42A: wfl_checked_display_connect (piglit-util-waffle.h:74)
There is one more thing which disallow us to easily fix it are different element sizes
for instance: `glx_config_create_list` allocates memory just for `glx_config`,
`driwindowsMapConfigs` for `driwindows_config` and
`createDriMode` for `__GLXDRIconfigPrivate`.
Yes it is possible but size of such fix
will be more big and complex than original one.
So it make sense only if the malloc overhead
really is a big problem there.
Acked-by: Eric Engestrom <[email protected]>
Signed-off-by: Andrii Simiklit <[email protected]>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3406>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3406>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The fallback to the non-shm put path used the wrong width here
as the pixmap is still allocated in a shared segment, so the
width needs to reflect that.
Fixes: 02c3dad0f3b4 ("Call shmget() with permission 0600 instead of 0777")
Reviewed-by: Michel Dänzer <[email protected]>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3823>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3823>
|
|
|
|
|
|
|
|
|
|
|
|
| |
If an attempt to create an shm pixmap in XCreateDrawable fails
then it ends up with the shmid == -1. This means the get image
path needs to fallback so return false in this case to use the
non-shm get image path.
Fixes: 02c3dad0f3b4 ("Call shmget() with permission 0600 instead of 0777")
Reviewed-by: Michel Dänzer <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3823>
|
|
|
|
|
|
|
|
|
| |
This adds return values to the get image path, so the caller can fallback.
Fixes: 02c3dad0f3b4 ("Call shmget() with permission 0600 instead of 0777")
Reviewed-by: Michel Dänzer <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3823>
|
|
|
|
|
|
|
|
| |
useful if FPS is low.
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3590>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3590>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is not always ->rgbBits, because there are cases where that could
be 32 but we're (legally) bound to a depth-24 pixmap. The important
thing to have match here is the actual server-side notion of depth. You
can look this up (at modest expense) from the xlib visual info if the
fbconfig has a visual. But it might not, so if not, fetch it (at
slightly greater expense) from XGetGeometry. Do this at GLX drawable
creation so you don't have to do it on the SwapBuffers path.
Apparently this fixes glx/glx-swap-singlebuffer, which is unintentional
but quite pleasant.
Fixes: mesa/mesa#2291
Fixes: 90d58286 ("drisw: Fix and simplify drawable setup")
Reviewed-by: Eric Anholt <[email protected]>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3305>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3305>
|
|
|
|
|
|
|
|
|
|
| |
We were supplying __DRI2_THROTTLE_SWAPBUFFER, rather than the obvious
choice of __DRI2_THROTTLE_COPYSUBBUFFER. This meant that we hit the
swap-based frame throttling. glXCopySubBuffer doesn't seem like it's
intended to be a frame boundary, so we'd like to avoid this throttling.
Tested-by: Michel Dänzer <[email protected]> # DRI3 only
Reviewed-by: Michel Dänzer <[email protected]>
|
|
|
|
|
|
|
|
| |
Helps point the user to the specific device that's having issues, since
you're increasingly likely to have more than one.
Gitlab: https://gitlab.freedesktop.org/mesa/mesa/issues/107
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
| |
XDestroyImage will mark the segment as to-be-destroyed, but it will
persist until we detach it, and we weren't doing so.
Cc: [email protected]
Gitlab: https://gitlab.freedesktop.org/mesa/mesa/issues/121
Reviewed-by: Adam Jackson <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We don't want to require a visual for the drawable, because there exist
fbconfigs that don't correspond to any visual (say a 565 pixmap|pbuffer
config on a depth-24 display). Fortunately, we don't need one either.
Passing the visual to XCreateImage serves only to fill in the XImage's
{red,green,blue}_mask fields, which libX11 itself never uses, they exist
only for the client's convenience, and we don't care. And we already
have the drawable depth in glx_config::rgbBits. So replace the
XVisualInfo field in the drawable private with a pointer to the
glx_config.
Having done that driswCreateGCs becomes trivial, so inline it into its
caller.
Gitlab: https://gitlab.freedesktop.org/mesa/mesa/issues/1194
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
There's no reason to have two GCs here. The only difference between
them is that swapgc would generate graphics exposures, except we only
ever use this GC for PutImage, and PutImage doesn't generate graphics
exposures. We also don't need to explicitly ChangeGC to GXCopy, because
that's the default.
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Apparently this provokes crashes elsewhere in code unrelated to
MakeCurrent. I hate GLX so very very much.
This reverts commit 999c2aed8826f403b071f52b040ce25b56d35f9d.
Gitlab: https://gitlab.freedesktop.org/mesa/mesa/issues/1207
|
|
|
|
|
|
| |
This reverts commit 0d635ccc912d7122f35f81eec27d8b2c0a2a7a28.
Gitlab: https://gitlab.freedesktop.org/mesa/mesa/issues/1207
|
|
|
|
|
|
|
|
|
|
| |
This is the GLX counterpart to EGL_KHR_no_config_context. Contexts may
now be created without reference to an fbconfig, in which case it is
treated as compatible with any fbconfig (and thus any GLX drawable).
Khronos: https://github.com/KhronosGroup/OpenGL-Registry/pull/102
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Only relevant for indirect contexts, so let's get that code out of the
common path.
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were using the current drawable of the context to name the
appropriate screen for creating the bitmaps. But one, the current
drawable can be None, and two, it can be a GLXDrawable. Passing either
one as the second argument to XCreatePixmap will throw BadDrawable. Use
the root window of the context's screen instead.
Gitlab: https://gitlab.freedesktop.org/mesa/mesa/issues/89
LOLed-by: Kristian H. Kristensen <[email protected]>
Reviewed-by: Kristian H. Kristensen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
atof() is locale-dependent (sigh), which means 1.3 becomes 1.0 if the
locale's decimal separator isn't a full-stop. Just use the protocol
major/minor instead. This would be slightly broken if the server
generically implements 1.3+ but a particular screen is only capable of
less, but in practice no such servers exist.
Gitlab: https://gitlab.freedesktop.org/mesa/mesa/issues/74
Reviewed-by: Eric Engestrom <[email protected]>
|
|
|
|
|
| |
Gitlab: https://gitlab.freedesktop.org/mesa/mesa/issues/64
Reviewed-by: Adam Jackson <[email protected]>
|
|
|
|
|
|
|
| |
This slot is always filled in with __glFillImage.
Reviewed-by: Michel Dänzer <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When run in optirun, applications that linked to `libGLX.so` and then
proceeded to querying Mesa for extension strings caused a SEGV in Mesa.
`glXQueryExtensionsString` was calling a chain of functions that
eventually led to `__glXQueryServerString`. This function would call
`xcb_glx_query_server_string` then `xcb_glx_query_server_string_reply`.
The latter for some unknown reason returned `NULL`. Passing this `NULL`
to `xcb_glx_query_server_string_string_length` would cause a SEGV as the
function tried to dereference it.
The reason behind the function returning `NULL` is yet to be determined,
however, simply checking that the ptr is not `NULL` resolves this. A
similar check has been added to `__glXGetString` for completeness sake,
although not immediately necessary.
In addition to that, we stumbled into a similar problem in
`AllocAndFetchScreenConfigs` which tries to access the configs to free
them if `__glXQueryServerString` fails. This, of course, SEGVs, because the
configs are yet to have been allocated. Simply continuing past the configs
if their config ptrs are `NULL` resolves this. We also switch to `calloc`
to make sure that the config ptrs are `NULL` by default, and not some
uninitialized value.
Cc: [email protected]
Fixes: 24b8a8cfe821 "glx: implement __glXGetString, hide __glXGetStringFromServer"
Fixes: cb3610e37c4c "Import the GLX client side library, formerly from xc/lib/GL/glx. Build it "
Reviewed-by: Adam Jackson <[email protected]>
Signed-off-by: Hal Gentz <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
The GLX extension strings are independent of any context, so abusing the
direct_support bit to control this extension's visibility is wrong.
This reverts commit 079d0717fc896bc8086b037d0ed22642274986c7.
Reported-by: Michel Dänzer <[email protected]>
Reviewed-by: Michel Dänzer <[email protected]>
|
|
|
|
|
|
|
| |
GLX_EXT_import_context operates only on indirect contexts, a direct
context cannot possibly support it. Without this change the extension
will appear in the combined GLX extension string even if it is missing
from the server string, indicating a lack of required server support.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix this build error on macOS.
../src/glx/apple/glx_empty.c:158:4: error: void function 'glXQueryGLXPbufferSGIX' should not return a value [-Wreturn-type]
return 0;
^ ~
Fixes: 3dd299c3d5b8 ("glx: Sync <GL/glxext.h> with Khronos")
Signed-off-by: Vinson Lee <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
Reviewed-by: Adam Jackson <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Right now it always returns zero, but as of:
commit a48a6b8a400e6e92961cf7b7b4c287e8e9875f39
Author: Adam Jackson <[email protected]>
Date: Tue Nov 14 15:13:05 2017 -0500
glx: Prepare driFetchDrawable for no-config contexts
We were hoping it would return true if the drawable could actually be
looked up. It wasn't, so that didn't go very well. With the most recent
update to <GL/glxext.h> glXQueryGLXPbufferSGIX (correctly) returns void,
so there's no longer anything else besides driFetchDrawable that depends
on the return value from __glXGetDrawableAttribute.
Acked-by: Eric Engestrom <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
| |
Minor fixups required to keep the prototypes matching and to remove
mention of retired enums.
Acked-by: Eric Engestrom <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
| |
Acked-by: Eric Engestrom <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
glx doesn't read the masks from the dri config directly, but for consistency
add shifts to the glxconfig.
Signed-off-by: Kevin Strasser <[email protected]>
Reviewed-by: Adam Jackson <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
| |
These are redundant with glx_config::renderType, let's just use that
consistently.
|
|
|
|
| |
Reviewed-by: Eric Engestrom <[email protected]>
|
|
|
|
|
|
| |
Simpler, less failure prone, less malloc overhead, what's not to like.
Reviewed-by: Eric Engestrom <[email protected]>
|
|
|
|
| |
Reviewed-by: Eric Engestrom <[email protected]>
|
|
|
|
|
|
| |
'minimum_size' is not, in fact, an argument to this function.
Reviewed-by: Eric Engestrom <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Eric Engestrom <[email protected]>
Reviewed-by: Adam Jackson <[email protected]>
|
|
|
|
|
|
|
| |
These days it is not GLX only and it does not work with all TLS
implementations.
Reviewed-by: Eric Engestrom <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Eric Engestrom <[email protected]>
Acked-by: Eric Anholt <[email protected]>
Tested-by: Vinson Lee <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
This automates the include_directories and dependencies tracking so that
all users of libmesa_util don't need to add them manually.
Next commit will remove the ones that were only added for that reason.
Signed-off-by: Eric Engestrom <[email protected]>
Acked-by: Eric Anholt <[email protected]>
Tested-by: Vinson Lee <[email protected]>
|
|
|
|
|
|
|
| |
It's better to test for needed functions instead of using external
knowledge about presence in this or that C library.
Reviewed-by: Eric Engestrom <[email protected]>
|
|
|
|
|
|
|
|
| |
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111016
Fixes: a47c525f3281a2753180e076c7e9b7772aff8f06
("meson: build glx")
Acked-by: Emil Velikov <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
| |
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110709
Fixes: 22a9e00aab66d3dd6890 ("glx: Implement the libglvnd interface.")
Signed-off-by: Eric Engestrom <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This `gen_scrn_dispatch.pl` has never existed, in the sense that NVIDIA
never published it. There have been a number (6) of commits to fix
various things in there over the years, and never anything from NVIDIA.
For all intents and purposes this file is hand-written and
hand-maintained, and we're on our own.
Let's make this clear by removing this misleading comment.
Suggested-by: Eric Anholt <[email protected]>
Signed-off-by: Eric Engestrom <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Acked-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix compilation where the DWORD type is used with a format, after
-Werror-format added by c9c1e261.
Some Win32 API types are different fundamental types in the 32-bit and
64-bit versions. This problem is then further compounded by the fact
that whilst both 32-bit Cygwin and 32-bit MinGW use the ILP32 data
model, 64-bit MinGW uses the LLP64 data model, but 64-bit Cygwin uses
the LP64 data model. This makes it near impossible to write printf
format specifiers which are correct for all those targets.
In the Win32 API, DWORD is an unsigned, 32-bit type. So, it is defined
in terms of an unsigned long, except in the LP64 data model used by
64-bit Cygwin, where it is an unsigned int.
It should always be safe to cast it to unsigned int and use %u or %x.
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit e91ee763c378d03883eb88cf0eadd8aa916f7878.
This seems to have broken a number of wine games. Lets revert
everything for now and try again later.
Acked-by: Adam Jackson <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110632
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110590
|
|
|
|
|
|
|
| |
Leftovers from when autotools was deleted.
Signed-off-by: Eric Engestrom <[email protected]>
Reviewed-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
|
| |
One special case, `src/util/xmlpool/.gitignore` is not entirely deleted,
as `xmlpool.pot` still gets generated (eg. by `ninja xmlpool-pot`).
Signed-off-by: Eric Engestrom <[email protected]>
Reviewed-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To quote Uli Schlachter, who understands this stuff more than I do:
> The function __glXSendError() in mesa's src/glx/glx_error.c invents an X11
> protocol error out of thin air. For the sequence number it uses dpy->request.
> This is the sequence number of the last request that was sent. _XError() will
> then update dpy->last_request_read based on the sequence number of the error
> that just "came in".
>
> If now another something comes in with a sequence number less than
> dpy->last_request_read, since sequence numbers are monotonically increasing,
> widen() will incorrectly add 1<<32 to the sequence number and things might go
> downhill afterwards.
`__glXSendErrorForXcb` was also patched, as that's the function that
`glXCreateContextAttribsARB` actually uses.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99781
Cc: [email protected]
Fixes: ad503c41 'apple: Initial import of libGL for OSX from AppleSGLX svn repository'
Reviewed-by: Adam Jackson <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
Signed-off-by: Hal Gentz <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Acked-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
Acked-by: Marek Olšák <[email protected]>
Acked-by: Jason Ekstrand <[email protected]>
Acked-by: Bas Nieuwenhuizen <[email protected]>
Acked-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
XQueryExtension merely tells you whether the extension exists, it
doesn't tell you whether you're local enough for it to work.
XShmQueryVersion is not enough to discover this either, you need to
provoke the server to do actual work, and if it thinks you're remote it
will throw BadRequest at you. So send an invalid ShmDetach and use the
error code to distinguish local from remote.
[airlied: fixed bug not resetting xshm_error to 0 on success,
which made later stuff fail completely.]
Reviewed-by: Eric Anholt <[email protected]>
Reviewed-by: Dave Airlie <[email protected]>
Signed-off-by: Adam Jackson <[email protected]>
|
|
|
|
|
|
|
|
|
| |
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: 9777c4234b0e ("loader: drop the [gs]et_swap_interval callbacks")
Reviewed-by: Ian Romanick <[email protected]>
|