Raised during the 2021-06-22 WGSL meeting
Can the following happen:
- shader modules created successfully
- pipeline creation parameters pass validation
- but pipeline creation fails in the underlying (platform) driver anyway.
Context: checking workgroup memory exhaustion.
The context where this was raised is where pipeline-overridable constants are used to size variables in workgroup storage, and that somehow exhausts the workgroup storage.
In this particular case, the browser might check for exhaustion in advance because, for example:
Metal limits for threadgroup memory
Metal feature set tables list "maximum total threadgroup memory allocation" in feature set tables
Note there is also a "threadgroup memory length alignment" of 16B, which sounds like an alignment reuqirement on each threadgroup variable.
Vulkan limits for workgroup memory
Vulkan can report a device limit maxComputeSharedMemorySize in VkPhysicalDeviceLimits.
Ignoring extensions, the size (and layout) of values in workgroup memory is implementation-defined, but the total size can be bounded: From the description of maxComputeSharedMemorySize:
The amount of storage consumed by the non-Block variables declared with the Workgroup storage class is implementation-dependent. However, the amount of storage consumed may not exceed the largest block size that would be obtained if all active non-Block variables declared with Workgroup storage class were assigned offsets in an arbitrary order by successively taking the smallest valid offset according to the Standard Storage Buffer Layout rules. (This is equivalent to using the GLSL std430 layout rules.)
Other cases
The other case I mentioned is: if the shader is too complex, then compilation could fail.
Some people really do push boundaries in unusual ways, e.g. with machine-generated code. SPIR-V has a set of limits to draw the line somewhere. https://www.khronos.org/registry/spir-v/specs/unified1/SPIRV.html#Limits
These limits protects some limit in an implementation detail of underlying driver compilers.
Raised during the 2021-06-22 WGSL meeting
Can the following happen:
Context: checking workgroup memory exhaustion.
The context where this was raised is where pipeline-overridable constants are used to size variables in workgroup storage, and that somehow exhausts the workgroup storage.
In this particular case, the browser might check for exhaustion in advance because, for example:
Metal limits for threadgroup memory
Metal feature set tables list "maximum total threadgroup memory allocation" in feature set tables
Note there is also a "threadgroup memory length alignment" of 16B, which sounds like an alignment reuqirement on each threadgroup variable.
Vulkan limits for workgroup memory
Vulkan can report a device limit maxComputeSharedMemorySize in VkPhysicalDeviceLimits.
Ignoring extensions, the size (and layout) of values in workgroup memory is implementation-defined, but the total size can be bounded: From the description of maxComputeSharedMemorySize:
Other cases
The other case I mentioned is: if the shader is too complex, then compilation could fail.
Some people really do push boundaries in unusual ways, e.g. with machine-generated code. SPIR-V has a set of limits to draw the line somewhere. https://www.khronos.org/registry/spir-v/specs/unified1/SPIRV.html#Limits
These limits protects some limit in an implementation detail of underlying driver compilers.