These were always-crash in CI, had a comment saying they passed locally,
and now seem to be passing in CI. Just hit it as flake until someone
actually looks into it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34256>
We were never setting has_multiview. It's not actually necessary anyway,
since we can just do the optimization we were trying to do whenever
num_views is 1 instead.
This doesn't affect the actual fragment size, which was already correct,
only gl_FragSizeEXT.
Fixes: 6f2be52487 ("tu, ir3: Handle FDM shader builtins")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33991>
When bin merging we maximize instead of minimize the VSC pipe size,
which means that we fail when there are too many pipes instead of when
the pipes are too large. This means that we need to calculate
binning_possible differently, and we need to skip
tu_tiling_config_update_pipes() when binning is impossible because
otherwise we will write out-of-bounds.
Fixes: 3fdaad0948 ("tu: Implement bin merging for fragment density map")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34196>
Most implementation defined behaviors have been properly defined via
new maintenance extensions, and the mapping support is the only one
left on the table...in a very unfortunate way for historical reasons.
Meanwhile, update the host driver list for the latest that has been
tested working. Two major KVM improvements have also been documented
along with the setups that rely on those.
Acked-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34225>
CPS surfaces are marked as stencil compressed internally and
should use the fast clear depth stencil path for clearing when possible
Signed-off-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20741>
This particular scenario indicates that the CPB will be written to using
a fragment shader, disable compression to ensure the correct data is
read back from the surface later.
Signed-off-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20741>
Compressed CPS surfaces operations such as copies and clears need to be
handled through the depth stencil hw to ensure that the aux data is
handled correctly.
Signed-off-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20741>
Apparently hwconfig has not implemented this workaround.
This warning was noted on MTL and ADL.
> INTEL_HWCONFIG_TOTAL_GS_THREADS (336) != devinfo->max_gs_threads (312)
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34243>
Previously we were printing this information whenever the driver
started, but that proved to noisy.
For example, if running thousands of tests, this would cause thousands
of warnings messages to be printed. (Assuming the driver was built in
debug mode.)
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34243>
We will move this check into the `intel_dev_info` tool. Unfortunately,
this means we will be much less likely to notice inconsistencies, but
the current strategy has proven to be far too noisy.
For example, if the driver was built in debug mode, then when test
suites are running thousands of tests, the current approach can lead
to thousands of messages being printed.
Closes: mesa/mesa#12141
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34243>
Previously we'd burn 4 minutes waiting for curl to bang its head
trying to get results which would never emerge. Change this so we don't
fail on a 404, and also pull the retry down quicker, so we'll spend a
maximum of 2 minutes waiting for a server to come back, and no minutes
when the results aren't there to be fetched.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34244>
The new s3-proxy we have on fd.o is just a redirecting agent: it queries
the policy and, if allowed, returns a URL with temporary credentials
where the client can pull the real data from.
This means that nginx would see /fdo-opa/mesa-rootfs/misc?key=foo and
/fdo-opa/mesa-rootfs/misc?key=bar as distinct objects, not knowing that
it could cache only on the base URL.
Strip the query params from the nginx cache key so we can actually do
caching.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34244>
