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
JiaoluAMD
Jaebaek Seo
seppala2
Ehsan
alan-baker
Greg Roth
Minmin Gong
Sahil Parmar
Ehsan