On v7-, use TEXC(op=GRDESC_DER) to convert user-provided gradient into a
gradient descriptor consumed by the hardware, and then supply that
descriptor to the TEXC instruction.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29521>
On v9+, use TEX_GRADIENT to convert user-provided gradient into a
gradient descriptor consumed by the hardware, and then supply that
descriptor to TEX_SINGLE.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29521>
Rather than adding memcpy()s to a local u32 variable, add a union
to bifrost_texture_operation so we can directly access the packed
value.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29521>
Instead of using the surface fence, store the fence in buffer.
This way the fence won't be overwritten when encoding multiple frames
using the same source surface and SyncBuffer will sync the correct job.
Also fixes possible crash when destroying coded buffer before calling
SyncSurface and possible leak when destroying or reusing coded buffer
with pending encode job without calling SyncSurface/SyncBuffer.
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31959>
VK_PIPELINE_STAGE_2_VERTEX_INPUT_BIT is equivalent to the logical OR of:
- VK_PIPELINE_STAGE_2_INDEX_INPUT_BIT
- VK_PIPELINE_STAGE_2_VERTEX_ATTRIBUTE_INPUT_BIT
VK_ACCESS_2_SHADER_READ_BIT is equivalent to the logical OR of:
- VK_ACCESS_2_SHADER_SAMPLED_READ_BIT
- VK_ACCESS_2_SHADER_STORAGE_READ_BIT
VK_ACCESS_2_SHADER_WRITE_BIT is equivalent to
VK_ACCESS_2_SHADER_STORAGE_WRITE_BIT.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31898>
Currently a630-gles-asan is running deqp-runner directly rather than
through a toml suite configuration
Convert a630-gles-asan to use a toml suite. This makes it similar to other
freedreno jobs. The two substantive consequences are:
* it runs tests in default groups of 500 instead of 5000
* it skips tests listed in `freedreno-a6xx-skips.txt`
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31916>
The `.baremetal-arm64-asan-test` job extends `.baremetal-test` and
`.use-debian/baremetal_arm64_test` but doing this is unnecessary because
all of the arm64-asan jobs also inherit the `.baremetal-test-arm64` job
which does the same thing.
Furthermore when `.baremetal-arm64-asan-test` appears last in the list of
extended jobs, as in the case of the `a630-gles-asan`, the general rules
inherited by `.baremetal-arm64-asan-test` override the more specific
driver rules and prevent the driver job from appearing in the merge
pipeline.
Simply bumping the `.baremetal-arm64-asan-test` job back earlier in the
list of extended jobs would allow the driver rules to take precedence but
then the S3_ARTIFACT_NAME, provided by `.baremetal-arm64-asan-test`, which
is specific for asan builds, is overridden.
By removing the inherited jobs from the `.baremetal-arm64-asan-test`,
this job can continue to provide the asan artifact without interfering
with the driver jobs appearing in the merge pipeline.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31916>
The `.baremetal-arm32-asan-test` job extends `.baremetal-test` and
`.use-debian/baremetal_arm32_test` but doing this is unnecessary because
the only job that extends `.baremetal-arm32-asan-test`, i.e.
`gc2000-gles2-asan`, also indirectly inherits `.baremetal-test-arm32`
which does the same thing.
Duplicating the extended jobs in `.baremetal-arm32-asan-test` can
unnecessarily cause rule overrides and unexpectedly remove jobs from
pipelines.
Remove the inherited jobs from the `.baremetal-arm32-asan-test` job so
that (when the necessary farm is enabled) `gc2000-gles2-asan` will appear
in pipelines as expected.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31916>
Fixes 'dEQP-VK.draw.renderpass.inverted_depth_ranges.nodepthclamp_deltazero'.
This is an unfortunate fix, but it's not a situation that's likely to
come up in practice. The proprietary driver does something similar.
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Co-authored-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31879>
Block all YCbCr formats from getting blit feature flags by using
vk_format_ycbcr_info.
Fixes dEQP-VK.api.info.format_properties.g10x6_b10x6r10x6_2plane_420_unorm_3pack16
and dEQP-VK.api.info.format_properties.g12x4_b12x4r12x4_2plane_420_unorm_3pack16.
Fixes: ab298b9c3a ("lavapipe: Remap 10 and 12 bit formats to 16 bit formats")
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Signed-off-by: Valentine Burley <valentine.burley@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31863>
Also change ifdef's from just `HAVE_LIBDRM` to check for both LIBDRM
and for UDMABUF HEADER. preventing unbalanced guards preventing part of
the code from being included if you just have LIBDRM or just have the
udmabuf headers.
Fixes: 4cfaf10c ("llvmpipe: Only use udmabuf with libdrm")
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31877>
We emit it for gfx8, so the assembler should support it too.
Signed-off-by: Sviatoslav Peleshko <sviatoslav.peleshko@globallogic.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31747>
Previously this bit was not clearly documented in PRMs, but gfx12 PRMs
finally list all the instructions where it is present.
Although it's unclear if it's functional for anything other than "if",
"else", and "goto", we probably still should acknowledge its existence
in other instructions.
Signed-off-by: Sviatoslav Peleshko <sviatoslav.peleshko@globallogic.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31747>
We emit it for gfx9, so the assembler should support it too.
Signed-off-by: Sviatoslav Peleshko <sviatoslav.peleshko@globallogic.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31747>
Previously this bit was not clearly documented in PRMs, but gfx12 PRMs
finally list all the instructions where it is present.
Although it's unclear if it's functional for anything other than "if",
"else", and "goto", we probably still should acknowledge its existence
in other instructions.
Signed-off-by: Sviatoslav Peleshko <sviatoslav.peleshko@globallogic.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31747>
The gallium interface always expected the driver to support multiple
in-flight feedbacks, so this shouldn't have been needed in the first
place.
Even if the driver wouldn't support it, we still can't force
applications to sync after each frame. In fact, the old VCE dual
instance feature relied on the vaSyncSurface not being called every
frame.
Reviewed-By: Sil Vilerino <sivileri@microsoft.com>
Reviewed-by: Boyuan Zhang <Boyuan.Zhang@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31933>
This was added for the VCE dual instance feature and it tries
to delay flush such as the flush is done only every second frame.
For this it requires applications not to call vaSyncSurface after
each vaEndPicture, otherwise every frame will be flushed.
When this was implemented in 2016, libva and applications were
different. Now applications will always sync surface after each
end frame, making this feature completely non-functional.
Another issue is that this is incorrect, the flush cannot be delayed
and every vaEndPicture needs to flush. This is needed to ensure
interop with other APIs (eg. sharing dmabufs with GL) works correctly.
Delaying the flush would also mean submitting the same surface
every frame for encoding (and changing the surface contents before
encoding each frame) will not work.
Reviewed-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Boyuan Zhang <Boyuan.Zhang@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31933>
This feature requires only flushing every second frame (submit two
encode jobs together), but that's not possible with VAAPI where
vaEndPicture is required to flush.
Current implementation in va frontend needs application to not call
vaSyncSurface after each vaEndPicture, but all applications actually
sync surface after each end picture so it will always flush after each
frame.
Remove this feature as the frontend implementation is wrong and it's not
even used currently because applications don't behave the way this expects.
Reviewed-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Boyuan Zhang <Boyuan.Zhang@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31933>
This change fixes the calculation of the number of cubemap
images which requires a 6x multiplier.
This commit is inspired from nir_lower_robust_access and fixes
at least the following tests on cayman:
spec/arb_shader_image_load_store/layer/imagecubearray/layered binding test: fail pass
spec/arb_shader_image_load_store/max-size/imagecubearray max size test/8x8x2046x1: fail pass
Fixes: 27f5157777 ("r600/sfn: Add lowering pass to legalize image access")
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/31626>
use mesa_clc for the spir-v part, this improves incremental build granularity.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31923>
This is a generic tool to convert OpenCL C to SPIR-V.
In the future, this will be replaced by `clang` directly using the LLVM SPIR-V
backend, but for now we need a tool in Mesa to provide this functionality with
older LLVM versions.
The important parts are that:
1. It does not depend on NIR or any real platform details. An older mesa_clc
from a previous Mesa version can generally be used to build a newer Mesa to
ease cross-OS builds.
2. Its output can be consumed without any LLVM dependence, which will untangle
the LLVM mess we have now.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31923>
Reduced the looping copy structure of a 2D array down to a single malloc
& memcpy operation to copy the entirety of the image buffer to a local
1D array copy.
With this setup, we can write the image row by row using the associated
libpng API call.
Local testing with vkcube showed ths as a large perf gain, reducing the
time it took to copy images by more than half:
Previous method:
mesa-screenshot: DEBUG: Time to copy: 251907 nanoseconds
Current method:
mesa-screenshot: DEBUG: Time to copy: 112904 nanoseconds
Also reduced swapchain image list malloc operations to one use. This
doesn't have much perf impact, but it's good to reduce the number of malloc
operations overall.
Signed-off-by: Casey Bowman <casey.g.bowman@intel.com>
Reviewed-by: Felix DeGrood <felix.j.degrood@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31793>
