igl | Shader constants. Metal:MTLFunctionConstantValues. Vulkan:SpecializationInfo.

[vinsentli]

No description provided.

[corporateshark]

It should be std::vector indexed by constant_id.

[vinsentli]

done

[vinsentli]

Personally, I think using std::map might be better. Sometimes I only need to modify a subset of the constant values, which is achievable with std::map. If I used std::vector, I'd have to update all the constant values at once.

[corporateshark]

If I used std::vector, I'd have to update all the constant values at once.

What do you mean? You can still access each individual constant value by changing one vector element at functionConstantValues[constant_id]. The vector can have "holes" of course.

[vinsentli]

layout (constant_id = 0) const int value0 = 0;

layout (constant_id = 1) const int value1 = 1;

layout (constant_id = 2) const int value2 = 2;

If I want to modify value2, I can simply use functionConstantValues[2] = xxxwith std::map. However, if I do the same with std::vector, it would implicitly modify functionConstantValues[0]and functionConstantValues[1]as well. I can't just change value2because I don't know whether value0and value1should be updated or not.

[corporateshark]

It all can be much simpler than that. Please take a look here for a much cleaner implementation https://github.com/corporateshark/lightweightvk/blob/e910eba1bf198baad83094f7c439e53ba6dbafb4/lvk/LVK.h#L745

There's absolutely no need to wield an std::map to do it.

[vinsentli]

I've looked at SpecializationConstantDesc, and while it's very flexible and covers all scenarios, it can be somewhat complex to use. Our current discussion involves using a map, a vector, or SpecializationConstantDesc—these are different implementations with different interfaces. Perhaps we should design a clean interface that hides the implementation details. I find the Metal API design quite convenient. Could we design an interface like that?

enum DataType{
kDataTypeInt,
kDataTypeInt2,
kDataTypeInt3,
kDataTypeInt4,

kDataTypeFloat,
kDataTypeFloat2,
kDataTypeFloat3,
kDataTypeFloat4,

......
}

struct ShaderModuleInfo {
  ShaderStage stage = ShaderStage::Fragment;

  std::string entryPoint;

  void setFunctionConstantValue(int index, DataType type, void* value);

  std::string debugName;
}

I originally used std::map<uint8_t, int>because I only wanted to handle intvalues. Since intsatisfies our current use cases, I didn't want to deal with other data types. However, as a public API, handling all data types is an inevitable requirement.

[corporateshark]

How would be a hypothetical implementation of setFunctionConstantValue() look like in this case?

[vinsentli]

I've implemented a version, you can take a look.

[vinsentli]

https://docs.vulkan.org/spec/latest/chapters/pipelines.html#pipelines-specialization-constants

It is legal for a SPIR-V module with specializations to be compiled into a pipeline where no specialization information was provided. SPIR-V specialization constants contain default values such that if a specialization is not provided, the default value will be used. In the examples above, it would be valid for an application to only specialize some of the specialization constants within the SPIR-V module, and let the other constants use their default values encoded within the OpSpecConstant declarations.

According to the Vulkan spec, partial updates to constants are allowed. But testing on two mobile devices showed that all constants must be set. Am I interpreting this wrong?

[corporateshark]

According to the Vulkan spec, partial updates to constants are allowed. But testing on two mobile devices showed that all constants must be set. Am I interpreting this wrong?

If there are no other validation errors, you can report this to GPU vendors.

[meta-codesync]

@corporateshark has imported this pull request. If you are a Meta employee, you can view this in D103906352.

[meta-codesync]

@corporateshark merged this pull request in 7fb685a.