According to the GL_EXT_multisampled_render_to_texture specification,
copy operations should be allowed when the extension is supported.
Previously, glCopyTexImage* would unconditionally fail with
GL_INVALID_OPERATION when copying from any multisampled framebuffer
(samples > 0), even when using render-to-texture attachments.
Fixes: d7b9da2673 ("mesa/main: fix artifacts with GL_EXT_multisampled_render_to_texture")
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Signed-off-by: Wujian Sun <wujian.sun_1@nxp.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40863>
st_cb_bitmap appends a temporary bitmap sampler view to the sampler
view array passed to set_sampler_views().
1a5c660ef5 changed this path to only release the extra YUV views
returned by st_get_sampler_views(), but the temporary bitmap view is
created locally and is not part of extra_sampler_views. It therefore
stopped being released so release the temporary bitmap sampler view
explicitly after drawing the bitmap quad.
Fixes: 1a5c660ef5 ("st/bitmap: only release YUV samplerviews")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40694>
Allows a uniform name to be passed to force_explicit_uniform_loc_zero
allowing us to set that uniform to an explicit location of zero.
Cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40448>
This sets the per-vertex point size state correctly in the presence of mesh shaders.
(fixes line is just a educated pick)
Fixes: 51d6e4404a ("mesa: allow NULL for vertex shader when mesh pipeline")
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40475>
st_texture_set_sampler_view() currently allows only one samplerview for
a given texobj per context. in a scenario where the same texobj is
bound multiple times with different samplerviews (e.g., SRGB) for the
same draw like
samplerviews[] = {view0, view1}
then st_texture_set_sampler_view() will release view0 while creating view1
before either view is actually set to the driver, and then the driver will explode
this is gross, but the best solution which avoids infinite memory ballooning
from bufferview offsets is to pass through the array of views during creation
to ensure that the cache doesn't try to prune a view it just created
caught by Left 4 Dead 2
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/15045
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40353>
st->release_counter is initialized to 0, so if we happen to call
st_add_releasebuf with a non-NULL releasebuf when st->work_counter
is 0 due to wraparound in st_context_add_work, we might end up never
calling st_prune_releasebufs.
Since st_context_add_work and st_add_releasebuf both use work_counter
as a "some work was done" and don't care about the actual value, we
can remove the wraparound which will fix the buffer not being released
issue.
Fixes: b3133e250e ("gallium: add pipe_context::resource_release to eliminate buffer refcounting")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/14955
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/14499
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40168>
We need to update the state var locations before the
st_serialize_base_nir() calls otherwise
_mesa_optimize_state_parameters() can alter params such that
variants wont be able to find the correct match when calling
_mesa_lookup_state_param_idx().
Prior to 891d46f5 this worked because after failing to match
we would end up adding additional params back in that we had
just attempted to optimise.
Fixes: a6fcc2835e ("
st/glsl_to_nir: make sure the variant has the correct locations set")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/14837
Acked-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40133>
This prevents re-entering the flush if during the flush
of a context X we end up in vbo_exec_FlushVertices_internal.
I had this issue on one machine, with the following simplified
call sequence:
glthread_unmarchash_batch
...
vbo_exec_FlushVertices(ctxA)
...
st_validate_state
...
dri3_get_buffer
loader_dri3_blit_context_get
...
dri_destroy_context(ctxB)
...
_mesa_make_current(ctxB)
vbo_exec_FlushVertices(ctxA)
The last vbo_exec_FlushVertices would hit the assert checking
flush_call_depth == 1.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39857>
This fixes some dead assignment issues detected with static analyzer.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39578>
For drivers that set allow_st_finalize_nir_twice locations are set
when the variable is created. But for variants here we update the
locations in case parameter opt pass or something else changed the
location.
Fixes: 891d46f517 ("st/glsl_to_nir: dont add duplicate state tokens")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/14837
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39867>
When a buffer is deleted, we have to remove it from all binding points.
We were re-using the code for BindBufferRange for this; however, this
caused the general binding point to be unbound (bound to NULL)
unconditionally, even if a different buffer is bound there. Fix this by
inlining the various bind calls into the delete buffers code.
cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/14755
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39659>
Since glibc-2.43:
For ISO C23, the functions bsearch, memchr, strchr, strpbrk, strrchr, strstr, wcschr, wcspbrk, wcsrchr, wcsstr and wmemchr that return pointers into their input arrays now have definitions as macros that return a pointer to a const-qualified type when the input argument is a pointer to a const-qualified type.
https://lists.gnu.org/archive/html/info-gnu/2026-01/msg00005.html
Resolves the following warnings:
src/mesa/glapi/glapi/gen/enums.c: In function '_mesa_enum_to_string':
src/mesa/glapi/glapi/gen/enums.c:7799:8: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
7799 | elt = bsearch(& nr, enum_string_table_offsets,
| ^
../src/egl/main/egldispatchstubs.c: In function 'FindProcIndex':
../src/egl/main/egldispatchstubs.c:52:7: warning: initialization discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
52 | bsearch(name, __EGL_DISPATCH_FUNC_NAMES, __EGL_DISPATCH_COUNT,
| ^~~~~~~
Signed-off-by: Rudi Heitbaum <rudi@heitbaum.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39707>
Add a new PIPE_CAP_CLEAR_MASKED capability that allows drivers to
handle buffer clears with color and stencil masks directly, instead
of falling back to drawing a quad in Mesa.
This patch introduces several changes:
1. Add the new pipe cap PIPE_CAP_CLEAR_MASKED to pipe_defines.h and
document it in the Gallium screen documentation.
2. Add color_clear_mask and stencil_clear_mask parameters to the
pipe_context::clear() hook:
- color_clear_mask (uint32_t): contains 4 color mask bits per draw buffer
(max 8 buffers = 32 bits)
- stencil_clear_mask (uint8_t): contains the stencil write mask (8 bits)
3. Update the state tracker to use the masked clear path when the
driver supports it:
- Pass ctx->Color.ColorMask for color buffer clears
- Pass ctx->Stencil.WriteMask for stencil clears
- Allow both color and stencil clears to avoid the quad path when
masks are present and the driver advertises support
4. Update all existing driver clear() hooks to accept the new
color_clear_mask and stencil_clear_mask parameter.
This optimization allows drivers that can efficiently handle masked
clears in hardware to do so, improving performance for applications
that frequently clear buffers with masks enabled.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31512>
Rename gl_advanced_blend_mode to pipe_advanced_blend_mode and move it
to src/util/blend.h so it can be shared between OpenGL and Vulkan
drivers.
This prepares for implementing VK_EXT_blend_operation_advanced by
providing a common enum for advanced blend modes across APIs.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38929>
Lowering FP variants calls a number of passes that aren't aware of
driver locations. For drivers relying on them, make sure that they are
still correct by recomputing them rather than adding awareness to every
pass.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39328>
These are useful for displaying very high color precision images with
more than 10 bpc color depth, and also more precision than what fp16
can do on a standard dynamic range (SDR) display, where fp16 for values
in the unorm 0.0 - 1.0 range is about equivalent to at most ~11 bpc
linear color depth. This is especially useful for and aimed at scientific
applications, e.g., neuroscience and other bio-medical research cases.
At least current generation AMD gpu's released during the last 10 years
and supported by amdgpu-kms + atomic modesetting do allow for scanout of
such 16 bpc framebuffers and of up to 12 bpc output to suitable HDMI or
DisplayPort high precision displays.
We gate the format behind a new driconf option 'allow_rgb16_configs',
which defaults to true, but allows to disable the formats if any issues
should arise.
Most regular applications won't need the high display precision of
these new 16 bpc 64 bpp formats which have higher memory and bandwidth
requirements, and therefore a potential undesired performance impact
for regular apps. Followup per-platform enablement commits will use
the EGL_EXT_config_select_group extension to put these 16 bpc unorm
formats into a lower priority config select group 1, so they don't get
preferably chosen by default by eglChooseConfig(), but must be explicitely
requested by client applications which really need the high color
precision of these 64 bpp formats and are happy to pay the potential
performance impact. Thanks to Adam Jackson for pointing me to the
EGL_EXT_config_select_group extension.
If the format would be put into the default config select group 0, a
simple EGL eglChooseConfig() call would end up choosing these formats,
which is not what such regular apps would want.
Tested to not cause any change on native X11/EGL and X11/GLX, which only
supports at most 30 bpc / 32 bpp formats.
Followup commits will enable these formats for the EGL/Wayland backend,
and on the EGL/DRM backend.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38588>
Not setting this results in an extra bitcast to float for u/int target types as
outputs are always floats, which could in turn also result in HW-dependent
behavior with having float outputs getting written to u/int targets. Whether
this ends up being handled correctly is also driver and HW specific. Zink does
not handle this, which causes problems as having FS float outputs writing to
an int attachment is undefined behavior.
Since we know the texture type already, let's use that.
Explicitly setting this to dest_type gets Zink to behave better, and could also
help other drivers by dropping the cast and marking the output type as u/int.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39352>
The Function glInternalReleaseBufferMESA is called whenever a
intermediate buffer is used by MESA internal and being released, however
it's only exported for GLES3, which leads to drawing w/o VBO not
operational for GLES1/2.
Fixes invalid operation warning in `glmark2-es2 -b build:use-vbo=false` for
GLES2 HW / any HW with MESA_GLES_VERSION_OVERRIDE=2.0 .
VBO-less drawing is possible for GLES 1.0 too, so this function is also
exported with GLES1. Tested on GLES1 with mesa-demos gears demo with
VBO allocation commented out.
Fixes: ae75b59cb5 ("glthread, tc: Fix buffer release with glthread and tc")
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39092>
Kopper draw codepath calls an internal helper called
InternalInvalidateFramebufferAncillaryMESA, which is currently only
exported for GLES3 contexts.
This leads to a warning when the underlying Vulkan driver capability
isn't enough for GLES3 or GLES version number is forced to 2.0 or the
program is a GLES1 one.
Export this internal helper for GLES1/2 too.
Fixes: 0c7994bb2d ("mapi: add InternalInvalidateFramebufferAncillaryMESA")
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39092>
Mesa internally converts some draw calls to DrawArraysInstancedBaseInstance
or DrawElementsInstancedBaseVertexBaseInstance, which are only available
in GLES contexts via GL_EXT_base_instance, a GLES3-only extension.
Export these two functions into the internal namespace for GLES 2.0
contexts too.
This fixes black screen for `glmark2-es2 -b build:use-vbo=false` (which is
the first test item for glmark2 auto test sequence) on GLES 2 HW / GLES
3 HW with MESA_GLES_VERSION_OVERRIDE=2.0 .
Fixes: 7c1f8b63ad ("glthread: work around GL_INVALID_OPERATION with OpenGL ES 1.x draws")
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39092>
