https://github.com/shader-slang/slang
Revision 0ab4d044896ad3d8c5c9cedbb7bd7ec94be81d69 authored by Tim Foley on 29 January 2021, 21:17:51 UTC, committed by GitHub on 29 January 2021, 21:17:51 UTC
The problem would manifest for any code that declared a DXR 1.1 `RayQuery` value, but then only used it as one location in their code. The most common way for this to arise in user code was declaring a `RayQuery` and then handing it off to a helper/worker subroutine. RayQuery<0> myRayQuery; helperRoutine(myRayQuery, ...); The root cause was in the emit logic, where the initialization of `myRayQuery` above (a `defaultConstruct` operation in our IR) was getting folded into its (only) use site. This folding makes some sense, because the initialization of a ray query is not an operation with side effects, but doesn't work in practice because our way of handling default construction in HLSL output is by using a variable declaration. The simple fix here is to ensure that `defaultConstruct` instructions never get folded into use sites. If we decide to revisit the logic here, it might be possible to separate out the case where a `defaultConstruct` is being used as a stand-alone instruction, where we can emit it as: RayQuery<0> myRayQuery; versus cases where the `defaultConstruct` is being used as a sub-expression, such as: helperRoutine(RayQuery<0>(), ...); Whether or not we can emit the latter form (or if it would be equivalent) depends on details of how constructors like this are being implemented in dxc. For now it seems safest to emit things in a form that is obviously expected to work. Aside: Historically, the HLSL language has had no notion of "constructors" as being a thing. A variable that is declared but not initialized in HLSL has always been left uninitialized, since the first version of the language. The `RayQuery` type in DXR 1.1 is the first example of a type that appears to have a C++-style "default constructor," although HLSL as implemented by dxc still does not expose constructors as a user-visible or documented feature. (There is the small detail that the DXR 1.0 `HitGroup` type also relied on C++ constructor syntax, but I'm not aware of anybody using that feature right now, so it is mostly a curiosity.)
1 parent da6463a
Tip revision: 0ab4d044896ad3d8c5c9cedbb7bd7ec94be81d69 authored by Tim Foley on 29 January 2021, 21:17:51 UTC
Fix issue when passing ray query to a subroutine (#1680)
Fix issue when passing ray query to a subroutine (#1680)
Tip revision: 0ab4d04
.gitmodules
[submodule "external/glslang"]
path = external/glslang
url = https://github.com/shader-slang/glslang.git
[submodule "external/tinyobjloader"]
path = external/tinyobjloader
url = https://github.com/syoyo/tinyobjloader
[submodule "external/glm"]
path = external/glm
url = https://github.com/g-truc/glm.git
[submodule "external/imgui"]
path = external/imgui
url = https://github.com/ocornut/imgui.git
[submodule "external/slang-binaries"]
path = external/slang-binaries
url = https://github.com/shader-slang/slang-binaries
[submodule "external/spirv-tools"]
path = external/spirv-tools
url = https://github.com/KhronosGroup/SPIRV-Tools.git
[submodule "external/spirv-headers"]
path = external/spirv-headers
url = https://github.com/KhronosGroup/SPIRV-Headers.git
[submodule "external/miniz"]
path = external/miniz
url = https://github.com/richgel999/miniz
[submodule "external/lz4"]
path = external/lz4
url = https://github.com/lz4/lz4
![swh spinner](/static/img/swh-spinner.gif)
Computing file changes ...