the non-negotiated path assumes that drivers know what implicit modifiers they're
using, but zink doesn't know what it's doing, so instead try to copy the
swapchain's modifier and reuse that since in theory it should work
Fixes: 247b8f2924 ("zink: add all format modifiers when adding for dmabuf export")
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18095>
the spec mandates that all modifiers passed to the driver be valid, so
iterate through all of them and delete the invalid ones
Fixes: 247b8f2924 ("zink: add all format modifiers when adding for dmabuf export")
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18095>
if srgb-ness isn't supported by the driver for dmabuf, bail out early with an
error message with the assumption that this would later (maybe) explode when
trying to create a view for srgb framebuffer
ref !17900
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18095>
get_ssa_temp's and NIR's bit size can differ for scalar sources.
This causes broken packing of the MIMG operands with A16/G16.
Fixes: f5f73db846 ("aco: Support 16bit sources for texture ops.")
Signed-off-by: Georg Lehmann <dadschoorse@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18008>
Separately track descriptor set layouts for pools with
FREE_DESCRIPTOR_SET disabled, instead of reusing
`radv_descriptor_pool::entries`. This saves 8 bytes for each entry and
also avoids some indirection.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16541>
The lp_rasterizer is shared across contexts, and lp_rast_fence called
without holding rast_mutex could race with rast_mutex being replaced and
unref'd on a different thread.
Fixes: a680fd078c ("llvmpipe: make last_fence a screen/rast object not a context one.")
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18116>
this is cumbersome to detect, so detect it here
the flag denotes the use of either bindless texture operations
or shader variables such that drivers can infer the use of bindless
descriptor management functionality
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18088>
Simplify things for the next patch.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18111>
Mostly because simple_mtx_assert_locked() will come in handy during
locking re-work.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18111>
*Technically* we should be unlocking with the 'disp' and not the 'dpy'
(even though they are the same thing).
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18111>
Needed for dependency on MAX_INT.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Acked-by: Eric Engestrom <eric@igalia.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18111>
Perfetto is showing mutex contention on disp->Mutex when multiple
threads are making egl calls on their own current context. This
makes it easier to see what is contending with what.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Acked-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18111>
DCC shouldn't be compressed for Vulkan feedback loops (ie. render pass
with input attachments). It looks like it has always been broken...
Note that GFX9 and earlier chips aren't affected because they don't
compress DCC on GENERAL.
This fixes
dEQP-VK.rasterization.rasterization_order_attachment_access.format*.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Joshua Ashton <joshua@froggi.es>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18104>
Since PIPE_CAP_TGSI_TEXCOORD is now enabled, texcoord is now declared
as TGSI_SEMANTIC_TEXCOORD instead of TGSI_SEMANTIC_GENERIC.
Fixes assert running REDTurbineDEMO with MTL Renderer when the guest needs to
fallback to swtnl for line stipple.
Fixes: e73443b7a5 ("svga: enable PIPE_CAP_TGSI_TEXCOORD for vgpu10 and up")
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18113>
It's noisy since Bifrost was introduced, unnecessary since we converted to
per-arch GenXML, and wrong since Valhall was added.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18094>
Architecturally, these only work for Midgard, and even on Midgard didn't turn
out to be too useful. While we're removing pandecode cruft, let's remove the
stats that just add noise to Bifrost and Valhall (and largely just noise to
Midgard too).
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18094>
It's the same core logic. Unify and let GenXML do its thing.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18094>
Eliminate some #ifdef by grouping v5 and v6 state separately.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18094>
Remove unsued width/height properties, and use cleaner C syntax to build the
return value.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18094>
There are a lot of problems with passing job_index around:
* Almost entirely unused
* Not particularly helpful even when used
* Mostly ignored for Valhall already
* Doesn't extend to CSF
It only really exists due to the early days of pandecode generating valid C code
as the trace format. With GenXML instead, that's not applicable.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18094>
It hasn't had a consistent semantic meaning since we've switched decoding over
to GenXML.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18094>
The hardware doesn't care what BO a given buffer resides in, only what GPU
address it's at. It's simpler to fetch from a GPU address, rather than the pair
of a GPU address and a backing allocation. This cleans up a lot of cruft in
pandecode.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18094>
Section 11.2.6 of the Vulkan spec states:
"Importing memory from a particular host pointer may not be possible due to
additional platform-specific restrictions beyond the scope of this
specification in which case the implementation must fail the memory
import operation with the error code VK_ERROR_INVALID_EXTERNAL_HANDLE_KHR."
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17995>
This experimental and very suboptimal implementation of graphics
pipeline library shouldn't be used by anyone, except for development
purposes. It's still under active development from my side. This
extension is only exposed via RADV_PERFTEST=gpl anyways.
It's very suboptimal because RADV doesn't yet support PS epilogs and
VS prologs need to be improved/reworked because GPL changed the logic
(eg. can't know the next stage when compiling a prolog). So, currently
the driver ALWAYS retains NIR shaders during libs creation and it links
and compiles in the final pipeline.
I have WIP branches for approximately everything but it looks simpler
to start merging an initial implementation in order to improve steps
by steps from main. This commit might look simple and short but I
already merged TON of preliminary work. RADV was definitely not ready
for GPL and it's still not completely fine. Expect refactoring again.
This implementation currently pass
dEQP-VK.pipeline.pipeline_library.* on NAVI21, except few feedback
creation tests due to CTS bugs.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17542>
For gfx pipeline libraries we would have to keep track of the gfx
state, so change how it's allocated.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17542>
It currently inherits from radv_graphics_pipeline because it's simpler
but I think it could be improved because most of fields won't be useful
for libs.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17542>
It also initializes dynamic states and active stages. It will also be
used when creating a graphics pipeline library.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17542>
It isnt used anymore, last used in tu_wsi_display.c which doesnt
exist anymore.
Signed-off-by: Yusuf Khan <yusisamerican@gmail.com>
Reviewed-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17927>
The majority of the logic here was for the Gfx8-9 sample-from-hiz
hardware feature, which only applies to AUX_USAGE_HIZ, and neither
of the combined HiZ+CCS modes. So, reorganize the function to put
the logic for each case in the case itself.
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4674>
When using HIZ_CCS_WT, we always want to use that for texturing so that
we're able to sample from the CCS buffer, which will have the latest
data due to the write-through mode.
With the previous commit in place, HiZ now exists for all miplevels
on platforms which support HIZ_CCS_WT, so we no longer need the
per-miplevel checks.
The other restrictions in this function only apply to the Gfx8-9 feature
where the sampler directly supported reading from HiZ itself, which was
removed. Hardware where HiZ and CCS can be used together doesn't have
that feature nor its restrictions.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4952
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4674>
8x4 alignment was absolutely required prior to Gfx8, and while some
things were relaxed on Gfx8-9, Nanley's experiments in issue #3788
indicated that there were still issues on those platforms.
It appears that the restrictions were relaxed on Icelake and
non-8x4 aligned HiZ "should" work on Gfx11+.
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4674>
