The old impl used `get_arc` which internally calls into
`Arc::increment_strong_count` in order to protect against Arc::drop
deallocating our objects. We could also just not do that :)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27376>
For some yet unknown reason the CS L3 coherency setting is different
on MTL than DG2.
Fixes issues in tests from the subgroup :
dEQP-VK.api.buffer_marker.*
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: c8e122a738 ("anv: Implement rudimentary VK_AMD_buffer_marker support")
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27613>
It seems the hardware behavior for this is as per-spec and we are
supposed to identify as active entire quads. Particularly, there
are some derivative tests with dynamic control flow that use
subgroup ballot and require this.
However, we still need to exclude terminted lanes (OpTerminate). For
that, we keep track of the sample mask at the start of a fagment
shader start and compare it with the current sample mask.
Fixes: ('broadcom/compiler: support subgroup reduction operations from fragment shaders')
Fixes: dEQP-VK.glsl.derivate.dynamic_loop.*
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27409>
Enable drm_shim to parse a serialized intel_device_info structure from
json. When overriding the gpu hardware, drm_shim provides the stubbed
intel_device_info structure to mesa through an unused ioctl.
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27557>
intel_dev_info prints out struct intel_device_info in a user-friendly
format. Json format enables this information to be used as input for
tools.
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27557>
Generate intel_device_serialize.c from a mako template, providing
functions to dump and parse intel_device_info.
intel_device_info.py declares python objects representing all type
declarations associated with intel_device_info. It is used as a data
source for intel_device_serialize_c.py
intel_device_serialize_c.py emits a c++ file with routines to dump
or load all struct members to/from json. The json format is a direct
translation of the c structure, with 2 exceptions:
- When parsing json, the no_hw member is always set to true to
indicate that the driver's intel_device_info does not correspond to
the current platform.
- When dumping to json, devinfo_type_sha1 is calculated to be a
checksum which changes whenever intel_device_info is updated. This
checksum is encoded in json. When parsing json, the driver verifies
that the checksum matches before loading data into
intel_device_info. This verifies compatibility.
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27557>
XeSS workaround is required for Hitman 3 to launch for Intel cards.
The following was observed during launch, coming from libxess.dll:
"Intel Plugin Extension ERROR: INTC_LoadExtensionsLibrary failed"
Signed-off-by: Casey Bowman <casey.g.bowman@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27477>
idep_intel_dev ensures that headers are generated before dependent
source files are compiled. Some tools have been building without that
dependency, and encounter intermittent compilation errors on
sufficiently parallel builds.
Any target which depends on idep_intel_dev will link with
libintel_dev. Redundant link instructions can be removed.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10604
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27600>
Apparently spiregg can produce not-taken branches that somehow try
to access textures that aren't actually declared. These branches
need to be trimmed before any texture lowering is done.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27531>
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>
