For those drivers that don't make full use of the 64 bits in
pipe_query_result.u64.
Applications will make use of it via GL_QUERY_COUNTER_BITS to handle
when the value rolls over.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10770>
We don't have any special requirements for this, so we can just expose
the extension.
The tests in CTS have an issue where they only check if a format is
supported for sampling but don't check if an image with that format
can be created for sampling. In our case, since we can't sample
1D depth/stencil images, this causes affected tests to crash in the
simulator (they pass on the device though). There is an issue with
a fix here:
https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/3923
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18489>
Implement natively by always returning invalid feedback. This is a legal
(but useless) implementation according to the spec.
In the future, I want to return the real feedback values from the host,
but that requires changes to the venus protocol. The protocol does not
know that the VkPipelineCreationFeedback structs in the
VkGraphicsPipelineCreateInfo pNext are output parameters. Before
VK_EXT_pipeline_creation_feedback, the pNext chain was input-only.
Tested with `dEQP-VK.pipeline.*.creation_feedback.*`.
The tests in vulkan-cts-1.3.3.0 are buggy. I submitted a fix to dEQP
upstream; see below.
Results with the bug:
Passed: 0/30 ( 0.0%)
Failed: 12/30 (40.0%)
Not supported: 18/30 (60.0%)
Warnings: 0/30 ( 0.0%)
Results with bugfix:
Passed: 12/30 (40.0%)
Failed: 0/30 ( 0.0%)
Not supported: 18/30 (60.0%)
Warnings: 0/30 ( 0.0%)
See: https://gerrit.khronos.org/c/vk-gl-cts/+/10086
See: https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/909
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Signed-off-by: Chad Versace <chadversary@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18035>
We now have lowering-code in the mesa state-tracker, meaning we no
longer need this feature.
Fixes: e4ff42684b ("mesa/st: enable bptc extension with fallback")
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18434>
LLVM 16 requires this since [0] and instead of just going all over the
various directories and adding overrides it should be easier to just
raise this globally. GCC supports C++17 since GCC 8 (2018), Clang since
version 5 (2017). Debian Buster (oldstable) has GCC 8.3 and Clang 7.0,
so all major distributions should have this and there shouldn't be an
issue with bumping.
[0] <b4e9977fc1>
Closes: <https://gitlab.freedesktop.org/mesa/mesa/-/issues/7031>
Signed-off-by: Kai Wasserbäch <kai@dev.carbon-project.org>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: David Heidelberg <david.heidelberg@collabora.com>
Reviewed-by: Ganesh Belgur Ramachandra <ganesh.belgurramachandra@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17966>
We have fine NIR lowering for this (already called from mesa/st), no need
for a separate GLSL pass.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18361>
It is just a renamed VK_ARM_rasterization_order_attachment_access.
Zink depends on it to expose KHR_blend_equation_advanced_coherent
Passes GL tests via Zink:
dEQP-GLES31.functional.blend_equation_advanced.*
KHR-GLES31.core.blend_equation_advanced.*
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18420>
There are many subtleties to laying out twiddled images on AGX. Document
the known ones in a central place. Many of the hairy details of
twiddling were discovered by Asahi Lina and Dougall Johnson, many thanks
to them.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18167>
Every driver uses the nir_lower_system_values path now.
Reviewed-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18327>
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>
