Bifrost will require more work
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Signed-off-by: Ashley Smith <ashley.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35789>
This extension is implemented for v3d, but we forgot to update the
documentation.
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36042>
Similar to how support for X11's DRI2 protocol was deprecated in 24.2,
begin deprecating EGL_WL_bind_wayland_display (including
eglBindWaylandDisplayWL et al) by moving it behind a legacy-wayland
build option.
This extension was originally created in a pre-dmabuf world, where we
didn't have a universally-accepted way of exchanging buffers between
client and compositor, or even really the ability to describe formats
and modifiers universally.
Since then, the world has settled on dmabuf with DRM FourCC and
modifiers. We've had the zwp_linux_dmabuf_v1 protocol for 10 years now:
both clients and compositors implement this protocol to handle buffer
sharing. Compositors either use EGL_EXT_image_dma_buf_import or the
Vulkan dmabuf extensions to import these into GPU world.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36026>
wl_drm is the legacy protocol which is used to support
EGL_WL_bind_wayland_display to exchange buffers between client and
server. It's supported dmabuf for a very long time, and as a private
protocol for Mesa's use, there is no need to carry around support for
old codepaths, as all relevant drivers support dmabuf.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35885>
This extension was designed in a pre-dmabuf world, to allow us to share
DRM buffers based on global GEM names (generated with flink, as distinct
from context-local GEM handles).
We've had dmabuf since Linux kernel 3.4, so there's no need to carry
around this extension which encourages users to do bad things - namely,
to expose their buffers with a global ID that anyone can access - and
requires us to carry around some irritating support code.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35885>
DRI2 was hidden behind a legacy-x11 build option back in the 24.2
release. It's now been a year, so let's get on with removing it so we
can simplify our winsys interactions.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35885>
The extension allows returning 0 if a given rate is unknown, which
allows us to support this on all GPUs, but since the extension depends
on Vulkan 1.1, we only expose it on v10+ for now.
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35155>
The KHR_shader_expect_assume dEQP tests use dynamic rendering without
first checking that the driver supports 1.3 or the
KHR_dynamic_rendering extension
Signed-off-by: Simon Perretta <simon.perretta@imgtec.com>
Acked-by: Frank Binns <frank.binns@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33998>
In some cases a format may be supported in a more limited way by the
hardware. For example, formats with NPoT pixel sizes. A driver might
normally prefer that mesa/st use R8G8B8X8 rather than R8G8B8. But if
the user wants to (dma-buf/etc) import R8G8B8, it is still possible,
and in this case zero copy is more important.
So add a PIPE_BIND_x flag as a hint to the driver when checking if
a format is supported.
Signed-off-by: Rob Clark <rob.clark@oss.qualcomm.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35982>
We're currently not using image layouts in PanVK so we can advertise
this extension without additional changes.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: John Anthony <john.anthony@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35911>
Almost all the gitlab-ci.yml files in Mesa have their hidden jobs defined in
an include file. This may have started with !25238 with the idea to simplify
the re-use of hidden jobs by other projects. But we missed the .gitlab-ci
directory.
Signed-off-by: Sergi Blanch-Torne <sergi.blanch.torne@collabora.com>
Acked-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Reviewed-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35427>
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>
