Commit a52c1994aa ("intel/dev: generate declarations for struct
intel_device_info") started generating and including
intel/dev/intel_device_info_gen.h, but it's not present in the
documentation build, leading to errors:
docs/isl/formats.rst:222: ERROR: src/intel/dev/intel_device_info.h:39: 'intel/dev/intel_device_info_gen.h' file not found
docs/isl/tiling.rst:87: ERROR: src/intel/dev/intel_device_info.h:39: 'intel/dev/intel_device_info_gen.h' file not found
Add an empty header stub under docs/header-stubs to fix the build.
Fixes: a52c1994aa ("intel/dev: generate declarations for struct intel_device_info")
Signed-off-by: Jani Nikula <jani@nikula.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27573>
NGG GS doesn't perform well in some cases and having an option to
disable it for performance experiments is very useful.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27518>
It's sometimes really, really useful if GL_BGRA8 can be used as a
sized internal format, and the combination of EXT_texture_storage
and EXT_texture_format_BGRA8888 allows this (only when using
texture-storage, which is good enough in some cases). Until now,
we've only implemented ARB_texture_storage, and not the EXT
version.
So let's implement the EXT version as well, so we get the benefit
of the interaction here. This pulls in a lot of other similar
interactions as well, which also seems useful.
...because the ARB version is created from the EXT version, let's move
the EXT function definitions to the EXT extension. These should probably
have been suffixed with ARB in the ARB-version, but things seems to have
just ended up kinda confused. Oh well.
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27222>
We already had the logic implemented, but it was never really tested
(there was a comment about that)
So the advantage of this is that we now test that code (in fact, there
were a small typo on that code).
There aren't too much CTS tests for this feature, but we gets tests
like this working:
dEQP-VK.clipping.clip_volume.depth_clip.*
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10527
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27386>
Provide fd_rd_output facilities which enable constructing RD dumps that are
stored into gzip-compressed output. This matches the default behavior of
libwrap. Enabling and adjusting the behavior of functionality is done
through the FD_RD_DUMP environment variable.
Integration into Turnip's MSM backend is covered, replacing the previous
RD dump that was enabled through TU_DEBUG=rd. That debug option still
works and is the same as using FD_RD_DUMP=enable.
By default the dumps are created for each submission, using the provided
submit index. FD_RD_DUMP=combine enables gathering dumps for submissions
for the given logical device into a single file.
In the Turnip integration, FD_RD_DUMP=full will force dumping contents of
any buffer object. Additionally, with that option enabled any previous
submit will be waited on.
Specifying FD_RD_DUMP=trigger sets up a trigger file that can be used to
activate dumping manually. Writing zero or some non-integer value to the
file will disable dumping. Writing a positive integer value to it will
enable dumps for that many future submissions. Writing -1 to it will enable
dumps until disabled.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27230>
NIR caching is useful for two use cases:
- Shader permutations involving reused VS or FS.
- GPL-like engine that compiles a separate (library) variant and an
optimized (monolithic) variant, e.g. DXVK.
By caching the result of radv_shader_spirv_to_nir, permutations hitting
the cache can have their compilation time reduced by 50% or more.
There are still open questions about the memory and storage footprint of
NIR caches, which is why this is gated behind a perftest flag. In
particular, Steam doesn't want to ship NIR cache since they are
unnecessary in presence of a full precompiled shader cache. In this
commit, the cache entries do not reside in memory and are immediately
written to the disk. Further design around how the caches are stored and
how to coordinate cache type with Steam etc. is left as future work.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26696>