Subtract position from Vulkan inter stage limits

[teoxoy]

No description provided.

[github-actions]

Previews, as seen when this build job started (760a32a):
WebGPU _{webgpu.idl | Explainer | Correspondence Reference}
WGSL _{grammar.js | wgsl.lalr.txt}

[kainino0x]

Oops, good catch. LGTM, matches my summary of the investigation/proposal. (Suggested edits to point directly at it.)

[kainino0x]

Oh wait, I think this change doesn't align with my summary:

maxInterStageShaderVariables (straw-person name). Base value 16.

• Counting vertex outputs:

  • All locations must be less than the limit.
  • Add 1 for each used location.

• Counting fragment inputs:

  • All locations must be less than the limit.
  • Add 1 for each used location.
    (Note there's no location cost to using the position input³, front_facing, or sample_index1.)

• Limit derivation by backend (backend limit minus base cost):

  • Vulkan: Ranges from 16 to 32. Min of:

    • maxVertexOutputComponents / 4
      (no base cost)
    • maxFragmentInputComponents / 4
      (no base cost)

³ Only D3D12 counts the fragment input position toward its limit. Because the limit can't go higher than 31 anyway (D3D12_VS_OUTPUT_REGISTER_COUNT is fixed at 32, minus one for the vertex output position which is always present), we also subsume the fragment output position into the "base cost" for the limit, without detriment.

[kainino0x]

I think that summary is self-inconsistent. If both limits are based on Vulkan's maxVertexOutputComponents/maxFragmentInputComponents, then they both have to account for position (either in the WebGPU spec accounting, or statically by adjusting the limit derivation for Vulkan backends).

[kainino0x]

Oh, wait, I remember why the summary says that. It's because the Vulkan spec actually uses this limit for two arguably separate restrictions: max...Components components, and max...Components / 4 locations. This one paragraph in this spec section defines both:

The number of input and output Location slots available for a shader input or output interface is limited, and dependent on the shader stage as described in Shader Input and Output Locations.

This is an intro to both restrictions.

All variables in both the built-in interface block and the user-defined variable interface count against these limits.

This is about the number of components across user-defined AND built-in variables.

Each effective Location must have a value less than the number of Location slots available for the given interface, as specified in the “Locations Available” column in Shader Input and Output Locations.

I thought this restricted the number of user-defined variables. But it is actually about the indices of user-defined variables. With the accounting fix to count every variable as 4 components, this actually does not restrict the number of user-defined variables any further than the first restriction.

In any case, it is consistent with our maxInterStageShaderVariables which is also just a restriction on the indices of user-defined variables.

So I think this change isn't needed.

Suggested change

	<td>`min(maxVertexOutputComponents, maxFragmentInputComponents) // 4 - 1`
	<td>`min(maxVertexOutputComponents, maxFragmentInputComponents) // 4`

In the spec, I guess there should probably be an adapter capability guarantee something like
maxInterStageShaderVariables * 4 ≤ maxInterStageShaderComponents ≤ maxInterStageShaderVariables * 4 + 3
?

[teoxoy]

I see, but is it valuable to have it slightly higher?
Users will run into maxInterStageShaderComponents first anyway.

unsure