Implement it locally with the common implementation.
Signed-off-by: Chad Versace <chadversary@chromium.org>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18000>
The patch looks asymmetic because the extension was promoted to 1.3 but
not its feature struct.
Signed-off-by: Chad Versace <chadversary@chromium.org>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18000>
This extension has no Vulkan API, only SPIR-V API.
Signed-off-by: Chad Versace <chadversary@chromium.org>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18000>
when compute shaders can be precompiled, they can be precompiled asynchronously
which allows the implementation of the parallel shader compile hooks
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18197>
The extension disrupts assumptions in venus. It gives
vkCreateFooPipelines an additional success code,
VK_PIPELINE_COMPILE_REQUIRED, which allows some pipelines to succeed
creation and others fail.
Tested with 'dEQP-VK.*cache_control*' at vulkan-cts-1.3.3.1.
pass/fail/skip/warn = 15/0/0/3
Warnings were from long pipeline compiles on a full debug build in host
and guest.
See: https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/890
Signed-off-by: Chad Versace <chadversary@chromium.org>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17847>
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>
it's been long enough, and there's no technical reason why drivers
shouldn't have this implemented
ZINK_DESCRIPTORS environment variable is preserved for future use
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18065>
Newcomers may want to test traces locally and understand how the replay
works.
Acked-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Signed-off-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17347>
Varying interpolation is quite involved in the hardware. Now that I
understand how it works, add some documentation. This documentation is
too long and uses too much fancy formatting to put inline with the XML,
so put in our external documentation space.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17198>
This extension introduces a new layout which allows applications
to both render and sample from the same image inside the same draw
(aka. feedback loops).
Previously, the GENERAL layout was used and this introduced some
rendering artifacts because the hw can't read&write DCC/HTILE for
the same image, and we try to keep it compressed on GFX10+.
This helps fixing corruption with D3D9 and RPCS3 games which
are candidate for feedback loops.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4411
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17883>
Introduce new cache type, the Mesa-DB. This is a single-file read/write
cache that is based on the read-only Fossilize DB cache. Mesa-DB supports
cache size capping. It's a much more efficient cache than the multi-file
cache because Mesa-DB doesn't have the inode overhead. The plan is to make
Mesa-DB the default cache implementation once it will be deemed as stable
and well tested. For now users have to set the new MESA_DISK_CACHE_DATABASE
environment variable in order to active the Mesa-DB cache.
Mesa-DB cache is resilient to corrupted cache files and doesn't require
maintenance from users and developers. The size capping is implemented
by evicting least recently used cache items and compacting the cache
database files with the evicted entries. In order to prevent frequent
compaction of the cache, at minimum a half of cache is evicted when cache
is full.
Acked-by: Timothy Arceri <tarceri@itsqueeze.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16888>
