This version claims to support validator version 1.6, but doesn't
actually have the 1.6 changes (PSV v2, PSV resource v1, barycentrics).
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17603>
This is a huge pain because it's an array, meaning that accessing
an entry in the array now depends on the validator version to use
the right element stride.
We could always just store the v1 and downconvert if needed... but
this isn't *that* bad that I felt I had to do it that way.
Reviewed-by: Enrico Galli <enrico.galli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17603>
Instead of counting the number of UAV arrays, it counts the
number of actual UAVs declared. This is more correct, but we
need to do the same accounting to set the 64 UAVs flag.
Reviewed-by: Enrico Galli <enrico.galli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17603>
This starts actually updating the always-read/never-written
masks while processing the shader. Note that we follow DXC's
lead here and treat "always read" as "sometimes read."
This isn't strictly required, but might help drivers out.
Reviewed-by: Enrico Galli <enrico.galli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17603>
This version of the validator starts adding usage masks into
the DXIL, which then are expected to match the PSV and signature
data. The usage masks are "correct" meaning that the never-writes
mask no longer includes bits outside of components 0-3.
A future change will actually compute useful masks.
Reviewed-by: Enrico Galli <enrico.galli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17603>
A future change will start computing component masks while
processing I/O instructions, and only having to compute
a mask for one component per instruction simplifies things.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17603>
We're about to lower I/O to scalar, which means we'll end up with
multiple writes to position, and none of them has enough info to
fill in the blanks.
This causes a test that previously crashed on WARP (due to
StoreOutput with an undef not being handled) to fail more
gracefully - but that failure means that the test spends
forever just outputting errors, so explicitly skip it.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17603>
First, preprocess the signatures, strictly based on the variables
in the nir shader. Then, later, after the actual shader contents
have been processed, we emit the metadata.
This lets shader processing rely on the pre-processed data (e.g.
the row -> ID mapping needed for large VS inputs) while also allowing
the signature data to rely on data gathered during the shader traversal
(e.g. which components are actually used).
Reviewed-by: Enrico Galli <enrico.galli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17603>
Instead of using the short-lived semantic structure (that's used to
fill out the long-lived signature and PSV data), use the long-lived
ones. This is staging so we can hold off on emitting the metadata
until later.
Reviewed-by: Enrico Galli <enrico.galli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17603>
While SPIR-V's OpKill is block terminating, the converted discard
intrinsic is not block terminating. This can lead to issues where
instruction could be placed after discard.
This patch adds an extra pass that drops all instructions after discard
before we convert discards.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17474>
get_dword_size() is misleading, its name implies it's returning
a size in dwords, but it's actually returning a size in bytes.
This led to a wrong size passed to emit_cbv(). Instead of fixing
get_dword_size(), let's inline the code in emit_ubo_var().
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17230>
Fix defect reported by Coverity Scan.
Side effect in assertion (ASSERT_SIDE_EFFECT)
assignment_where_comparison_intended: Assignment var->type =
glsl_int_type() has a side effect. This code will work differently in a
non-debug build.
Fixes: afb64e10c1 ("microsoft/compiler: Move d3d12_fix_io_uint_type() to dxil_nir.c")
Suggested-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17097>
We currently have two implementations of the same logic. Let's pick
the d3d12 one, move it to dxil_nir.c and let nir_to_dxil() call it
when appropriate.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17039>
It's like load_sample_id except it shouldn't force per-sample shading
when not already enabled. In that case, we simply return 0.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16926>
Use an unreachable() statement instead of the incorrect assertion in the
unsupported intrinsic path.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16926>
This flag should be set to true when the RWTexture is attached a vector,
and we always declare a vec4 right now, so it should always be true.
Might be worth reworking the dxil_module_get_res_type() to use a scalar
when the image only has one component.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16926>
emit_barrier_impl() was still checking the nir_var_uniform flag to
detect images, which is no longer correct.
Fixes: cfdc7ee066 ("spirv: Use nir_var_mem_image")
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16926>
DXIL metadata strings and function names have a limited size. Truncate
the name when they don't fit. This is a quick&dirty workaround since it
doesn't address the problem for all kind of strings, and doesn't ensure
there's no collision in the function names after the truncation. That's
not an issue right now because I don't think we have implementations
keeping more than one function (the entrypoint), but it might be a
problem at some point.
Acked-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16961>
We can't use linear interpolation on integer types, and varyings using
a struct type might actually contain only fp32 members, in which case
interpolation should happen as requested.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16961>
These functions only deal with images, so let's make that clear.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16904>
As far as I can't tell, there's no native operation doing this
equivalent of fquantize2f16. Let's lower this operation to
if (val < MIN_FLOAT16)
return -INFINITY;
else if (val > MAX_FLOAT16)
return -INFINITY;
else if (fabs(val) < SMALLER_NORMALIZED_FLOAT16)
return 0;
else
return val;
which matches the definition of OpQuantizeToF16:
"
If Value is an infinity, the result is the same infinity.
If Value is a NaN, the result is a NaN, but not necessarily the same NaN.
If Value is positive with a magnitude too large to represent as a 16-bit
floating-point value, the result is positive infinity. If Value is negative
with a magnitude too large to represent as a 16-bit floating-point value,
the result is negative infinity. If the magnitude of Value is too small to
represent as a normalized 16-bit floating-point value, the result may be
either +0 or -0.
"
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16959>
Looks like some hardware needs this info in the shader to match the
topology. Since there's no spot in the shader info for it, we're
currently using the array size of the TCS input vars to store it.
Cc: mesa-stable
Reviewed-by: Paul Dodzweit <paul.dodzweit@amd.com>
Tested-by: Paul Dodzweit <paul.dodzweit@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16920>
Now that all nir_to_dxil() have transitioned to explicit linking, we
can drop the auto_link parameter and simplify the signature logic along
the way.
Reviewed-by: Enrico Galli <enrico.galli@intel.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16221>
Letting the compiler decide which slot should be used for varyings when
it doesn't know about the varyings written/read by the previous/next
stage doesn't work well. So let's the caller decide when it wants
automatic index/register assignment through a dedicated parameter,
instead of assuming Vulkan users always want that.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16221>
Right now, nir_to_dxil() assumes driver_location on inputs will be
contiguous, which is true for GL, and also true for Vulkan shaders
with the current implementation. But we are trying to delegate
the varying linking step to Dozen, and that means the driver will
assign the driver_location field.
For everything except vertex shaders this works fine, because we
are in control of the ID we assign to each variable, and can make
sure no holes exists in this assignment, but vertex inputs expect
the index value (which is directly extracted from the
driver_location field) to match the input index defined at pipeline
creation time. The compiler has a hack to treat Vulkan differently
and extract the index from the var->data.location field instead,
but that's a bit confusing.
Moreover, the input_mappings[] array is already indexed with
the var->data.driver_location field in the input load emission
path, so it makes sense to index it with the same field when
emitting signatures.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16221>
Sometimes you can end up with tex instructions that have sampler deref srcs, even though
they don't need them, e.g. a txs. In this case, still fix up those derefs in the sampler
splitting pass rather than leaving them pointing to a typed sampler.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16639>
Otherwise, the code to actually run Release() might not be loaded or
callable anymore.
Fixes: 193cf76c ("microsoft/compiler: add common dxil-validator API")
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16225>
When per-sample shading is forced and all input variables have a flat
interpolation, DXIL validation detects a mismatch between the
SampleFrequency property and the fact that no variables are per-sample
and SV_SampleIndex is never read. When that happens, add a dummy
SV_SampleIndex.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15916>
Jesse Natalie
Emma Anholt
Enrico Galli
Boris Brezillon
Vinson Lee
Yonggang Luo
Louis-Francis Ratté-Boulianne
Erik Faye-Lund
Timothy Arceri