Every driver wants the chance to see the default variant of the shader in
the hopes of avoiding draw-time shader compiles, even if they have some
NOS compiled into the shader by st/mesa. Before, every driver had to
avoid st/mesa lowering options to get this behavior, even if they would
like to have the shared lowering code, and some drivers were just missing
the behavior because nobody had debugged that it was missing yet.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8601>
The version overrides leaked into the virglrenderer server, breaking
compiling of all sorts of shaders. We already get GLES3.1 when running
virgl on llvmpipe GL without doing any overrides.
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8854>
if compute or gfx use a resource which is already in use by the other pipeline,
we need to ensure tha we flush that pipeline now in order to have commands execute
in the expected order
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8781>
this is almost identical, the difference being that we need to explicitly
use the compute batch/program in a few places
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8781>
this is a bit different since the regular functions cycle the gfx batch
array, but the compute batch isn't in an array
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8781>
this is a massive block of code that we need to reuse for compute shaders
because we absolutely don't want to be copying it around
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8781>
these are similar to the gfx variants, but mostly smaller
some things are implemented as placeholders for now to make the code
similar to gfx programs/pipelines and thus easier to read/review
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8781>
by moving this into its own function, we can reuse it for creating a compute
batch, which will not be part of the gfx batch array
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8781>
this lets us reuse the function for gfx and compute programs without much
churn, since in C we can use a pointer to the first member of a struct and
a pointer to the struct interchangeably
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8781>
now that we have the capability to wait on specific batches, we can
check whether we need to sync with the compute queue here before trying
to map resources
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8781>
now this provides some info regarding which batches need to be flushed,
allowing gfx batches and compute batches to share resources
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8781>
I'm pretty sure this doesn't fix anything because the WSI code only
use a single VkSubmitInfo, but better be safe.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: ccb7d606f1 ("anv: Use submit-time implicit sync instead of allocate-time")
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8934>
We want more control over batching things up when possible to minimize
the round trips to i915. This breaking up of one big internal function
into helpers will be useful later.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8934>
This should no longer be necessary since the mark_block_wqm() we use to
flag break conditions as WQM now adds block to the worklist. With them
added to the worklist, get_block_needs() will add WQM to block_needs.
Adding WQM to block_needs here without adding the block to the worklist
(like we do here) can cause issues because it does not ensure that the
predecessors' branches are in WQM (needed for it to be possible to
transition to WQM in the block). This happened in an Overwatch shader.
No fossil-db changes.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Fixes: 661922f6ac ("aco: add block to worklist in mark_block_wqm()")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4066
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8446>
This automatically ensures the LAVA kernel / device-tree / rootfs files
are updated along with the build image, so any relevant changes in the
latter are reflected in the former.
v2:
* Use the same definition of DISTRIBUTION_TAG in .lava-test:amd64 as in
kernel+rootfs_amd64
v3:
* Extend comment about $MESA_BASE_TAG in .lava-test:amd64 (Eric Anholt)
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7988>
Using new .incorporate-base-tag+templates-commit & .set-image-base-tag
templates.
This automatically ensures dependent images get rebuilt along with the
base image, no more need to manually bump the dependent image tags.
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7988>
Gives us 48 more passed tests, and possibly slightly shorter job times.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4986>
