This requires shader-side lowering, which is handled in
dxil_nir_lower_vs_vertex_conversion().
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/15955>
This fixes a crash in this test:
dEQP-VK.renderpass2.suballocation.simple.color_unused_omit_blend_state
Fixes: 2d0798440b ("dzn: Add support for dynamic rendering")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17027>
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>
This logic accidentally got flipped in a refactoring. Let's correct it!
Fixes: e293691a99 ("dzn: Get rid of the render pass logic")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16997>
textureLoad() doesn't work on cube images. We need to lower cube
images to 2D arrays.
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>
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>
That's still a dummy linking we do here, and it's likely to be
incorrect for complex scenarios. Not sure the previous situation
was any better though, and at least, doing that allows us to
get rid of the special cases we have in dxil_signature.c.
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>
Vertex shaders are allowed to define input variables pointing to the
same location but a different, or even variables that overlap other
variables, as long as only one of them is used in a shader invocation.
One way to support that case would be to merge overlapping variables,
but we can also declare one input element per variable, and make those
point to the same input slot/offset. The only limitation with the
second approach is the maximum number of VS input registers, meaning
that only (32 - num_sysvals) input variables can be defined.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16221>
Now that dxil_spirv_nir.h exposes an helper to run the
DXIL-SPIRV specific passes, we can handle the varying linking
on our side and tell nir_to_dxil() we don't want automatic
varying index/register assignment, which should fix a bunch
of compiler errors.
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>
Linking should be done in reverse order, starting from the last
pipeline stage and going backward, so we can eliminate outputs from the
previous stage that are never used by the next stage, and possibly
kill some instructions and input variables too.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16221>
No need to keep them around if they're unused. Moreover, this should
allow the linking step to get rid of outputs when the next stage
doesn't use them.
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>
Extract NIR passes out of spirv_to_dxil() so we can re-use them
without separately and do the varying linking in Dozen. This way
we will also be able to use vk_shader_module_to_nir() which
takes care of the SPIRV -> NIR translation, plus a bunch of
common lowering passes.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16221>
We need the fix adding a Block decoration to the BuiltIn struct in
SpvModuleScopeVarParserTest_BuiltinPosition_BuiltIn_Position_Initializer.spvasm.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16221>
VkRenderingAttachmentInitialLayoutInfoMESA provides information about
the initialLayout -> currentLayout that's expected when we begin a
render pass. Let's take it into account.
Fixes: 2d0798440b ("dzn: Add support for dynamic rendering")
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16792>
In mingw's `<unknwn.h>`, it's defeind __REQUIRED_RPCNDR_H_VERSION__ to 475,
so that gcc/mingw won't raise compiling error that because directx/d3d12.h
define __REQUIRED_RPCNDR_H_VERSION__ to 500, but the maximal supported __REQUIRED_RPCNDR_H_VERSION__ in mingw
are 475.
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16767>
Right now, we just consider the size of the accessed portion of the
push constant array, but it doesn't necessarily reflect the size
of the UBO we should declare.
Fixes: de1e941c59 ("microsoft/spirv_to_dxil: Lower push constant loads to UBO loads")
Reviewed-by: Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16703>
We're not declaring an array of bytes but an array of uint32. Let's
fix the element_count we pass to glsl_array_type().
Fixes: de1e941c59 ("microsoft/spirv_to_dxil: Lower push constant loads to UBO loads")
Reviewed-by: Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16703>
For applications that doesn't have a terminal, it's useful to get output
like nir_log etc output somewhere.
This outputs these to stderr.txt and stdout.txt in the current user's
home directory, typically in C:\Users\my-user\.
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16640>
It's geneunely useful to wait for the debugger to attach in some cases.
So let's add a debug-flag and staill untik the debugger has attached.
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16640>
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>
Similar to commit c6cddd2e17 ("lavapipe: Use the correct ICD path on
Win32"), but applied to dozen.
Suggested-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16634>
D3D12 fences are capable of handling binary operations, but the
current dzn_sync implementation doesn't match vk_sync expectations
when sync objects are used to back semaphores. In that case, the wait
operation is supposed to set the sync object back to an unsignaled
state after the wait succeeded, but there's no way of knowing what
the sync object is used for, and this implicit-reset behavior is not
expected on fence objects, which also use the sync primitive.
That means we currently have a semaphore implementation that works
only once, and, as soon as the semaphore object has been signaled it
stays in a signaled state until it's destroyed.
We could extend the sync framework to pass an
implicit-reset-after-wait flag, but, given no one else seems to
need that, it's probably simpler to drop the binary sync
capability and rely on the binary-on-top-of-timeline emulation provided
by the core.
Fixes: a012b21964 ("microsoft: Initial vulkan-on-12 driver")
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16629>
