In commit 1396dc1c a new output field was added as a parameter, but this
is a problem since the signature of the function are not versionned.
The flush function didn't have a versionned output struct. So what I'm
proposing here is that if the version of the input argument is new enough
(bumped to 2 here), then we re-use the existing argument, which until now
was directly a pointer to GLsync, and instead use it as a pointer to a
versioned struct.
We're just changing one pointer type to another, so in C, this should
be fine AFAIK.
Fixes: 1396dc1c
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26315>
This was an ill-advised extension. While we advertised SWAP_COPY support,
we might implement it with a back-copy from the front buffer. And we
never advertised EXCHANGE because we couldn't guarantee it. So, if you
actually used this extension to try to reduce app redraws of the back
buffer, you might actually increase the bandwidth you used. Whoops.
Instead, GLX_EXT_buffer_age and the similar EGL extension give you
feedback on what's left in your back buffer, letting you do minimum
redraws.
This reduces our GLX visual+fbconfig count from 1410 to 940 on an llvmpipe
X server. Reducing visual counts will improve test runtime for
visual-iterating tests like piglit's glx-visuals-*.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25650>
With this change we are able to query the render node fd of a
render-only device compatible with a given KMS-only device (at the
egl/dri2 level).
It uses pipe_loader_get_compatible_render_capable_device_fd(), which was
added in commit "pipe-loader: add
pipe_loader_get_compatible_render_capable_device_fd()".
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24825>
Add support for 1555 and 4444 formats, both in RGB/BGR ordering, with
and without alpha.
These are already supported by Gallium and drivers, but not yet for
winsys surfaces. Adding these is enough to make them renderable when
using Weston on iris.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24331>
Commit f9a074dd55 ("dri2/android: Bypass throttling") dropped
unnecessary throtting in the SwapBuffers() path for android. But
unfortunately MSAA resolve got tangled up in the throttle reason
flag. So add a new flag that indicates "no throttingling, but yes
please do MSAA resolve".
Fixes: f9a074dd55 ("dri2/android: Bypass throttling")
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22719>
Provide a use flag to let the driver know that the allocated buffer will
be used for frontbuffer rendering. For example, bandwidth compressed
formats should usually be avoided for frontbuffer rendering to avoid the
visual corruption that results from this display racing with the GPU
writing header data vs. pixel data.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17799>
The DRM fourcc for this format is DRM_FORMAT_ABGR16161616 = 'AB48', not
__DRI_IMAGE_FOURCC_RGBA16161616 = 'RA48'. This should have no outward
effect for clients, since the format does not get revealed by
dri2_query_dma_buf_formats, and is otherwise only used within the
library.
Signed-off-by: Manuel Stoeckl <code@mstoeckl.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14580>
e9c3dbd046 added PIPE_BIND_DRI_PRIME but it was only set when
importing a prime buffer.
This commit adds handling of this flag in the other codepath = the
one where the prime buffer is allocated by the render GPU.
With this change PIPE_BIND_DRI_PRIME is still only set for the
render GPU - the display GPU will never see this flag; a future
commit will rename it.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14615>
The bug here is that the DRI context "flags" are intended to alias the
GLX context flag values, and they don't, DRI's no-error flag is GLX's
reset-isolation flag. GLX (and EGL!) treat no-error as a context
attribute, and reset isolation predates Mesa's no-error implementation
by several years. The GL_KHR_no_error spec does describe it as a
"context flag", though, so maybe that's why we do it as a (DRI) context
flag.
In order to unalias these we need a new contract with the loader. We
remove the old __DRI_NO_ERROR extension, and add a new
__DRI_RENDERER_HAS_CONTEXT_NO_ERROR value to query. Loaders can key on
that to know to pass no-error-ness through as a context attribute,
matching the GLX/EGL calling convention. We go ahead and define
__DRI_CTX_FLAG_RESET_ISOLATION as well, and update the drivers to refuse
it since we don't support it yet.
This means mismatched drivers/loaders will not be able to create
no-error contexts. Too bad. If you want performance that badly you can
build both things at once.
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12474>
__declspec(dllimport) isn't needed for linking to functions, extern
is sufficient. The preprocessor define used to determine when to
set it (_DLL) was incorrect, since that preprocessor define is set
anytime you're linking against dynamic CRT as opposed to static CRT.
Reviewed-by: Bill Kristiansen <billkris@Microsoft.com>
Reviewed-by: Marek Olák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12776>
