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>
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>
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>
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>
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>
