Fix wrong claims about Slang/scalar layout in Advanced Vulkan Compute tutorial - #495
Fix wrong claims about Slang/scalar layout in Advanced Vulkan Compute tutorial#495gpx1000 wants to merge 1 commit into
Conversation
juliusikkala
left a comment
juliusikkala
left a comment
There was a problem hiding this comment.
In general, this is now pretty good. There's just a couple of small things to fix, some of which were my own fault, mainly the OptionKind -> CompilerOptionName. I don't use the Slang API much myself so I double-checked and found that the public API uses a different enum than the compiler internals.
| // C/C++ layout: sizeof(Outer) == 12 -- that padding is never reused. | ||
| ---- | ||
|
|
||
| Slang has a distinct layout mode for this: `-fvk-use-c-layout` on the command line (`OptionKind::ForceCLayout` via the API, or the `CDataLayout` tag in-language) lays buffers out to match native C/C{pp} layout exactly, including for nested structures -- the only known caveat being empty structs, which are 0 bytes in Slang but 1 byte in C/C{pp}. GLSL has no equivalent option, so if you mix nested structures with scalar layout in GLSL, double-check their sizes on both sides of the CPU/GPU boundary rather than assuming they match. |
There was a problem hiding this comment.
Ah, I made a small mistake myself; it's CompilerOptionName::ForceCLayout in the public API instead of OptionKind.
| === Slang: Automatic Packing | ||
| === Slang: Opting Into Scalar Layout | ||
|
|
||
| It's worth being precise here, because it's a common misconception: Slang does not default to scalar layout, and this doesn't change based on which Vulkan version you're targeting -- Slang targets a SPIR-V version, not a Vulkan version, and none of the SPIR-V versions switch the default buffer layout to scalar. By default, a `StructuredBuffer<T>` or `RWStructuredBuffer<T>` in Slang is laid out with the same natural/std430-style alignment rules as HLSL, so an unadorned `float3` member is still padded exactly the way it would be under GLSL's `std430`. |
There was a problem hiding this comment.
I would take out the term "natural" from here, it has a Slang-specific (and frankly confusing) meaning that is not relevant for people who simply want to use Slang instead of working on the compiler itself.
| ---- | ||
|
|
||
| The `RWStructuredBuffer` in Slang maps to a `Storage Buffer` in Vulkan, and because Slang defaults to natural alignment, it produces the same result as the `scalar` layout in GLSL without the boilerplate. | ||
| Globally, the equivalent is the `-fvk-use-scalar-layout` flag for `slangc`, or `OptionKind::GLSLForceScalarLayout` when compiling through the Slang API. Either way, the `RWStructuredBuffer` maps to a Vulkan `Storage Buffer`, and once scalar layout is requested it packs identically to the `scalar`-qualified GLSL buffer below. |
There was a problem hiding this comment.
Same OptionKind -> CompilerOptionName here. Sorry about that.
| === GLSL: Requesting Scalar Layout | ||
|
|
||
| To truly appreciate the "win" in Vulkan 1.4, let's look at how this same structure would be handled in GLSL under the older `std430` rules vs. the modern `scalar` layout. | ||
| Scalar layout has to be requested explicitly in GLSL too -- it's exactly as manual as it is in Slang, just spelled differently. Let's look at how this same structure would be handled in GLSL under the older `std430` rules vs. the `scalar` layout enabled by Vulkan 1.4. |
There was a problem hiding this comment.
This "exactly as manual as it is in Slang" sounds a bit odd in this revision of the text, as the "The Manual Struggle" part has also been removed. I'd just say "Scalar layout has to be requested explicitly in GLSL too -- it's just spelled differently."
2 participants
Fixes #494 — Slang doesn't default to scalar layout and scalar layout doesn't always match C++ layout for nested structs; corrected both plus a couple of smaller wording issues from the issue.