Metal does not seem to respect memory coherency for threads. Workaround 6
enforces device coherency for global loads/stores even if it should not
be needed.
Reviewed-by: Arcady Goldmints-Orlov <arcady@lunarg.com>
Signed-off-by: Aitor Camacho <aitor@lunarg.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38847>
Metal will prematurely discard fragments with side effects even if those
side effects happen before the discard. Work around this by making said
discards "optional".
Reviewed-by: Arcady Goldmints-Orlov <arcady@lunarg.com>
Signed-off-by: Aitor Camacho <aitor@lunarg.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38741>
These were accidental when I split up the large article in to multiple
documents. Let's fix that up, so we don't end up repeating this for
future documents.
Fixes: 8248cc0bf4 ("docs/panfrost: move details to separate articles")
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38738>
When discarding a fragment in Metal, it will not be demoted to helper. At
least for Apple Silicon M1 and M2. Call nir_lower_is_helper_invocation to
work around this.
Reviewed-by: Arcady Goldmints-Orlov <arcady@lunarg.com>
Signed-off-by: Aitor Camacho <aitor@lunarg.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38590>
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>
Adds build instructions and workarounds documentation.
Workarounds documentation only has the biggest offenders and
there are probably way more in code that need yet to be
documented.
Reviewed-by: Arcady Goldmints-Orlov <arcady@lunarg.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38232>
This description was incorrect in that it impiled we supported Hopper
and Blackwell A, which is not currently the case (see nvk_is_conformant
in nvk_physical_device.c).
Fixes: edd0cb6d56 ("docs/nvk: Update hardware support")
Reviewed-by: Mary Guillemard <mary@mary.zone>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38320>
Vulkan 1.0 conformance has happened on BXS-4-64, but not on other GPUs
or Vulkan versions using an upstream version of the driver. So let's
update the phrasing to include this.
And since we actually expose Vulkan 1.2 now (see next commit), let's
untangle the conformance information from the GPUs support table; this
way nobody should be confused and think we're conformant to Vulkan 1.2,
when we're not (yet).
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37678>
Due to the division of TU_DEBUG options into runtime and envvar
options, it limited where options could be set from when
TU_DEBUG_FILE was being used. This commit addresses that by allowing
the envvar to set runtime debug options even when TU_DEBUG_FILE is
active while also allowing the file to set non-runtime options if
the file included them at startup.
Signed-off-by: Dhruv Mark Collins <mark@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37580>
RD dump generation can be expensive and can only be desired for some
specific part of execution. Trigger file mechanism helps with this to a
certain degree but is still somewhat inexact.
FD_RD_DUMP_SUBMITS environment variable can be used to specify ranges of
submit indices for which RD dumps of command streams should be generated.
FD_RD_DUMP_FRAMES environment variable can similarly be used to specify
ranges of frames under which RD dumps for submitted command streams should
be generated. Frame ranges only really work with Turnip since the frame
count data is available there.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37499>
This has gotten complicated enough that we need somewhere outside of the
driver itself to give an overall flow of how the feature is implemented.
This includes a few things that are enabled in the subsequent commits,
specifically the LRZ parts.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36475>
I've been waiting for the Vulkan 1.4 results to be formally conformant
to submit this, so I didn't have to update the wording, hehe.
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36838>
The "optimizing pixomatic for modern x86" page was available on the web
archive but the "rasterization on larrabee" one was not, but fortunately
it had been copied onto another website, so link to that now.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36555>
virtio-gpu cross-domain context supersedes the downstream virtio-wl.
However, there's no compositor working well with cross-domain context
yet (sommelier from ChromeOS only works robustly with virtio-wl while
being pretty broken with cross-domain). So let's just drop the legacy
piece to avoid confusions.
Reviewed-by: Corentin Noël <corentin.noel@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35680>
Lima can't do *both* FP16 *and* 4x MSAA at the same time. And because
GLES2 requires MAX_SAMPLES to be valid for *all* supported formats,
this means we can't support MSAA at all unless we disable support for
the FP16 formats when used as render-targets.
To allow applications that needs FP16 render-targets to still support
it, we introduce a driconf that makes the opposite trade; support FP16,
but not 4x MSAA. Unfortunately, we can't support both, and still be
following the spec.
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35207>
This allows building tools for cross-compiling without building gallium
or vulkan drivers unnecessarily.
Backport-to: 25.1
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Janne Grunau <j@jannau.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34693>
While not yet officially conformant, we support all the required
features, and we pass the CTS. Let's mark off Vulkan 1.2, to make things
easier for applications.
Backport-to: 25.1
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34512>
We need GPU_FEATURES to determine if this is another variant but this
will do for now.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34032>
We need GPU_FEATURES to determine if this is another variant but this
will do for now.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34032>
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>
