Making it easier to work with shaders https://git.yummers.dev/slang.git/atom?h=master 2024-10-29T06:49:26+00:00 2024-10-29T06:49:26+00:00 Ellie Hermaszewska ellieh@nvidia.com 2024-10-29T06:49:26+00:00 urn:sha1:f65d756bff8d4c5cbc15bd0322a2ae8e6b896a21 * format * Minor test fixes * enable checking cpp format in ci 2020-01-28T20:35:13+00:00 Tim Foley tfoleyNV@users.noreply.github.com 2020-01-28T20:35:13+00:00 urn:sha1:8b3e3beea66d9773adf11ea2e163577d649f3d7c When using row-major layout (via command-line or API option), the following sort of declaration: ```hlsl StructuredBuffer<float4x4> gBuffer; ... gBuffer[i] ... ``` Generates unexpected results when compiled to DXBC via fxc or DXIL via dxc, because the fxc/dxc compilers do not respect the matrix layout mode in this specific case (a structured buffer of matrices). Instead, they always use column-major layout, even if row-major was requested by the user. A user can work around this behavior by wrapping the matrix in a `struct`: ```hlsl struct Wrapper { float4x4 wrapped; } SturcturedBuffer<Wrapper> gBuffer; ... gBuffer[i].wrapped ... ``` This change simply automates that workaround when compiling for an HLSL-based downstream compiler, so that we get the same behavior across all our backends. The change adds a test case to confirm the behavior across multiple targets, but it turns out we also had a test checked in that confirmed the buggy (or at least surprising) fxc/dxc behavior, so that one had its baselines changed and can work as a regression test for this fix as well.