Due to flawed logic, Chromium and Firefox thinks EXT_texture_storage
allows using GL_BGRA8_EXT for *all* texturing, including things like
glTexSubImage2D, which it does not.
However, this bug was introduced in Chromium back in 2016, and there's
also a lot of Electron apps that bundle outdated versions of Chromium.
This means it's going to be a *mess* to fix this properly while staying
within the spec.
I've opened a ticket with Khronos to consider changing the spec to make
this legal, because it seems most other OpenGL implementations allow it.
But in the mean time, let's complain a bit, but accept the behavior.
This way people can at least run browsers with hardware acceleration
again. If we decide to change the spec, we can remove this wording.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10550
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27521>
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>
