Issue 14639 in skia: UBO/SSBO layout compatible array types

[arman… via monorail]

Status: Accepted
Owner: arma...@google.com
Area: SkSL
Priority: Medium
Type: Defect

New issue 14639 by arma...@google.com: UBO/SSBO layout compatible array types
https://bugs.chromium.org/p/skia/issues/detail?id=14639

Array types currently do not compile cleanly in std430 layout. For
instance, consider the float[] type. If we apply std430 layout to SSBOs
and std140 layout to UBOs (as the latter is required), a different array
stride will be inferred for this type if it is declared inside a UBO
block and a SSBO block in the same program (16 in std140 and 4 in
std430).

This difference in layout is currently not handled well by SkSL,
especially when array types appear in user-defined function parameter
signatures. For example, consider this program:

layout(...) uniform UBO {
float uboArray[4];
};

layout(...) buffer SSBO {
float ssboArray[4];
};

void helper(float[4] arg) {...}

half4 main() {
...
helper(uboArray);
helper(ssboArray);
...
}

This is a valid SkSL program but it is unclear what code this should
generate in the WGSL and SPIR-V backends, both of which need to
determine:

1. What is the stride of `arg`?
2. What is the stride of `ssboArray`?
3. If `arg` and `ssboArray` have different strides what are the
argument passing semantics of `helper(ssboArray)`?
4. What is the stride of a temporary binding, e.g.

float[4] myArray = ssboArray;
myArray = uboArray;

The SPIR-V backend passes function arguments by pointer but the pointer
types of two different arrays with different strides are incompatible,
so a better way to pass an array as an argument is to copy its
elements into a temporary composite, which is not how SPIR-V codegen
works today.

WGSL requires that different array strides be declared via different
type signatures. `array<f32, N>` always has a stride of 4 and is
incompatible with UBO layout, which requires `float[N]` to be converted
to `array<vec4<f32>, N>` or `array<S, N>` where `S` is a struct with 16
byte alignment. What should the function parameter signature of `helper`
be in WGSL?

It makes sense for SPIR-V and WGSL codegen to have a consistent story
to determining stride if we want to support packed array layouts with
std430. Until then, use std140 layout with SSBOs.

--
You received this message because:
1. The project was configured to send all issue notifications to this address

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

[arman… via monorail]

Comment #1 on issue 14639 by arma...@google.com: UBO/SSBO layout compatible array types
https://bugs.chromium.org/p/skia/issues/detail?id=14639#c1

[arman… via monorail]

Updates:
Owner: johns...@google.com
Status: Untriaged

Comment #2 on issue 14639 by arma...@google.com: UBO/SSBO layout compatible array types
https://bugs.chromium.org/p/skia/issues/detail?id=14639#c2

(No comment was entered for this change.)

[arman… via monorail]

Updates:
Cc: arma...@google.com

Comment #3 on issue 14639 by arma...@google.com: UBO/SSBO layout compatible array types
https://bugs.chromium.org/p/skia/issues/detail?id=14639#c3