diff options
| author | Tim Foley <tfoleyNV@users.noreply.github.com> | 2019-03-01 08:20:09 -0800 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2019-03-01 08:20:09 -0800 |
| commit | efca2bb38700847adb2385d311b8b801376659bb (patch) | |
| tree | 79d83f46d5d2719892bbfd78d8b33f0c201f0633 /source/slang/type-layout.cpp | |
| parent | 852c88cc9d7e720af66275bf7fdf58341f5f6e7c (diff) | |
A small refactor to how implicit constant buffers are getting created. (#871)
This affects layout computation for both the global and entry-point scopes, where multiple discrete shader parameters can be declared, but for layout purposes they must be treated as if they lived in the same `struct` type. If that `struct` type ends up consuming any "ordinary" data (`LayoutResourceKind::Uniform`) then an implicit constant buffer will be needed for that scope (e.g., the way fxc produces a `$Globals` constant buffer for the global scope).
The logic for computing those scope layouts had a bug in it, in that the struct type was not being updated to have the right size for uniform data at the scope. That bug hasn't bitten anybody yet because no Slang users are relying on entry-point uniforms, and global-scope uniforms aren't fully implemented (and get diagnosed as an error elsewhere in the compiler). This change fixes that bug.
This change also refactors things so that the logic for creating a constant buffer layout if and only if needed is moved into `type-layout.cpp` instead of relying on `parameter-binding.cpp` to compute whether or not it needs a block on its own. This is anticipating the rules for deciding whether or not a constant buffer is needed being slightly more thorny once interface types are in the mix.
Diffstat (limited to 'source/slang/type-layout.cpp')
| -rw-r--r-- | source/slang/type-layout.cpp | 35 |
1 files changed, 28 insertions, 7 deletions
diff --git a/source/slang/type-layout.cpp b/source/slang/type-layout.cpp index eefcfe1fd..ea5287999 100644 --- a/source/slang/type-layout.cpp +++ b/source/slang/type-layout.cpp @@ -1378,20 +1378,41 @@ static RefPtr<ParameterGroupTypeLayout> _createParameterGroupTypeLayout( return typeLayout; } -RefPtr<ParameterGroupTypeLayout> createParameterGroupTypeLayout( + /// Doe we need to wrap the given element type in a constant buffer layout? +static bool needsConstantBuffer(RefPtr<TypeLayout> elementTypeLayout) +{ + auto uniformResInfo = elementTypeLayout->FindResourceInfo(LayoutResourceKind::Uniform); + if(uniformResInfo && uniformResInfo->count != 0) + return true; + + // Note: additional cases are expected here, to deal with existential types. + + return false; +} + +RefPtr<TypeLayout> createConstantBufferTypeLayoutIfNeeded( TypeLayoutContext const& context, - RefPtr<ParameterGroupType> parameterGroupType, - LayoutRulesImpl* parameterGroupRules, - SimpleLayoutInfo parameterGroupInfo, RefPtr<TypeLayout> elementTypeLayout) { + // First things first, we need to check whether the element type + // we are trying to lay out even needs a constant buffer allocated + // for it. + // + if(!needsConstantBuffer(elementTypeLayout)) + return elementTypeLayout; + + auto parameterGroupRules = context.getRulesFamily()->getConstantBufferRules(); + return _createParameterGroupTypeLayout( - context.with(parameterGroupRules).with(context.targetReq->getDefaultMatrixLayoutMode()), - parameterGroupType, - parameterGroupInfo, + context + .with(parameterGroupRules) + .with(context.targetReq->getDefaultMatrixLayoutMode()), + nullptr, + parameterGroupRules->GetObjectLayout(ShaderParameterKind::ConstantBuffer), elementTypeLayout); } + static RefPtr<ParameterGroupTypeLayout> _createParameterGroupTypeLayout( TypeLayoutContext const& context, RefPtr<ParameterGroupType> parameterGroupType, |
