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.
In Vulkan1.3/SPIR-V1.6, we default OpDemoteToHelperInvocation
instruction for the discard statement. Unlike previous Vulkan versions,
we do not need to enable SPV_EXT_demote_to_helper_invocation extension.
This commit enables `-fspv-target-env=vulkan1.3` flag, but supporting
Vulkan1.3/SPIR-V1.6 is still WIP.
Without this change, setting the path of SPIRV-Tools with an arbitrary
path causes cmake error that the binary path of SPIRV-Tools is not
specified. This commit sets the binary path of SPIRV-Tools/Headers
even when they are out of DXC code base.
spirv-opt desc-sroa pass recently handles OpMemberDecorate by adding
OpDecorate instruction for the corresponding element of the resource
array. This commit uses it to preserve RelaxedPrecision decoration used
for resource variables in struct.
The existing DXC cannot a flatten descriptor array when an instruction
accesses it using a variable index, because spirv-opt
--descriptor-scalar-replacement pass did not support it. spirv-opt
recently added --replace-desc-array-access-using-var-index that replaces
accesses to descriptor arrays using variable indices with accesses to
constant elements using switch statements. This commit uses the newly
added pass to support flattening all descriptor arrays.
* Restore lit and googletest sources from LLVM 3.7.0
This commit just re-adds sources that were removed somewhere along the
way.
* Pull in googletest & googlemock from LLVM 4.0
Googlemock was introduced in LLVM 4.0, and is used by SPIR-V's tests.
This pulls in the LLVM 4.0 version of GoogleTest and GoogleMock to
replace the external submodules.
LLVM's version of GoolgeTest and GoogleMock have some minor extensions
to work better with LIT for error reporting and producing cleaner test
output.
* Remove external googletest
* Fix lit to handle comment in gtest names
This fix came into LLVM with the updated googletest in a977582dead2
* Ignore raw_fd_ostream errors when not closing
There's some odditites with the changes in the filesystem code that
cause this to error sometimes in unit tests. Until we can dedicate time
to looking into the filesystem code, just swallow that error...
* Fix bot failure
Missed an option change.
* Fixing MSVC build failure
* A cleaner build fix
This should address issues with VS 2019 in a cleaner way.
* Fix build
Since loading a big object takes the memory pressure, reduction of the
load size can have some performance benefit. In particular, it is
useful for mobile GPUs. `-fspv-reduce-load-size` removes
OpLoad/OpCompositeExtract of struct/array types by running spirv-opt
--reduce-load-size pass.
Fixes#3889
According to Vulkan specification when using `OpImageRead/OpImageWrite`, the `OpTypeImage` (`Buffers`, `RWBuffers`, `RWTextures`) must have a format that matches the format on the API side, unless the StorageImageReadWithoutFormat/StorageImageWriteWithoutFormat is added and `Unknown` is used as the format.
This pull request addressess #2498 for the format part by adding an attribute `[[vk::image_format("<image format as spelled in SPIR-V spec>")]].` Example of the syntax:
```
[[vk::image_format("rgba8")]]
RWBuffer<float4> Buf;
[[vk::image_format("rg16f")]]
RWTexture2D<float2> Tex;
RWTexture2D<float2> Tex2; // Works like before
```
The `image_format` only applies to **global variables** of type `Buffer`, `RWBuffer`, `RWTexture`. For variables and function parameters it is propagated by the inlining pass in legalization. This required a small change to one of the passes in SPIRV-Tools, that should be also checked by someone more familiar with the codebase: https://github.com/KhronosGroup/SPIRV-Tools/pull/4126
Note that this does not fix the handling of unspecified format (that case still works like before, using `R32f`, etc. based on the type in shader), although it should be still fixed to add the
StorageImageReadWithoutFormat and/or StorageImageWriteWithoutFormat and use Undefined. But I think the ability to specify the format is more urgent.
Design note from Jaebaek:
Since the `image_format` attribute only applies to **global variables**, under the DXC architecture
only `DeclResultIdMapper` can check the attribute when it handles `VarDecl`s. It means
we have to pass the `image_format` information to `LowerTypeVisitor` because it cannot access to
`VarDecl`. In order to pass the `image_format`, we use `SpirvContext` that can be accessed by
`SpirvEmitter` and all visitors. We use `SpirvVariable` to `spv::ImageFormat` mapping because the
attribute only applies to **global variables** (not to image types).
See how we use `llvm::DenseMap<const SpirvVariable *, spv::ImageFormat> spvVarToImageFormat`.
The current DXC emits `OpLine` for the first instruction in the location
and does not emit the same `OpLine` for the following instructions.
However, it does not specify the end of the effectiveness of the
`OpLine`, which is technically wrong based on the spec of OpLine and
OpNoLine. We have to specify the `OpLine` is not applied to the
following instructions when we meet an instruction without the location
information.
As SPIRV-Tools supports the debug info preservation for the full
optimization, we want to allow DXC users to use the full optimization
for the debug info generation.
This change updates SPIRV-Tools and SPIRV-Headers.
OpenCL.DebugInfo.100
is a SPIR-V extended instruction set that provides DWARF style debug information.
This PR allows DXC SPIR-V backend to generate the rich HLSL debug information
using OpenCL.DebugInfo.100 instructions.
* Update SPIRV-Tools and SPIRV-Headers
* SPIRV-Tools build has changed slightly
* SPIRV-Tools-static is now the target to use instead of plain
SPIRV-Tools
* Update SPIRV-Tools further
* Enable recompile of shaders with includes in dxc
When recompiling, the dxc executable stores all file blobs under names
that use backslashes. However, when recompiling, the filenames of the
includes in a shader are joined with the directory using a forward
slash. In addition, many authors use forward slashes to separate
subdirectories in these includes. Because of this, no includes could
ever match.
By converting all / in the path to \ just before trying to retrieve the
associated pseudo-file, the file is found. Recompilation is only
supported on Windows presently, so other OS path dividers needn't be
considered. The same native() call that generates the keys originally is
used to generate the keys to retrieve them.
Modify smoke.hlsl to verify that recompilation works
Natalie Chouinard
Jaebaek Seo
Natalie Chouinard
Chris B
JiaoluAMD
seppala2
Ehsan
alan-baker
Greg Roth
Minmin Gong