The dri2_allocate_buffer() can be called with arbitrary height, however
the struct pipe_resource .height0 member is uint16_t. Check height for
maximum size to avoid overflow. Note that .width0 is unsigned int, so
it does not have the same issue.
The uint16 limit comes from commit:
e6428092f5 ("gallium: decrease the size of pipe_resource - 64 -> 48 bytes")
The overflow can be triggered e.g. by requesting large BO:
```
gbm_bo_create(dev, 1, 640*480*4, GBM_FORMAT_R8, GBM_BO_USE_LINEAR);
```
Signed-off-by: Marek Vasut <marex@denx.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16513>
For images created from textures or renderbuffer, the internal
format is known so store it.
This will be used in the next commit to replaces guessing it.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16662>
This set of changes:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15649
caused a regression in Xorg when using swrast_kms:
(EE) AIGLX error: Calling driver entry point failed
This commit changes the swrast_kms driver to use a dedicated screen init function
(which I believe was overlooked); I also took the opportunity to rename the
associated plumbling to have swrast-specific names.
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16942>
This only applies to MSAA visuals. The MSAA channel order doesn't have to
match the visual, but some drivers don't support MSAA with BGR.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16327>
sw drivers don't support modifiers or dmabufs or any of that, so separate
interfaces are needed to avoid advertising extensions that will only lead
to crashes
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15802>
Debugging fd lifetime issues can be hard. Add a helper for debug builds
to print out an error if an fd is not a fence fd, and sprinkle it around
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/15094>
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>
Use createImageFromFds2 together with __DRI_IMAGE_PRIME_LINEAR_BUFFER, so
the driver's resource_from_handle hook will be aware that this specific
image is the linear buffer.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13362>
This indicates driver that a given blit is coming from the DRI
frontend.
This information can then be used to pick an appropriate blitting
method.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12763>
If we're going to have to bind them as separate planes with colorspace
conversion for sampling on the frontend, then we need to report that
they're only for external-image samplers, otherwise the lowering won't be
applied.
Fixes: 4e3a7dcf ("gallium: enable EGL_EXT_image_dma_buf_import_modifiers unconditionally")
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13038>
For being used by EGLImage import in the following commits.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12336>
We can't ask for a fence fd if we don't pass PIPE_FLUSH_FENCE_FD. Also
don't leak fences.
Fixes: abec42c9a3 ("gallium/dri: implement EGL_KHR_mutable_render_buffer")
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11202>
NV12, YUV, YUYV and UYVY handling checks !tex_usage so set
PIPE_BIND_PROTECTED after.
This fixes encrypted nv12 textures handling.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11107>
Tested with low-lantency stylus apps with this extension enabled, no
regression on the cts.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10685>
Unlike front buffer used by big GL API for front rendering,
EGL_KHR_mutable_render_buffer together with ES redirects GL_BACK to the
front buffer.
This patch adds a fallback to use back buffer and ensures no behavior
change for unrelated frontends.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10685>
dri2_resource_get_param() is called from two different places right now.
Only one of them adds the EXPLICIT_FLUSH hint to the handle usage, which
may disable the optimizations provided by this hint without a reason.
Make sure to always add this hint when appropriate.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7603>
The u_resource_vtbl indirection is going to be removed.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10659>
This implements __DRIimageExtension version 19.
Signed-off-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8106>
As documented in 6ec7e0d406 (gallium: document convention for get_handle
calls on multi-planar resources) it's the drivers responsibility to walk
the chain of resources for multi-planar resources. The get_handle interface
should always be called with the base resource by the frontend.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Acked-by: Simon Ser <contact@emersion.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10212>
This reverts the resource_get_param changes from Tomeu's commit
ab7744b280. It breaks every single
program run on iris (such as wflinfo -a gl -p glx).
iris's I915_FORMAT_MOD_Y_TILED_CCS modifier reports two planes - one for
the main surface, and a second one for the CCS surface. However, there
is only one underlying pipe_resource. We only use pipe_resource::next
for modifier information when importing buffers from elsewhere; there is
no res->next for internally allocated resources created with modifiers.
resource_get_param() is not supposed to chase res->next pointers. The
hook is intended to take the base image, and the plane, as parameters.
The driver can then walk its own data structures however it sees fit
in order to find the appropriate plane, rather than enforcing a linked
list of resources.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9847>
Previously, we were calling resource_get_handle for the first plane in
the image, regardless of what plane was being requested.
v2: - Add assert (Simon)
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5442>
I was suspicious that some entries in dri2_format_table (in
dri_helpers.c) had this field set incorrectly. It seemed like
DRM_FORMAT_ABGR16161616F and DRM_FORMAT_XBGR16161616F should have been 8
instead of 4. Upon digging I found that nothing uses the field. Fix
code by removing it.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9354>
Move the fields that should be restored by glPopAttrib into the Attrib
structure, which is the only portion of texture objects that is restored
by glPopAttrib. Also moves fields that should not be restored by glPopAttrib
out of the Attrib structure.
This is based on the GL 4.6 Compatibility spec.
Reviewed-by: Zoltán Böszörményi <zboszor@gmail.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8181>
Some DRI extension features are enabled/disabled
based on capabilities of the gallium pipe_screen
associated with the DRI screen. Additionally, the
list of extensions enabled also varied based on
features requested by the screen creator. However,
prior to this change the extension list and
extension definition structures within it were
global variables, meaning the last screen
initialized ended up defining the DRI capabilities
of all screens.
This change instead stores a copy of the
extensions which vary per screen, as well as a
copy of the extension list itself in the gallium
DRI screen structure, allowing them to vary per
screen.
Closes: https://gitlab.freedesktop.org/drm/nouveau/issues/9
Signed-off-by: James Jones <jajones@nvidia.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7175>
Share the DRI extension setup code between
dri2_init_screen and dri_kms_init_screen. There's
currently very little difference, and the sharing
will make a subsequent change to refactor this
code to use per-screen extension lists easier.
Signed-off-by: James Jones <jajones@nvidia.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7175>
Yonggang Luo
Marek Vasut
Pierre-Eric Pelloux-Prayer
Alexander Kanavin
Adam Jackson
Marek Olšák
Mike Blumenkrantz
Rob Clark
Dave Airlie
Emma Anholt
Qiang Yu
Yiwei Zhang
Lucas Stach
Ian Romanick
Simon Ser
Kenneth Graunke
Tomeu Vizoso
James Jones
Lionel Landwerlin
David Stevens