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>
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>
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>
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>
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>
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>
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