While this is not quite as clear as in the previous commit, I still
believe this is the case, but in a bit of an indirect way:
1. EXT_texture_storage defines that GL_BGRA8_EXT is allowed to be used
in certain sitations if *either* EXT_texture_format_BGRA8888 *or*
APPLE_texture_format_BGRA8888 is supported.
2. Surprisingly, EXT_texture_format_BGRA8888 (which we do support) does
not even mention GL_BGRA8_EXT, only GL_BGRA_EXT.
3. APPLE_texture_format_BGRA8888 on the other hand (which we *don't*
support) *does* introduce GL_BGRA8_EXT, and is pretty clear about it
being intended for rendering-purposes. But it's written against GLES
1.1 instead of GLES 2 or later, so it doesn't explicitly add it to
the required tables.
I think the above tells us that GL_BGRA8_EXT is *supposed* to be a
color-renderable format, even if the way we currently support it is
rather underspecified.
It should also be texture-filterable, for the same reason as in the
previous commit.
In the longer run, we should probably add support for
APPLE_texture_format_BGRA8888, which would make things a bit clearer.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27521>
The EXT_texture_format_BGRA8888-spec is quite clear that this format is
color-renderable, so let's mark it properly as such.
It should also be texture-filterable, because in the version of OpenGL
ES it was written against all texture-formats were filterable to begin
with.
While we're at it, use the non-EXT version of the enum; it's been in the
headers since OpenGL 1.2...
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27521>
This function needs the GLES fix for all APIs now. And it should also
handle the sized internal format.
Fixes: 4de62731f4 ("mesa/main: add support for EXT_texture_storage")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27521>
this logic relies on constant indexing for compact arrays, but this is
frequently not the case for compact array builtins (e.g., gl_TessLevelOuter).
the usual strategy of lowering to temps isn't viable in TCS, which means
io lowering has to be able to handle indirect access to these builtins
without crashing
cc: mesa-stable
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27534>
The round up in 'next_address_8kb = DIV_ROUND_UP(push_constant_kb, 8)'
was not decreasing the amount of URB available for Mesh and Task, what
could cause an over allocation of URB.
There was also no minimum entries enforcement for Mesh and Task, what
could cause 0 r.mesh_entries to be set in a case where tue_size_dw is
90% > than mue_size_dw. Same for r.task_entries when Task is enabled.
Also adding a few more asserts to help debug.
This fixes at least dEQP-VK.mesh_shader.ext.properties.mesh_payload_size
in LNL but it has potential to fixes other Mesh tests as well.
Cc: mesa-stable
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27555>
There is at least one case in a future commit where the compiler can't do
this automatically.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27587>
It's not necessary if we don't remove entries from the hash table,
which we don't have to do because we are going to destroy it anyway.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27586>
When we start generating indirect draws, we'll generate values ourself
and point the HW vertex buffer entries to right location from the
device.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26797>
Iris does not use Gfx11+ SGVS extended parameters, so we have to rely
on the old Gfx9 method of providing the parameters through vertex
buffers.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26797>
We're about to introduce a hard dependency on OpenCL functions in Iris
& Anv to generate commands. Intel-clc has been modified to generate
serialized NIR.
A number of builders are doing cross builds, so we can't use the
intel-clc built in that cross build. Other builds like ASAN/MSAN also
complain when running the built version of intel-clc because of
uninitialized values in the packaged LLVM libraries from the
x86_64-base image.
To solve those problems we build a host version of intel-clc and use
that binary in the cross build to generate the serialized NIR.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26797>
This will be used to generate a serialized NIR of functions for
internal shaders.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26797>
When doing query result copies in 3D mode, we're flushing the render
target cache, but the shader writes go through the dataport.
Fixes flakes/fails in piglit with shader query copies forced with Zink :
$ query_copy_with_shader_threshold=0 ./bin/arb_query_buffer_object-coherency -auto -fbo
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: b3b12c2c27 ("anv: enable CmdCopyQueryPoolResults to use shader for copies")
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26797>
