virtio-gpu cross-domain context supersedes the downstream virtio-wl.
However, there's no compositor working well with cross-domain context
yet (sommelier from ChromeOS only works robustly with virtio-wl while
being pretty broken with cross-domain). So let's just drop the legacy
piece to avoid confusions.
Reviewed-by: Corentin Noël <corentin.noel@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35680>
This change updates the documentation of the extensions.
Here are the commits where these extensions were activated:
8348c9c84d "r600: enable ARB_gl_spirv": GL_ARB_gl_spirv GL_ARB_spirv_extensions
8a1ef5bd31 "r600: enable ARB_transform_feedback_overflow_query": GL_ARB_transform_feedback_overflow_query
6fab29d37e "r600: implement EXT_window_rectangles": GL_EXT_window_rectangles
769510f1cc "r600: implement EXT_shader_image_load_store": GL_EXT_shader_image_load_store
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35547>
More driver boilerplate we don't need. We do still have to go through the
transformation in st_atom_clip.c because the clip state can get used in
draw fallbacks. This revealed that lima had a dirty bit being set that
nobody was reading.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8953>
This allows sampling from a buffer as if it was a simple (single
level/layer, linear) 2d image/texture. Add a helper to convert
struct pipe_image_view to an apprpriate fdl_layout and wire it up
in the image view and tex view paths.
Can be tested with cl cts:
./test_image_streams 2D read CL_RG CL_SIGNED_INT16 CL_FILTER_NEAREST CL_ADDRESS_CLAMP_TO_EDGE UNNORMALIZED
(for ex)
Signed-off-by: Rob Clark <rob.clark@oss.qualcomm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35447>
We do support both GL_EXT_texture_shared_exponent and GL_EXT_texture_snorm
on hardware able to deal with those formats. GL_ARB_texture_rg is limited
to HALTI5 feature level, as it requires R8 render target support, which
isn't available in earlier GPU versions.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35538>
Turnip does not use any image layouts aside from UNDEFINED, therefore, we can expose this extension.
Signed-off-by: Autumn Ashton <misyl@froggi.es>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35536>
While AMD_seamless_cubemap_per_texture gives more control over seamless
filtering than the base extension, the cap isn't strictly handled as a
superset, so we also need to set the cap for the context wide handling
to expose ARB_seamless_cube_map.
Makes piglit spec@amd_seamless_cubemap_per_texture go from skip to pass
as this test (correctly) also checks the presence of the base extension.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35527>
Reading the previous version of the docs, I had the impression that the
correct action when a farm is broken is to ping Daniel or Emma in
the #freedesktop channel. I learned that just creating an MR to disable
it immediately is fine, and am documenting this. The farm maintainer
table also wasn't mentioned in the docs previously.
Signed-off-by: Olivia Lee <olivia.lee@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35521>
Our existing descriptor implementation already supports
update-after-bind on both bifrost and valhall, but on bifrost the some
of the descriptor limits are lower than the minimum required by the
extension.
Signed-off-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35408>
PresentWait2 should be possible on any physical device, as it adds a
surface capability query that depends on common wsi code.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35414>
This already landed upstream, I just forgot to update this file.
While we're at it, update the vk 1.2-entry to only list V10+, to match
reality.
Fixes: 8ec846407d ("panvk: expose vulkan 1.3 support")
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35513>
We have all the pieces lined up now, so let's enable the memory model
extension.
Reviewed-by: Caterina Shablia <caterina.shablia@collabora.com>
Reviewed-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35502>
On GFX12, everything is compressed with DCC and it's completely
transparent to the userspace driver.
On GFX11-GFX11.5, DCC can compress everything with GENERAL and FMASK
has been merged with DCC.
On GFX10-GFX10.3, MSAA through FMASK can't be compressed with GENERAL
and this will hurt performance.
On GFX6-9, DCC can't be supported with GENERAL because no DCC stores,
so this will destroy performance.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35424>
This matches our existing behavior on both JM and CSF, where when
depthClamp is disabled, we clamp to [0,1].
Signed-off-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35224>
8x and 16x MSAA should work now, so we no longer need to deal with those
separately. We have more accurate checks for when it's supported or not
in place already.
2x MSAA isn't supported at all until v12, which we haven't finished
wiring up yet. So let's leave that one for now... We'll need some more
fixes for that anyway.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34455>
This change extends the ARB_shader_draw_parameters
algorithm to support ARB_indirect_parameters.
The linux kernel needs to be updated to support
the following PM4 commands: COND_EXEC and COND_WRITE.
Without the update, this extension is disabled.
This change was tested on cypress, palm, barts and cayman.
It passes all the piglit tests (6/6) and all the khr-gl45
tests (3/3).
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34726>
This implementation is aimed at compatibility. The
new multi draw indirect mode is unrolled at the
command stream level.
This change was tested on cypress, palm, barts and cayman.
It passes all the piglit tests (23/23) and all the khr-gl45
tests (11/11).
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34726>
Lima can't do *both* FP16 *and* 4x MSAA at the same time. And because
GLES2 requires MAX_SAMPLES to be valid for *all* supported formats,
this means we can't support MSAA at all unless we disable support for
the FP16 formats when used as render-targets.
To allow applications that needs FP16 render-targets to still support
it, we introduce a driconf that makes the opposite trade; support FP16,
but not 4x MSAA. Unfortunately, we can't support both, and still be
following the spec.
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35207>
Judging by comments in the chat, it seems the usage of the tokens in crnm is
only natural when you've been using it for a while. New users would appreciate
reading it in the documentation, beyond the help in the tool.
Also, mentioning how to create a token and what's the minimal scope of the
token to be used with the tool can help new users.
Signed-off-by: Sergi Blanch Torne <sergi.blanch.torne@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34860>
