The hardware's clear color conversion feature unfortunately requires
invalidating the texture cache for every fast clear. To avoid the
performance penalty that comes with the invalidation, avoid using the
hardware feature and write out the converted clear color pixel
ourselves.
When testing a patch which moves a state cache invalidate to occur after
fast clears instead of before, this prevents the following failures on
icl/zink:
* piglit.fast_color_clear.fcc-read-after-clear sample tex
* piglit.spec.arb_clear_texture.arb_clear_texture-cube
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30646>
Prevents the next patch from failing many multisampled, signed integer
rendering tests. For example:
dEQP-VK.renderpass2.suballocation.multisample_resolve.r8_sint.samples_4
Cc: mesa-stable
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30646>
We don't have an RSD descriptor on Valhall, and the vertex
attributes are part of the driver descriptor set, which we
re-emit anyway.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30736>
Quite a few things are common to Valhall/Bifrost. Specialize what's
different, and move the move to the root driver directory.
We don't compile it on v10 as this requires the cmd_buffer bits
that are not yet defined.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30736>
When PANVK_DEBUG=dump, all internal buffers get dumped, but not the user
ones, because they don't have a host address attached to them. Let's
register one when mappings dump is enabled.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30736>
The hardware limit on Valhall is 16 descriptor tables, but we reserve
one for our internal descriptors (dummy sampler, vertex attributes and
dynamic buffers), which leaves us with 15 user descriptor sets.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30736>
The JM implementation of queue_finish() is simple enough to be inlined,
but that won't be the case of the CSF implementation. So let's make
this function per-arch so we can move it to panvk_vX_queue.c.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30736>
We will have a new BO pool for CS buffers in the CSF backend.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30736>
It makes the reset of command buffers a tad simpler, and it allows
re-cycling push sets.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30736>
Co-developed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30736>
Co-developed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30736>
Dynamic rendering local read allows the application to use subpass input
attachments with feedback loops. But unless legacy RPs where it's
possible to determine feedback look at creation time, with dynamic
rendering it's not possible.
To fix that, the driver needs to determine at draw time if a feedback
loop is present, and it needs to decompress DCC/HTILE if necessary.
See https://gitlab.khronos.org/vulkan/vulkan/-/issues/3928 for more
information.
Note that VKCTS is still missing coverage but this has been reported.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11127
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30124>
VK_KHR_dynamic_rendering_local_read allows the application to sample
from a subpass input attachment where this attachment is also the color
attachment (aka. feedback loop). With legacy RPs, it's easy to detect
that at RP creation time by looking at the input<->color indices but
with DRLR this needs to be determined dynamically.
This flag would help when legacy RPs are converted to dynamic rendering
because it's not possible to know if a subpass used input attachments.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30124>
Now that we are explicitly checking for all supported formats, start
rejecting anything that isn't supported. This should make it easier to
avoid accidentally support formats without enabling the right
extensions-bits first.
A few tests regress on Lima, because we (corretly) deny using GL_FLOAT
as a texture component type. This should be fixed in the Piglit case to
skip the test there instead, but for now let's just update and document
the change.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29835>
Half-float textures got a bit strange in GLES2; they were added by the
OES_texture_float extension, but that added a *different* enum with a
*different* value than what ended up in ARB_half_float_pixel and GLES3.
So, we need to check separately for these. The former one is only
supported on GLES.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29835>
RG integer-textures are only supported on OpenGL if the combination
of EXT_texture_integer and ARB_texture_rg is supported. It's also
supported on GL3, but both of those extensions are required there
anyway. In addition GLES3 is supported.
BGR, BGRA and alpha integer-textures are only supported by
EXT_texture_integer.
Luminance and luminance-alpha integer-textures similarly, but are
unsupported in core contexts, because general luminance support is
removed.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29835>
This one is fairly trivial; this format has only ever been added by the
EXT_abgr extension. We always support it on GL, but never on GLES.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29835>
BGR and BGRA formats are either supported by desktop GL or by the
EXT_texture_format_BGRA8888 extension. Either of these should always be
supported, so let's just assert it and return true.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29835>
Most of these are either always supported, or supported on GL
compatibilitry profile. There's a few exceptions, though.
Luminance, luminance-alpha and alpha formats were removed from core
profiles, but are supported in all versions of GLES.
Float formats were always supported on desktop, but on GLES it was
initially added as a GLES2 extension through OES_texture_float, and
finally promoted to core in GLES3. However, since we check for
OES_texture_float support to to enable GLES3 support, only checking
for the extension is sufficient.
The 16-bit BGRA formats are supported on GL from version 1.2, and on
GLES by the EXT_read_format_bgra extensions. Either of these should
always be supported, so let's just assert this and return true.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29835>
GL_DEPTH_COMPONENT is supported from OpenGL 1.4 and later, or using
OES_depth_texture on OpenGL ES.
GL_DEPTH_STENCIL is supported from OpenGL 3.0 on, or by
EXT_packed_depth_stencil. The latter is always supported in the first
place, so no need to test for the former.
In addition, there's an interaction between OES_depth_texture and
OES_packed_depth_stencil that allows this on OpenGL ES 2.0 and later.
The end result is that we alway support GL_DEPTH_STENCIL, with the
notable exception of OpenGL ES 1.x.
Similarly, we always support either EXT_packed_depth_stencil or the OES
variant, both of which adds support for the GL_UNSIGNED_INT_24_8 type.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29835>
This type is allowed in OpenGL 1.2, which is guaranteed on desktop GL.
For OpenGL ES, it got introduced in EXT_texture_type_2_10_10_10_REV as
well as OpenGL ES 3.0. However, we already require
EXT_texture_type_2_10_10_10_REV for OpenGL ES 3.0 support, so just
checking for the extension should be enough.
We already have a helper that does all of the above, so let's use that
one.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29835>
Shared exponent only works if we have EXT_texture_shared_exponent (which
is required by GL 3.0 support), or GLES 3.
While we're at it, drop the needless and conservative check for GL 2.0
(which incorrectly lets through GLES2 as well).
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29835>
Following up on f8c0a99d52 ("anv: emit conditional after gfx state
flushing"), this should have been applied everywhere.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 0147908a89 ("anv: predicate emission of STATE_BASE_ADDRESS")
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30803>
Values over 2^16 as ue(v) are encoded with more than 32 bits,
but radeon_enc_code_fixed_bits can only handle 32 bits at max.
Change radeon_enc_code_ue to code the leading zeros separately.
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30672>
There is no need to separate these by VCN version.
For VCN < 3.0 transform skip must be disabled and for VCN < 2.0
SAO must be disabled.
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30672>
This removes the internal DPB management logic, which was unnecessary as
it was duplicating what applications already do, and it was also causing
issues when the internal DPB would de-sync from application DPB (eg.
driver removes reference that application still intends to use).
DPB is now dynamically resized instead of using fixed number of slots.
This also saves a lot of memory with HEVC encoding, as that was always
using the max_references which va frontend sets to 15.
Move reconstructed pictures to the end of the context and meta buffers
to ensure resizing works correctly.
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30672>
