If line smooth, stipple, quad_prims and a collection of other things are needed, zink produces a geometry shader to create them.
This code is disabling that from happening when there is no geometry shader support.
This removes a constant barrage of validation issues when trying to draw basic triangles.
Some of this missing functionality will be added back in later.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33059>
This returns the underlying device pointer but as an opaque
uintptr_t.
This will be required because libdrm_amdgpu will return the
same device when called multiple times from the same process.
radeonsi relies on the pointer value to identify if the device
are the same and adjust the synchronisation logic based on that.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33081>
This reported support for Profile2 on all VCNs that support Profile0
and reported no supported formats if Profile2 was not supported.
Instead, we should not advertise the Profile2 at all if not supported.
Fixes: e359b3c525 ("radeonsi/vcn: support 12bit YUV420 AV1 decoding")
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33092>
The progressive YUV shader used in vl_compositor_yuv_deint_full
does the same thing as util_compute_blit, but it also supports rotation.
Remove vlVaPostProcBlit and instead move the code to vlVaPostProcCompositor.
Reviewed-by: Thong Thai <thong.thai@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32919>
We're already limiting the maximum texture-size based on the available
system memory, so we shouldn't really need to limit this here. In
addition, the state-tracker also limits the max framebuffer size to
16384, so we don't have to worry about limiting this to the framebuffer
size either.
So I don't think we have a good reason to artificially limit the texture
size here. This allows us to support larger textures than 8192, which is
especially useful to support OpenCL images with RustiCL.
Unfortunately, while the HW supports up to 64k texture sizes, Gallium
currently caps us at 32k. So let's stick with that as the new limit for
now.
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32866>
We don't want huge textures to take up large amounts of system memory.
On a system with 1GB of RAM, this would limit us to 256 MB, which is the
same memory usage as a texture of 8192 x 8192 with 4 bytes per
component, which is what we currently limit max texture size to anyway.
The goal here is really to allow using larger textures on systems with
more memory, but that bit comes in a later patch in this series.
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32866>
We're doing a better job at selecting the tiler hierarchy mask in PanVK,
so let's move that to common code and reuse it for the Gallium driver as
well.
The logic to disable the first level for large tile-sizes has been left
at the call-sites, because this is specific to V10 GPUs and later, so it
doesn't apply to the JM code-paths.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32866>
We can handle invalidation of the FBO attachments at job
creation. It solves that we were skipping invalidations in jobs
that had been created by a clear call, as before this change
invalidations were only taken into account the first draw calls
of the job. In these cases where there is a clear after FB
invalidation the resource attachment was tracked as invalidated
for more time than expected. So the stores of the job with the
clear were not being loaded by the next job attaching it because
of the not correct application of the invalidation.
Fixes: 6c46890325 ("v3d: avoid load/store of tile buffer on invalidated framebuffer")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12456
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33148>
When a 2D_ARRAY view of a 3D image is created, the layer count of the 2D
view should be based on the depth of the 3D image. When
VK_REMAINING_ARRAY_LAYERS is used, we were incorrectly calculating them
from the layer count of the base image.
Fixes future tests: dEQP-VK.renderpass*.remaining_array_layers.*
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33075>
