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>
It makes no sense to add the active heaps to the free heaps, just to
remove them again. Instead, let's move them from the one list to the
other.
This fixes a crash in Doom 2016 after a while, due to resource
exhaustion.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16514>
This code just got duplicated a lot. There is still more, but the
remaining instances do a bit more than just removing other functions.
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16348>
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>
This controls the whole lowering of "make tex ops with implicit
derivatives on non-implicit-derivative stages be tex ops with an explicit
lod of 0 instead", but it's really hard to describe that in a git commit
summary.
All existing callers get it added except:
- nir_to_tgsi which didn't want it.
- nouveau, which didn't want it (fixes regressions in shadowcube and
shadow2darray with NIR, since the shading languages don't expose txl of
those sampler types and thus it's not supported in HW)
- optional lowering passes in mesa/st (lower_rect, YUV lowering, etc)
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16156>
The key is supposed to be the dzn_event pointer, not the VkEvent
object, even if they do match in practice on 64bit builds.
Fixes: a012b21964 ("microsoft: Initial vulkan-on-12 driver")
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16109>
Unfortunately it's not as simple as passing the indirect draw count
buffer to ExecuteIndirect. The compute job that populate the execute
buffer also needs to know the number of entries that need to be
patched. Instead of transitioning the indirect count buffer from
GENERIC_READ to INDIRECT_ARGUMENT we just keep at as a read-only
resource and copy the draw_count value to the exec buffer in the
compute job.
Acked-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15914>
The core provides generic render-pass -> dynamic-rendering wrappers,
so let's rely on them instead of implementing our own logic.
Suggested-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15913>
This is how D3D12 works, so nothing really complicated here. We just
add a bunch of states to the render state, patch the pipeline building
logic to support dynamic rendering, and add new functions to
Suggested-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15913>
