summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorTim Foley <tfoleyNV@users.noreply.github.com>2020-09-17 09:54:49 -0700
committerGitHub <noreply@github.com>2020-09-17 09:54:49 -0700
commit0124bf25c53ba76bf0d0e624d9a0d1b2b03760a6 (patch)
tree74a13305d3eff3508458b002e90f79a5f24e750b
parent3e2cb34bf112722368c296130b1424de267d2b3c (diff)
Fix an issue with double-counting uniform data for CUDA/CPU (#1545)
The `SimpleScopeLayoutBuilder` helper that is used to build up binding information for entry-point parameter lists has logic to try to support both explicit and implicit binding of parameters. This logic was added as part of supporting dual-source color blending on Vulkan. The basic approach is similar to that used for the global scope, where parameters with explicit binding first "carve out" the ranges they claim via a `UsedRangeSet`, and then parameters without explicit binding allocate space from what is left. The logic is (seemingly by accident) also applied to uniform/ordinary data, which creates a problem because the `ScopeLayoutBuilder` base type is also responsible for computing a layout for uniform/ordinary data that is 100% implicit (while dealing with all the relevant alignment restrictions). That logic goes on to add the computed uniform/ordinary resource usage to the computed type layout, but because such a layout has already been computed (albeit without taking alignment into account), the result is that the uniform/ordinary usage is reported at approximately double what it should be. The fix here is to skip uniform/ordinary resource usage when doing the explicit/implicit dance in `SimpleScopeLayoutBuilder`. This approach means that explicit bindings on entry-point `uniform` parameters will only apply to resources (which matches our rules for the global scope, where we don't allow for explicit binding on uniform/ordinary parameters). This is appropriate since the only reason we are supported explicit layout at all is for dual-source color blending (in general, we only support explicit `register` and `[[vk::binding(...)]]` modifiers on global parameters; users are stuck with our computed layouts in all other cases. Co-authored-by: Yong He <yonghe@outlook.com>
-rw-r--r--source/slang/slang-parameter-binding.cpp3
1 files changed, 3 insertions, 0 deletions
diff --git a/source/slang/slang-parameter-binding.cpp b/source/slang/slang-parameter-binding.cpp
index 7676c89b0..90b5d9824 100644
--- a/source/slang/slang-parameter-binding.cpp
+++ b/source/slang/slang-parameter-binding.cpp
@@ -2315,6 +2315,7 @@ struct SimpleScopeLayoutBuilder : ScopeLayoutBuilder
for (auto paramTypeResInfo : paramTypeLayout->resourceInfos)
{
auto kind = paramTypeResInfo.kind;
+ if (kind == LayoutResourceKind::Uniform) continue;
// We will look for an explicit/existing binding in
// the parameter var layout, which would represent
@@ -2344,6 +2345,7 @@ struct SimpleScopeLayoutBuilder : ScopeLayoutBuilder
for (auto paramTypeResInfo : paramTypeLayout->resourceInfos)
{
auto kind = paramTypeResInfo.kind;
+ if (kind == LayoutResourceKind::Uniform) continue;
// We only care about parameters that are not already
// explicitly bound, so we will skip those that already
@@ -2368,6 +2370,7 @@ struct SimpleScopeLayoutBuilder : ScopeLayoutBuilder
for (auto paramTypeResInfo : paramTypeLayout->resourceInfos)
{
auto kind = paramTypeResInfo.kind;
+ if (kind == LayoutResourceKind::Uniform) continue;
auto paramResInfo = paramVarLayout->FindResourceInfo(kind);
SLANG_ASSERT(paramResInfo);