During flat convertion, we have to pick the bit width for literals
because they could be used in multiple places as different sizes, and
that breaks the literal visitor. We currently use 32-bit types because
that is the most common use case, and we don't want to unnecessarily
add a capability.
However, if we pick a 64-bit width, we should be able to fold all of
the operations on literals. If they are only used as 32-bit value, then
ultimatlly fold them to 32-bit constants and remove the 64-bit
capabilities.
This commit updates the spir-v submodule to pull in the 64-bit interger
folding changes, and then starts to use 64-bit integer literal in flat
conversion.
Note that the problem still exists for floating point values. Spirv-opt
does not fold OpFConvert yet, we still treat the literals like a float.
Fixes#6188
---------
Co-authored-by: Natalie Chouinard <chouinard.nm@gmail.com>
The VulkanMemoryModelDeviceScope capability is now covered by the
SPIRV-Tools capability trimming pass, so it should be added here
unconditionally now.
Fixes#6066
Convert runCodeTest to lit FileCheck test and remove all the code
related to runCodeTest.
Remove effcee and re2 from git submodule since nothing is dependent on
them after the change.
These changes allow us to use DXC as as CMake subproject (via
add_subdirectory).
Commit comments from each commit:
===
cmake: allow CMAKE_INSTALL_RPATH to be defined in superproject on APPLE
platforms
As on Linux, allow CMAKE_INSTALL_RPATH to be defined in a CMake
superproject.
===
cmake: Allow LLVM_ENABLE_ASSERTIONS=OFF to disable assertions in Debug
builds
Currently, this flag is only used to enable assertions in non-Debug
builds, but is not respected in Debug builds. That is, if set to false,
Debug builds will still assert. This change fixes that.
Note that by default, LLVM_ENABLE_ASSERTIONS is true in Debug builds, so
unless it's explicitly set to false, this is a no-op for most people.
===
cmake: Allow DIRECTX_HEADERS_INCLUDE_DIR to be defined from superproject
Useful for when DXC is included as a subdirectory. In Dawn/Chrome, we
use our own mirror of DirectX-Headers instead of checking out the repo's
submodules, so we need to override this variable.
SPIRV has not yet implemented the changes in SM6.6 that allows
[derivatives
in compute, mesh, and amplification
shaders](https://microsoft.github.io/DirectX-Specs/d3d/HLSL_SM_6_6_Derivatives.html).
This is because there is no KHR
extension that enabled that capability in SPIR-V.
However, we have decided to use
[SPV_NV_compute_shader_derivatives](https://github.com/KhronosGroup/SPIRV-Registry/blob/main/extensions/NV/SPV_NV_compute_shader_derivatives.asciidoc)
to implement it for compute shader while we wait for a KHR extension.
This change only deals with the texture sample instructions.
The changes involve
1. modifying code that makes sure these only appear in fragment shaders
to allow compute shaders as well.
1. add the extension and capability
1. set the correct execution mode on the function when
the intrinsics are used in compute shaders.
This new optimization passes determines the required capabilities for a
module, and strips unneeded capabilities.
This means if some dead-code uses a capability, it won't be added as a
requirement for the module anymore.
This interacts with `[[vk::ext_capabilities]]` and
[[vk::ext_extension]]` attributes, as the extension/capability they
declare could be stripped if not required.
Still markes as draft for now as there are inconsistencies with debug
instruction I need to figure out:
- if 2 DebugScope are generated, SPIRV-Tools squash them into 1.
- seems like we started to generated the wrong ones, but test didn't saw
the 2 conflicting scopes, only checked the first one.
Updates the submodules, and disables validation on two tests. The SPIR-V
is invalid, and spir-val just started checking it. Since we have been
generating this code for a while, I do not see the need to modify the
generated code immediatly.
Add `-fspv-preserve-interface` CLI option to prevent DCE optimization
pass from compiling out interface variables. It happens if these
variables are unused.
The option may be useful when decompiling SPIR-V back to HLSL.
Personally, I need it to convert DX12 shaders to DX11 ones using
SPIRV-Cross as a tool for converting SPIR-V, produced by DXC, to the old
shader model HLSL.
SPIR-V Tools now have a parameter in `RegisterPerformancePasses()` and
`RegisterLegalizationPasses()` for this. This PR creates a new command
line option in DXC and passes it to the `spvtools::Optimizer`.
Closes#4567
A common source of bugs. Although many of these were harmless, some were
not. By eliminating them and enabling this warning as an error, we won't
add more in the future.
Fixed a real SPIRV bug that required a test update to expect the correct behavior.
SPIRV testing was expecting incorrect results that came from a fallthrough error
Needed for the impending enabling on *nix platforms
* Remove circular dependency from RDAT Dumper
A file included by the source that implemented various ToString
converters of reflection data to strings itself depended on those
declarations, which it only found because of the unique way MSVC
processes templates. By moving the definitions and declarations into
their own header and source files, everyone gets what they need
without ouroborosing.
* Create DirectX-Headers submodule
Creates the DirectX-Headers submodule and adds the needed defines to
allow them to be used. As yet makes no use of these headers
* Improve src dir finding error
The check for the file stream that is meant to represent the filechecked
source file wasn't sufficient to detect a non-existent file. By expanding
the error check, it can produce a helpful message.
Also initialize the failure code so it isn't random
* Enable reflection functionality and testing
This flips the switch, removing or repositioning many ifdefs and
including previously excluded files in the build.
* Actually add the DirectX-Headers submodule
* fix *nix build breaks caused while fixing win breaks :P
* Respond to feedback -- some of it anyway ;)
* simplify cmake file to exclude unneeded src dir
* fix cmake (again)
* Fix GCC template specialization finickiness
What compiler is overly permissive now huh? huh? (or just quick to adopt
new language features?)
* LPCBYTE isn't a thing
Loathe as I am to push one more commit onto this. I don't want to
propagate a misconception. I meant to remove this earlier and caught it
from one final self-review >:(
Based on the Vulkan spec "15.1.5. Component Assignment":
"A Component decoration must not be specified for any type that is not a
scalar or vector."
we cannot decorate `Component` for array/matrix stage variables, which
is critical for the signature packing. We conduct the scalar replacement
for the stage variables to assign `Component` all stage variables, which
allows us to reduce the number of assigned `Location`s. This commit uses
the interface-variable-scalar-replacement spirv-opt pass for the SROA.
Note that the interface-variable-scalar-replacement spirv-opt pass is
experimental. We want to avoid the side effect caused by the pass as
much as possible. Therefore, we enable the pass only when the option for
the signature packing is enabled.
Based on Vulkan spec
> VUID-StandaloneSpirv-VulkanMemoryModel-04678
If the VulkanMemoryModel capability is not declared, the Volatile
decoration must be used on any variable declaration that includes
one of the SMIDNV, WarpIDNV, SubgroupSize, SubgroupLocalInvocationId,
SubgroupEqMask, SubgroupGeMask, SubgroupGtMask, SubgroupLeMask, or
SubgroupLtMask BuiltIn decorations when used in the ray generation,
closest hit, miss, intersection, or callable shaders, or with the
RayTmaxKHR Builtin decoration when used in an intersection shader
> VUID-StandaloneSpirv-VulkanMemoryModel-04679
If the VulkanMemoryModel capability is declared, the OpLoad
instruction must use the Volatile memory semantics when it accesses
into any variable that includes one of the SMIDNV, WarpIDNV,
SubgroupSize, SubgroupLocalInvocationId, SubgroupEqMask,
SubgroupGeMask, SubgroupGtMask, SubgroupLeMask, or SubgroupLtMask
BuiltIn decorations when used in the ray generation, closest hit,
miss, intersection, or callable shaders, or with the RayTmaxKHR
Builtin decoration when used in an intersection shader
We have to propagate the volatile semantics based on the spec. Since
adding Volatile decoration to interfaces is allowed in Vulkan 1.3 or
above, we simply add Volatile decoration for such interfaces. If it is
Vulkan 1.2 or earlier, we have to set the Volatile for OpLoad
instruction, which need the VulkanMemoryModel capability. In addition,
since Vulkan 1.1 or earlier does not have the VulkanMemoryModel
capability in the core spec, we use SPV_KHR_vulkan_memory_model.
Natalie Chouinard
Michael Anttila
Cassandra Beckley
Steven Perron
Nathan Gauër
Xiang Li
Antonio Maiorano
Diego Novillo
Kirill Kozlov
Greg Roth
Nathan Gauër
Cassandra Beckley
Jakub Kuderski
Daniele Vettorel
Jaebaek Seo
Natalie Chouinard