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>
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>
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>
In VAAPI applications already need to do DPB management, but for each
picture to encode we only get the reconstructed surfaces needed to
encode this picture instead of entire DPB. Drivers need to know the
current size and layout of DPB, so keep track of entire DPB contents
in frontend.
This allows drivers to directly get the DPB layout as used by
application instead of trying to re-build it from limited information
they have available (frame numbers), which only works in the basic cases
and otherwise will de-sync from application (driver may remove pictures from
DPB that the application still want to use).
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Reviewed-By: Sil Vilerino <sivileri@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30672>
Boris Brezillon