darksylinc
commented
2 years ago Vertex Input
struct FVertexInput
{
float4 Position @attribute(0);
half3 TangentX @attribute(1);
half4 TangentZ @attribute(2);
int4 BlendIndices @attribute(3);
float4 BlendWeights @attribute(4);
float3 DeltaPosition @attribute(5);
half3 DeltaTangentZ @attribute(6);
};I don't have critique. Looks fine. I have only a couple comments:
APIs carry a legacy behavior where all types can be transformed to float. e.g. if I write float4 BlendWeights and I specify RGBA8_UNORM, RGBA8_SNORM, RGBA16_UNORM, RGBA16_SNORM they will all work and reinterpret the integers to either range [0; 1] or [-1; 1]
And if I write RGBA8_UINT, RGBA8_SINT then it will be converted to float in range [0; 255.0] or [-128; 127].
The same with RGBA16_FLOAT (aka half) -> float.
It is valid to e.g. specify RGBA8_UNORM but the shader only says float2 pos (i.e. only R & G channels get used).
But it is not valid to specify RG8_UNORM when the shader says float4 pos because there's nothing to source B & A from (there's an old legacy behavior for .w though; where for missing values it gets set to 1.0f).
However the same is not true for the other datatypes. For example if I write int4 BlendIndices, then the only valid formats are exclusively RGBA8_SINT, RGBA16_SINT and RGBA32_SINT.
As for what happens with half3 TangentX (which is like a float3, but it's not a float). It is a mystery. It's not defined, and different drivers behave differently. Mostly because 16-bit half isn't popular yet (but soon, probably).
VS -> PS Signature
struct FVertexOutput
{
float4 ScreenPosition;
float4 CameraVector_FogA;
float4 Position @position;
};This is the correct way. However I shall add a few notes:
- IIRC Vulkan requires the struct to match exactly.
- D3D11 / HLSL 5.0 (dunno about D3D12 / HLSL 5.1 / 6.x) allows for partial matching.
e.g. if the VS outputs this:
struct FVertexOutput
{
float4 Position @position; // Note I moved position first! This is important
float4 ScreenPosition;
float4 CameraVector_FogA;
};and PS inputs this:
struct FVertexOutput
{
float4 Position @position; // Note I moved position first! This is important
float4 ScreenPosition;
// Missing CameraVector_FogA
};Then the signature between VS and PS is still considered valid (i.e. as long as the same first N used bytes match exactly in name, type and size it's ok).
Syntax prefixes
// Heretical to C, functions start with the word "function" ...
// local variables are defined with a "var" keyword, which is also heretical
// to C users, but I couldn't help but notice WebGPU did this too, probably
// because parsing C is hard.Ahh, I understand making the parser easier.
But you may find adoption problems here. When porting existing engines to new APIs, these differences can be a mayor PITA.
Adding function may be an inconvenience. But adding var to every single variable can be a significant effort.
Some engines have significantly large Compute codebases.
Anecdotically Apple's Metal had something similar. Functions could either be:
void fooA(); // Must be forward declared first
void fooA() {}
inline void fooB() {} // If not forward declared, then it must be prepended with inlineAnd ended up bending the knee here allowing void fooB() {} without inline nor forward declarations in a subsequent Metal lang revision.
I don't know the reasons behind it though.
Buffer type declaration
function @vertex FVertexOutput VertexMain(FVertexInput Input @inputs, FVertexConstants Constants @buffer(0), BoneMatricesConstants BoneBuffer @buffer(1))@buffer is too broad here. Metal is a great example here. There's constant and device memory. The former are UBOs in Vulkan terms. The latter are either read-only SSBOs in Vk terms.
Vulkan also calls TBOs a "buffer" even though its type cannot be described with C-like code.
As a suggestion:
// Option A
function @vertex FVertexOutput VertexMain(
FVertexInput Input @inputs,
FVertexConstants Constants @buffer(0, constant),
BoneMatricesConstants BoneBuffer @buffer(1, device))
// Option B (basically Metal)
function @vertex FVertexOutput VertexMain(
FVertexInput Input @inputs,
constant FVertexConstants Constants @buffer(0),
device BoneMatricesConstants BoneBuffer @buffer(1))
// Option C
function @vertex FVertexOutput VertexMain(
FVertexInput Input @inputs,
FVertexConstants Constants @buffer_constant(0),
BoneMatricesConstants BoneBuffer @buffer_device(1))Note that buffer_constant slots should not overlap buffer_device.
Another issue to consider is that alignment constraints of FVertexConstants is not the same depending on whether it's a constant or a device function.
Consider this:
function @vertex FVertexOutput VertexMain(
FVertexInput Input @inputs,
FVertexConstants Constants @buffer(0, constant),
BoneMatricesConstants BoneBuffer @buffer(1, device))
{
doSomething( Constants, BoneBuffer );
}
void doSomething( FVertexConstants Constants, BoneMatricesConstants BoneBuffer )
{
// Ooops!!! Is FVertexConstants a constant or device???
// This is important. Without it we cannot compile doSomething
// because we don't know the alignment rules inside Constants & BoneBuffer
}
// Metal solves it like this:
void doSomething( constant FVertexConstants Constants, device BoneMatricesConstants BoneBuffer )
{
// Now we know their alignments. FVertexConstants must come from a constant buffer
// and BoneBuffer from a device buffer
}
michael-nischt
matias-eduardo
darkerbit
harryisgamer
icculus
kg
bruxisma
Hugobros3
bartwe
gingerBill
vanka78bg
Arcnor
Andre-LA
rudolfwalter
hw-claudio
I NEED FEEDBACK. IF YOU LOVE OR HATE THIS, PLEASE SPEAK LOUDLY.
IF THIS WILL ABSOLUTELY CAUSE PAIN AND MISERY, SPEAK TWICE AS LOUDLY.
THANK YOU.
Here's a first example of where I'm heading towards. The syntax and the heavy commenting explaining the syntax are what's important; the code itself is not and just meant to be an example.