DXIL has no concept of subgroup mask ops, relative
shuffle ops, and everything is scalar.
Most wave broadcast ops support i1 overloads, except
for quad swap operations. Go figure. Use lower_bit_size
to promote those to i32 instead.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20801>
D3D's view instancing is an optional feature, and even when it's
supported, it only goes up to 4 views, where Vulkan requires a
minimum of 6 supported views. So, we need to have a path for handling
the cases where we can't use the native feature.
In this mode, pass the view ID as a runtime var. The caller is then
responsible for looping the draw calls and filling out the constant
buffer value correctly for each draw. When we get to the last pre-rast
stage, we'll additionally want to write out gl_Layer to select the
right RTV array slice. Lastly, for the fragment shader, if there's
any input attachments, those get loaded using the RTV slice instead
of the view ID. RTV slice input into the PS is done with a signature
entry (which must be output from the previous stage) rather than a
system value.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20650>
Since we don't support wide points, this isn't a useful feature, but the CTS
requires a particular point coord value for the single rasterized pixel, based
on where the original point coord fell within the pixel. Since we're not doing
a quad, we don't get free interpolation like the GL driver does, so split the
logic between vertex (transform point center into screen space) and pixel
(compute delta between current pixel/sample and point center).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20400>
Fix resource leak reported by Coverity Scan.
Resource leak (RESOURCE_LEAK)
leaked_storage: Variable file_contents going out of scope leaks the storage it points to.
Fixes: 531d17c334 ("spirv2dxil: Support linking multiple shaders")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20576>
This probably could/should be split up into multiple commits, but
it's simpler to make this a monolithic change.
This change inlines a bunch of logic from spirv_to_dxil into the
spirv2dxil tool so that linking can be done on the nir shaders.
Probably the linking functionality should be exposed in the lib/dll
form too, which means that a helper for freeing intermediate nir
would be needed too. That's TODO for now.
The tool now requires arguments to be in-order, and once a filename
is encountered, will use the previous arguments to compile the shader.
If multiple graphics shaders are passed, they're linked as if they
were forming a pipeline together.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20440>
For cases where both clip and cull are used, and a shader has both
inputs and outputs that can contain them, we need metadata to tell
us where the clip array ends and the cull array begins, since they
get combined into CLIP location registers. For outputs, this is in
the nir info, but for input we pass it in a sideband channel.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20346>
It is invalid to have Boolean variables as either shader inputs or
outputs, so there is no point to try to lower them in general. The only
use for this was some two-phase lowering of
nir_intrinsic_load_front_face that could be done in a single phase.
Create the SYSTEM_VALUE_FRONT_FACE as a uint and compare it with zero at
the same time.
No shader-db or fossil-db changes on any Intel platform.
v2: Remove dxil_nir_lower_bool_input from dxil_nir.h and drop it from
the other caller in the spirv_to_dxil codepath. Noticed by Jesse. Fix
setting bit size when loading SYSTEM_VALUE_FRONT_FACE. Caught by CI.
v3: Use nir_ine_imm. Change type of gl_FrontFacing GS output in
d3d12_nir_passes from Boolean to integer. Both suggested by Jesse.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15121>
We will need to hash var bindings if we want to cache DXIL shaders.
Let's move this pass to dzn_pipeline.c to prepare this transition.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17140>
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>
Fixes following errors:
../src/microsoft/spirv_to_dxil/dxil_spirv_nir.c
In file included from ../src/compiler/nir/nir_builder.h:365,
from ../src/microsoft/compiler/dxil_nir.h:29,
from ../src/microsoft/spirv_to_dxil/dxil_spirv_nir.c:28:
../src/microsoft/spirv_to_dxil/dxil_spirv_nir.c: In function 'dxil_spirv_nir_passes':
src/compiler/nir/nir_builder_opcodes.h:1321:11: error: 'dyn_yz_flip_mask' may be used uninitialized in this function [-Werror=maybe-uninitialized]
1321 | return nir_build_alu2(build, nir_op_iand, src0, src1);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/microsoft/spirv_to_dxil/dxil_spirv_nir.c:290:59: note: 'dyn_yz_flip_mask' was declared here
290 | nir_ssa_def *y_flip_mask = NULL, *z_flip_mask = NULL, *dyn_yz_flip_mask;
| ^~~~~~~~~~~~~~~~
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
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/16671>
Add STATIC_ASSERT to guard `dxil_spirv_shader_stage` and `gl_shader_stage`
to be same for each enum value.
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
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/16671>
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>
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>
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>
