In addition to the DLL names being different, we don't have to do the versioning work since we don't have to fuss with known bad versions (for example).
Co-authored-by: Ethan Lee <flibitijibibo@gmail.com>
Co-authored-by: David Jacewicz <david.jacewicz@protonmail.com>
Co-authored-by: tieuchanlong <tieuchanlong@gmail.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19022>
Only add SV_SampleIndex if there exists a sample-rate var that has either flat
interpolation or centroid (and therefore can't force sample rate implicitly),
unless there is also a sample-rate var that doesn't have those properties.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20614>
There's VK tests that have mismatching interpolation specifiers between FS
and the previous stage. For structs, that resulted in different types, which
breaks DXIL validation.
We could link the shaders and have that overwrite the interpolation field from
the previous shader, but we could also just not care and always use float.
I don't see any regressions from that.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20614>
User varyings are linked by both name and register. The name is based
on how many *variables* are before it in final driver_location sort
order, not necessarily how many registers are before it.
In some cases where clip/cull distance are involved, it's possible
for one shader to write into a part of the cull distance that's
ignored by a downstream shader, but because linking is done by
*whole* register locations, and clip/cull can be combined using
*fractional* register locations, this is hard to detect. Since no
non-sysvals end up using fractional locations, just put all non-sysvals
first so they always generate the same semantic names for the same
register locations.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20346>
There are a lot of optimizations in opt_algebraic that match ('ine', a,
0), but there are almost none that match i2b. Instead of adding a huge
pile of additional patterns (including variations that include both ine
and i2b), always lower i2b to a != 0.
At this point in the series, it should be impossible for anything to
generate i2b, so there /should not/ be any changes.
The failing test on d3d12 is a pre-existing bug that is triggered by
this change. I talked to Jesse about it, and, after some analysis, he
suggested just adding it to the list of known failures.
v2: Don't rematerialize i2b instructions in dxil_nir_lower_x2b.
v3: Don't rematerialize i2b instructions in zink_nir_algebraic.py.
v4: Fix zink-on-TGL CI failures by calling nir_opt_algebraic after
nir_lower_doubles makes progress. The latter can generate b2i
instructions, but nir_lower_int64 can't handle them (anymore).
v5: Add back most of the hunk at line 2125 of nir_opt_algebraic.py. I
had accidentally removed the f2b(bf2(x)) optimization.
v6: Just eliminate the i2b instruction.
v7: Remove missed i2b32 in midgard_compile.c. Remove (now unused)
emit_alu_i2orf2_b1 function from sfn_instr_alu.cpp. Previously this
function was still used. 🤷
No shader-db changes on any Intel platform.
All Intel platforms had similar results. (Ice Lake shown)
Instructions in all programs: 141165875 -> 141165873 (-0.0%)
Instructions helped: 2
Cycles in all programs: 9098956382 -> 9098956350 (-0.0%)
Cycles helped: 2
The two Vulkan shaders are helped because of the "new" (('b2i32',
('ine', ('ubfe', a, b, 1), 0)), ('ubfe', a, b, 1)) algebraic pattern.
Acked-by: Jesse Natalie <jenatali@microsoft.com> [earlier version]
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Tested-by: Daniel Schürmann <daniel@schuermann.dev> [earlier version]
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15121>
In a future commit, nit_type_conversion_op won't be able to handle i2b
(and in a much later commit f2b), so switch many users to the fully
featured function.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15121>
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>
No shader-db or fossil-db changes on any Intel platform.
v2: Add missed i2b1 in ir3_nir_opt_preamble.c.
v3: Add missed i2b1 in ac_nir_lower_ngg.c.
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Acked-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Tested-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15121>
All of the full runtime+compiler stacks reassign these driver_location
values to compact them and sort between shader stages, but for the
spirv2dxil tool, we leave the original shader's "location" intact. That
means that there can be holes in the driver_location space, and simply
counting how many inputs there are can lead to collisions. So instead
place all sysvals after the last-used driver_location.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7811
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20253>
This change should avoid any accidental rounding issues because of
border colors getting stored in a float in dxil_wrap_sampler_state. It
also switches us to using the correct helpers for nir_const_value so we
can avoid any weird uninitialized data failures that can be caused by
filling out the fields in the struct directly.
Fixes: b9c61379ab ("microsoft/compiler: translate nir to dxil")
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19689>
Unconditionally lowering prevents GL drivers from natively
implementing these ops. Drivers that need lowering should set
lower_uadd_carry and lower_usub_borrow on nir_shader_compiler_options to
get the nir lowerings.
Tested with dEQP-GLES31.functional.shaders.builtin_functions.integer.*
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19704>
The error when include simple_mtx.h in glsl_types.h:
../src/microsoft/compiler/dxil_function.c
In file included from ../src/compiler/glsl_types.h:37,
from ../src/compiler/nir_types.h:36,
from ../src/compiler/nir/nir.h:44,
from ../src/microsoft/compiler/dxil_signature.h:28,
from ../src/microsoft/compiler/dxil_module.h:37,
from ../src/microsoft/compiler/dxil_function.h:48,
from ../src/microsoft/compiler/dxil_function.c:24:
../src/util/simple_mtx.h:37:12: fatal error: valgrind.h: No such file or directory
37 | # include <valgrind.h>
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19154>
This is almost always a nir_instr and updating the src of a nir_if will
have to work slightly differently in the future.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Acked-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12910>
We don't actually use any of the new features, but that's okay, it's
still valid DXIL at the higher shader models.
Reviewed-by: Giancarlo Devich <gdevich@microsoft.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18022>
