25.3.1 was planned for the day before the US Thanksgiving holiday, but
it slipped due to that holiday. The current plan puts 25.3.3 on
Christmas Eve, which will be missed for the same reason. To attempt to
fix this, I've updated the plan to move the missed release to this week,
with all releases re-aligned with that date. This moves the Christmas
Eve release to New Years Eve. We could possibly slip that by a week into
the new years as there is likely to be less work than normal done at
that time.
Due to the change in schedule I've removed one planned release, as we
should reach 25.3.Last and 26.0.1 at roughly the same time with one less
release.
Also update the last 25.2 release to match.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38757>
RADV_PERFTEST=sparse is a new option to enable experimental
support for sparse features when they aren't enabled by default:
- gfx6 supports sparse, albeit with a reduced feature set
- gfx7 supports 3D images (with non-standard block shape)
and unaligned mip sizes
- gfx8 supports the same feature set as gfx7
(Polaris behaves more stable than other gfx8, so we had
already enabled it by default on Polaris for a long time.)
We pass all dEQP-VK.*sparse* tests on gfx6-8 when running on
a single thread however it may cause hangs or failures
when executing the tests on multiple parallel jobs.
We plan to enable this by default when we deem it stable enough.
Until then, users can already test some games that use it.
Note, at the moment there are some unsolved problems in the
amdgpu kernel driver regarding sparse bindings on these GPUs.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38553>
Unlike textures, we can't easily do format-conversion of the data
before, because the source is a buffer object and not a texture object.
But we already have a hammer for this in Mesa, which means we'll drop
the ARB_texture_buffer_object extension support, but only for the OpenGL
compatibility profile. We still get GL 4.6, both core and compatibility.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38162>
Unlike textures, we can't easily do format-conversion of the data
before, because the source is a buffer object and not a texture object.
But we already have a hammer for this in Mesa, which means we'll drop
the ARB_texture_buffer_object extension support, but only for the OpenGL
compatibility profile. We still get GL 3.1 exposed.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38162>
Unlike textures, we can't easily do format-conversion of the data
before, because the source is a buffer object and not a texture object.
But we already have a hammer for this in Mesa, which means we'll drop
the ARB_texture_buffer_object extension support, but only for the OpenGL
compatibility profile. We still get GL 3.2 exposed.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38162>
While OpenGL 3.1 does require texture buffer objects, the ARB spec for
this requires support for texture buffers with alpha, luminance,
luminance-alpha and intensity formats in addition to RGBA formats. The
version of texture buffer objects that ended up in the OpenGL spec (even
in the compatibility spec) does not require these formats.
But, we don't even need to check this, because this is already included
in the GLSL 1.40 requirement that's also checked. So this shouldn't make
us expose GL 3.1 in cases where it isn't supported in the first place.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38162>
This extension seems to be supported on GC3000 (HALTI2) and later hardware.
While no explicit feature bit documents this capability, testing
confirms that the required vertex formats work correctly on these GPUs.
This patch adds the missing B10G10R10A2 vertex format variants
(UNORM, SNORM, USCALED, SSCALED), gates support behind the HALTI2
feature check, and updates features.txt to reflect the new capability.
All relevant piglit tests pass.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38446>
Netcat locks on to the first connection so if one tried to use
breadcrumbs again Netcat will appear as if it didn't receive
anything. Use `-k` so that it accepts another connection.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38419>
Add a new MESA_LOG_PREFIX environment variable that allows fine-grained
control over log prefixes in file logger output on Linux. The variable
accepts a comma-separated list of options:
- "tag": include the tag prefix (e.g., "MESA:")
- "level": include the level prefix (e.g., "info:")
By default, both tag and level are included. Users can customize the
prefix by setting MESA_LOG_PREFIX to any combination (e.g., "tag",
"level", "tag,level", or empty string for no prefix), making the output
more flexible and readable for different use cases.
Other loggers (syslog, Android logcat, Windows debugger) are unaffected
and continue to include tag and level information as appropriate for
their format.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38217>
I routinely don't update the docs because the build (hawkmoth in
particular) is a pain. The prior instructions almost worked, except that
on Debian you need to use a venv (which is a good idea to do for py3-clang
as well for reproducibility, anyway), and the versions that were listed
didn't actually run any more due to a revoked dependency.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38266>
Setting MESA_VK_VALIDATE_SHADER_BINARIES will cause the shader code to
round-trip every shader through [de]serialize and only ever use the
deserialized version. This catches bugs where the driver may drop
things in the [de]serialization process. It also deserializes the new
shader again and compares it against the original to ensure that
deserialize -> serialize is idempotent.
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36647>
Dylan Baker