Update limits correspondence - #5604
Conversation
|
Previews, as seen when this build job started (a000b50): |
| - `Maximum scalar or vector inputs to a fragment function` | ||
| - `(Maximum number of input components to a fragment function) / 4` | ||
| <td>31 = `min(D3D12_VS_OUTPUT_REGISTER_COUNT, D3D12_PS_INPUT_REGISTER_COUNT) - 1` |
There was a problem hiding this comment.
Only the position builtin doesn't count towards the maxInterStageShaderVariables in the WebGPU spec. The Vulkan and D3D12 limits need to be lowered by 1. On Metal the limit is only for user defined inter-stage variables.
There was a problem hiding this comment.
D3D12 change looks right, I guess we missed updating this when we changed these builtins to be counted (when merging the two limits together in #4688).
On Metal, we had this carveout because there was a specific difference in the Metal validation layers between Apple and non-Apple GPUs. See #1962 (comment) - the validation layer used to erroneously say "on macOS" but it meant "on non-Apple GPUs" - I don't know if that's been fixed since.
When I wrote this I should have made clearer what the subtractions were for, but I think they're position and point_size and should be left as they were - IIUC even though point_size is accounted for by our spec in vertex outputs, we have to reserve it on Metal because Metal counts it toward fragment inputs too?
There was a problem hiding this comment.
On Metal, we had this carveout because there was a specific difference in the Metal validation layers between Apple and non-Apple GPUs. See #1962 (comment) - the validation layer used to erroneously say "on macOS" but it meant "on non-Apple GPUs" - I don't know if that's been fixed since.
I see; our CI also started running into this now:
number of shader varying components (125) exceeds limit (124). Note that on macOS the following attributes count towards the limit: [[position]], [[clip_distance]], [[point_size]], [[point_coord]], and, when read in the fragment shader, [[viewport_array_index]] & [[render_target_array_index]].
from https://bugzilla.mozilla.org/show_bug.cgi?id=1931629#c9
There was a problem hiding this comment.
Dawn seems to set maxInterStageShaderVariables to 28 on non-Apple GPUs.
limits->v1.maxInterStageShaderVariables = mtlLimits.maxFragmentInputs - 4;
I will test in our CI with 30 min(32, 124 / 4) - 1 for now (accounting just for position).
| <th>`maxBindingsPerBindGroup` | ||
| <td>[#3279](https://github.com/gpuweb/gpuweb/issues/3279), | ||
| [#3864](https://github.com/gpuweb/gpuweb/issues/3864) | ||
| <td colspan=3>Limit is arbitrary to allow implementations to treat binding space as an array. |
There was a problem hiding this comment.
This was also referring to WebGPU implementations (not just drivers) so should be written in the table in a way that it applies to all backends.
There was a problem hiding this comment.
I updated the section; let me know what you think!
| - `Maximum scalar or vector inputs to a fragment function` | ||
| - `(Maximum number of input components to a fragment function) / 4` | ||
| <td>31 = `min(D3D12_VS_OUTPUT_REGISTER_COUNT, D3D12_PS_INPUT_REGISTER_COUNT) - 1` |
There was a problem hiding this comment.
D3D12 change looks right, I guess we missed updating this when we changed these builtins to be counted (when merging the two limits together in #4688).
On Metal, we had this carveout because there was a specific difference in the Metal validation layers between Apple and non-Apple GPUs. See #1962 (comment) - the validation layer used to erroneously say "on macOS" but it meant "on non-Apple GPUs" - I don't know if that's been fixed since.
When I wrote this I should have made clearer what the subtractions were for, but I think they're position and point_size and should be left as they were - IIUC even though point_size is accounted for by our spec in vertex outputs, we have to reserve it on Metal because Metal counts it toward fragment inputs too?
No description provided.