summaryrefslogtreecommitdiff
path: root/source/slang/slang-type-layout.h
diff options
context:
space:
mode:
authorTim Foley <tfoleyNV@users.noreply.github.com>2019-08-08 11:22:32 -0700
committerGitHub <noreply@github.com>2019-08-08 11:22:32 -0700
commit2552217b76c0bd83e18fceba1d35a367bf569eca (patch)
tree0651175e4601af75bc18687c853068f013e6c1b9 /source/slang/slang-type-layout.h
parent81ce78d08a7e3fbe74f2fd41c5a258ea4b078245 (diff)
Revise new COM-lite API (#1007)
* Revise new COM-lite API This change revises the "COM-lite" API that was recently introduced to try to streamline it and introduce some missing central/base concepts. The central new abstraction in the API is the notion of a "component type," which is a unit of shader code composition. A component type can have: * IR code for some number of functions/types/etc. * Zero or more global shader parameters * Zero or more "entry point" functions at which execution can start * Zero or more "specialization" parameters (types or values that must be filled in before kernel code can be generated) * Zero or more "requirements" (dependencies on other component types that must be satisfied before kernel code can be generated) Both individual compiled modules, and validated entry points are then examples of component types, and we additionally define a few services that apply to all component types: * We can take N component types and compose them to create a new component type that combines their code, shader parameters, entry points, and specialization parameters. A composed component type may also include requirements from the sub-component types, but it is also possible that by composing thing we satisfy requirements (if `A` requires `B`, and we compose `A` and `B`, then the requirement is now satisfied, and doesn't appear on the composite). * We can take a component type with N specialization parameters, and specialize it by giving N compatible specialization arguments. The result of specialization is a new component type with zero specialization parameters. Under the right circumstances the specialzed component type will be layout compatible with the unspecialized one. * One more example that isn't exposed in the public API today is that we can take a component with requirements and "complete" it by automatically composing it with component types that satisfy those requirements. This can be seen as a kind of linking step that pulls together the transitive closure of dependencies. * We can query the layout for the shader parameters and entry points of a component type, for a specific target. * We can query compiled kernel code for an entry point in a component type (for a specific target). This only works for component types with zero specialization parameters and zero requirements. The idea is that by giving users a fairly general algebra of operations on component types, they can compose final programs in ways that meet their requirements. For example, it becomes possible to incrementally "grow" a component type to represent the global root signature for ray tracing shaders as new entry points are added, in such a way that it always stays layout-compatible with kernels that have already been compiled. Much of the implementation work here is in implementing the unifying component type abstraction, and in particular re-writing code that used to assume a program consisted of a flat list of modules and entry points to work with a hierarchical representation that reflects the underlying algebra (e.g., with types to represent composite and specialized component types). There's also a hidden "legacy" case of a component type to deal with some legacy compiler behaviors that can't be directly modeled on top of the simple algebra with modules and entry points. This API is by no means feature-complete or fully developed. It is expected that we will flesh it out more when bringing up application code (e.g., Falcor) on top of the revamped API. One notable thing that went away in this change is explicit support for "entry point groups" and notions of local root signatures (especially the Falcor-specific handling of the `shared` keyword, which a previous change turned into an explicitly supported feature). With the new "building blocks" approach, it should be possible for a DXR application to deal with local root signatures as a matter of policy (on top of the API we provide). If/when we need to provide some kind of emulation of local root signatures for Vulkan (and/or if Vulkan is extended with an explicit notion of local root signatures), we might need to revisit this choice. * Fix debug build There was invalid code inside an `assert()`, so the release build didn't catch it. * fixup: warnings * fixup: more warnings-as-errors * fixup: review notes * fixup: use component type visitors in place of dynamic casting
Diffstat (limited to 'source/slang/slang-type-layout.h')
-rw-r--r--source/slang/slang-type-layout.h108
1 files changed, 67 insertions, 41 deletions
diff --git a/source/slang/slang-type-layout.h b/source/slang/slang-type-layout.h
index e066c2700..b7b3c3207 100644
--- a/source/slang/slang-type-layout.h
+++ b/source/slang/slang-type-layout.h
@@ -622,7 +622,7 @@ class GenericParamTypeLayout : public TypeLayout
{
public:
RefPtr<GlobalGenericParamDecl> getGlobalGenericParamDecl();
- int paramIndex = 0;
+ Index paramIndex = 0;
};
/// Layout information for a tagged union type.
@@ -667,8 +667,6 @@ public:
StructTypeLayout* getScopeStructLayout(
ScopeLayout* programLayout);
-class EntryPointGroupLayout;
-
// Layout information for a single shader entry point
// within a program
//
@@ -682,7 +680,10 @@ class EntryPointLayout : public ScopeLayout
{
public:
// The corresponding function declaration
- RefPtr<FuncDecl> entryPoint;
+ DeclRef<FuncDecl> entryPoint;
+
+ DeclRef<FuncDecl> getFuncDeclRef() { return entryPoint; }
+ FuncDecl* getFuncDecl() { return entryPoint.getDecl(); }
// The shader profile that was used to compile the entry point
Profile profile;
@@ -696,30 +697,38 @@ public:
};
unsigned flags = 0;
- /// Layouts for all tagged union types required by this entry point.
- ///
- /// These are any tagged union types used by the generic
- /// arguments that this entry point is being compiled with.
- List<RefPtr<TypeLayout>> taggedUnionTypeLayouts;
-
EntryPointLayout* getAbsoluteLayout(VarLayout* parentLayout);
- EntryPointLayout* getAbsoluteLayout(EntryPointGroupLayout* parentGroup);
RefPtr<EntryPointLayout> m_absoluteLayout;
};
-class EntryPointGroupLayout : public ScopeLayout
+ /// Reflection/layout information about a specialization parameter
+class SpecializationParamLayout : public Layout
{
public:
- RefPtr<EntryPointGroup> group;
- List<RefPtr<EntryPointLayout>> entryPoints;
+ Index index;
};
-class GenericParamLayout : public Layout
+ /// Reflection/layout information about a generic specialization parameter
+class GenericSpecializationParamLayout : public SpecializationParamLayout
{
public:
- RefPtr<GlobalGenericParamDecl> decl;
- int index;
+ /// The declaration of the generic parameter.
+ ///
+ /// Could be any subclass of `Decl` that represents a generic value or type parameter.
+ RefPtr<Decl> decl;
+};
+
+ /// Reflection/layout information about an existential/interface specialization parameter.
+class ExistentialSpecializationParamLayout : public SpecializationParamLayout
+{
+public:
+ /// The type that needs to be specialized.
+ ///
+ /// Currently, this will be an `interface` type that any concrete
+ /// type argument getting plugged in must conform to.
+ ///
+ RefPtr<Type> type;
};
// Layout information for the global scope of a program
@@ -748,7 +757,7 @@ public:
TargetProgram* getTargetProgram() { return targetProgram; }
TargetRequest* getTargetReq() { return targetProgram->getTargetReq(); }
- Program* getProgram() { return targetProgram->getProgram(); }
+ ComponentType* getProgram() { return targetProgram->getProgram(); }
// We catalog the requested entry points here,
@@ -756,12 +765,21 @@ public:
// will (eventually) belong there...
List<RefPtr<EntryPointLayout>> entryPoints;
- // Entry points can also be grouped for layout purposes (e.g., to form
- // ray-tracing hit groups), so this array represents those groups
- List<RefPtr<EntryPointGroupLayout>> entryPointGroups;
+ /// Reflection information on (unspecialized) specialization parameters.
+ List<RefPtr<SpecializationParamLayout>> specializationParams;
- List<RefPtr<GenericParamLayout>> globalGenericParams;
- Dictionary<String, GenericParamLayout*> globalGenericParamsMap;
+ /// Concrete argument values that were provided to specific global generic parameters.
+ ///
+ /// Not useful for reflection, but valuable for code generation.
+ ///
+ Dictionary<GlobalGenericParamDecl*, RefPtr<Val>> globalGenericArgs;
+
+ /// Layouts for all tagged union types required by this program
+ ///
+ /// These are any tagged union types used by the specialization
+ /// arguments that have been used to specialize the program.
+ ///
+ List<RefPtr<TypeLayout>> taggedUnionTypeLayouts;
};
StructTypeLayout* getGlobalStructLayout(
@@ -908,8 +926,6 @@ struct LayoutRulesFamilyImpl
virtual LayoutRulesImpl* getShaderRecordConstantBufferRules() = 0;
};
-typedef List<RefPtr<GenericParamLayout>> GenericParamLayouts;
-
struct TypeLayoutContext
{
// The layout rules to use (e.g., we compute
@@ -930,10 +946,10 @@ struct TypeLayoutContext
MatrixLayoutMode matrixLayoutMode;
// The concrete types (if any) to plug into the currently in-scope
- // existential type slots.
+ // specialization params.
//
- Int existentialTypeArgCount = 0;
- ExistentialTypeSlots::Arg const* existentialTypeArgs = nullptr;
+ Int specializationArgCount = 0;
+ ExpandedSpecializationArg const* specializationArgs = nullptr;
LayoutRulesImpl* getRules() { return rules; }
LayoutRulesFamilyImpl* getRulesFamily() const { return rules->getLayoutRulesFamily(); }
@@ -952,29 +968,29 @@ struct TypeLayoutContext
return result;
}
- TypeLayoutContext withExistentialTypeArgs(
- Int argCount,
- ExistentialTypeSlots::Arg const* args) const
+ TypeLayoutContext withSpecializationArgs(
+ ExpandedSpecializationArg const* args,
+ Int argCount) const
{
TypeLayoutContext result = *this;
- result.existentialTypeArgCount = argCount;
- result.existentialTypeArgs = args;
+ result.specializationArgCount = argCount;
+ result.specializationArgs = args;
return result;
}
- TypeLayoutContext withExistentialTypeSlotsOffsetBy(
+ TypeLayoutContext withSpecializationArgsOffsetBy(
Int offset) const
{
TypeLayoutContext result = *this;
- if( existentialTypeArgCount > offset )
+ if( specializationArgCount > offset )
{
- result.existentialTypeArgCount = existentialTypeArgCount - offset;
- result.existentialTypeArgs = existentialTypeArgs + offset;
+ result.specializationArgCount = specializationArgCount - offset;
+ result.specializationArgs = specializationArgs + offset;
}
else
{
- result.existentialTypeArgCount = 0;
- result.existentialTypeArgs = nullptr;
+ result.specializationArgCount = 0;
+ result.specializationArgs = nullptr;
}
return result;
@@ -1061,6 +1077,8 @@ public:
///
TypeLayoutResult getTypeLayoutResult();
+ UniformLayoutInfo* getStructLayoutInfo() { return &m_info; }
+
private:
/// The layout rules being used, if layout has begun.
LayoutRulesImpl* m_rules = nullptr;
@@ -1139,8 +1157,16 @@ createStructuredBufferTypeLayout(
RefPtr<Type> structuredBufferType,
RefPtr<Type> elementType);
-int findGenericParam(List<RefPtr<GenericParamLayout>> & genericParameters, GlobalGenericParamDecl * decl);
-//
+ /// Create a type layout for an unspecialized `globalGenericParamDecl`.
+RefPtr<TypeLayout> createTypeLayoutForGlobalGenericTypeParam(
+ TypeLayoutContext const& context,
+ Type* type,
+ GlobalGenericParamDecl* globalGenericParamDecl);
+
+ /// Find the concrete type (if any) that was plugged in for the global generic type parameter `decl`.
+RefPtr<Type> findGlobalGenericSpecializationArg(
+ TypeLayoutContext const& context,
+ GlobalGenericParamDecl* decl);
// Given an existing type layout `oldTypeLayout`, apply offsets
// to any contained fields based on the resource infos in `offsetVarLayout`.