On bifrost we only can use 3 coordinates for images, but
image2DMSArray needs 4 (x, y, sample#, and array index).
We work around this by making the image nr_samples times
higher than the original image, using the Y coordinate to
address the sample plane. This limits the maximum image
height (to 4K pixels instead of 64K pixels in the 16 sample
case) but at least allows us to use the images.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30521>
On valhall, the sample index should go in the R component
of the image load/store/lea instruction. This provides a
straightforward way to implement image2DMS and
image2DMSArray image load and store for valhall.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30521>
The nir_lower_image_atomics_to_global pass can create some image
load/stores, so we need to do the multisample image load/store
lowering after this.
Also, the pass only actually works on bifrost and below, so skip it
for valhall.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30521>
The pan_arch function is useful elsewhere, and doesn't rely on
anything else within genxml/gen_macros.h.
It's useful, for example, to find the architecture from the
GPU id in bifrost_compile.c, where before we were using ad-hoc
shifting.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30521>
The hardware's clear color conversion feature requires invalidating the
texture cache for every fast clear. We're no longer using the hardware
feature, so we longer need the invalidation.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30646>
Instead of using the clear color conversion feature by the hardware, use
software to write out the converted clear color pixel.
When testing a patch which moves a state cache invalidate to occur after
fast clears instead of before, this prevents the following failures on
tgl/zink:
* piglit.spec.arb_texture_cube_map_array.arb_texture_cube_map_array-cubemap
* piglit.spec.ext_framebuffer_object.fbo-generatemipmap-formats
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30646>
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>
