We need to be able to validate at the API that set specialization consts
have a valid ID and the value is the correct size.
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10322>
clc_object was overloaded, containing SPIR-V binary and metadata,
and it would only sometimes contain metadata (after linking). Split
it into a more generic clc_binary class which holds some type of data
(the kind depends on where it came from), and clc_metadata which can
be independently parsed on compiled or linked data.
Rename a couple entrypoints to be more explicit about what they're
actually transforming (c_to_spirv, link_spirv, spirv_to_dxil).
Add a logger to SPIR-V binary parsing so it can report errors on app-
provided SPIR-V.
Re-order helper function parameters to be more consistent (out params last).
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10322>
The caller can allocate these however they want. They don't need
independent allocations. Removes some unnecessary failure handling.
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10322>
1. Rename it to libclc to match what it is
2. Make it opaque externally
3. Remove it from non-essential entrypoints (compile/link)
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10322>
I no longer think there's value in trying to share code on disk here between
CL and GL at runtime, especially since we're now just building GL without LLVM
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10322>
Since DXIL does not have a way to get the base/first vertex and base
instance as well as using a zero-based vertex index, these values need
to be passed in via a constant buffer.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12707>
Since DXIL does not have a way to get the number of workgroups used
during dispatch with a system-value, these numbers need to be passed in
via a constant buffer.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12707>
We do not want to set an interpolation method for vertex shader inputs.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12513>
We need this to get e.g. a default lod for some instructions when it is
not provided.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12462>
Changes:
- nir_metadata_preserve(..., nir_metadata_all) is called when pass doesn't
make progress
v2: fix build
Signed-off-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12324>
This doesn't seems to make a practical difference, but it seems better
to do it the same way as we do for outputs, as well as what DXC does.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12197>
Rather surprisingly, the value stored in the NumVectors field of the
DXIL PSV header isn't the number of vectors, but rather the *maximum*
vector used.
This makes a difference when we're not writing to the first element of
an array, where we would previously generate a validation error.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12197>
We say that they're for debug only but we don't really have a good
policy around when to set them and when not to. In particular,
nir_lower_system_values and nir_lower_vars_to_ssa which are the chief
producers of SSA values which might reasonably have a name do not bother
to set one. We have some names set from things like BLORP and RADV's
meta shaders but AFAICT, they're setting a name more because it's there
than because they actually care.
Also, most things other than nir_clone and nir_serialize don't bother to
try and preserve them. You can see in the diffstat of this commit
exactly what passes attempt to preserve names. Notably missing from the
list is opt_algebraic which is the single largest source of SSA def
churn and it happily throws names away.
These observations lead me to question whether or not names are actually
useful at all or if they're just taking up space (8B per instruction)
and wasting CPU cycles (to ralloc_strdup on the off chance we do have
one). I don't think I can think of a single time in recent history
where I've been debugging a shader issue and a SSA value name has been
there and been useful. If anything, the few times they are there, they
just throw me off because they mess up the indentation in nir_print.
iris shader-db on my system gets runtime -2.07734% +/- 1.26933% (n=5)
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5439>
If the barrier tries to apply to memory that we can't express, just
don't apply the memory portion of the barrier. Similarly, if it tries
to apply a global memory barrier at invocation level, upgrade it to
thread-group.
Reviewed-by: Enrico Galli <enrico.galli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11670>
