HLSL's StructuredBuffer to GLSL conversion issues about slang

[tangent-vector-personal]

For cross-compilation, the reflection data should be the same as for HLSL, so you don't have to care about what it would translate to in GLSL.

For the raw GLSL case, it is going to reflect as a buffer with an array in it, yeah. I would assume the user would bind things just as they would for an array in a cbuffer today.

[tangent-vector]

A bit of follow-up on this (mostly for my own benefit). Part of the question here is about a convention that Falcor can use to have hand-written GLSL that appear "the same" to its reflection system as a StructuredBuffer<T>. That is an interesting problem, but out of scope for Slang to solve. Slang's job would be to report the global-scope buffer block to you as accurately as possible (I'm not sure how I do on that right now...).

There actual Slang issue is what to do with a StructureBuffer<T> type when used in Slang code.
Given a global-scope declaration like you show:

struct Foo { float3 bar; };
StructuredBufer<Foo> gFoo;

There are two big issues:

1. What to do with the actual global-scope shader parameter declaration
2. What to do with uses of StructuredBuffer<Foo> at other locations (e.g., as a function parameter)

For (1) the ideal answer is a translation like Nir shows above (with a bit of name-change sleight-of-hand):

struct Foo { vec3 var; };
layout(..) buffer SLANG_buffer_gFoo {
    Foo gFoo[];
};

In this case, the name gFoo does not refer to the whole buffer, but to the array member inside it. Simple expressions like gFoo[i] in HLSL translate naturally over to GLSL.

The tricky bit, then, is that when the type StructuredBuffer<Foo> appears in any other context, we need to translate it as Foo[] - an unsized array of Foos. This should make it semantically okay to pass gFoo as a parameter to a function.

The big problem with that last bit is that the GLSL semantics for function calls are pass-by-value-result, which means we would technically copy the whole array, which might not even be legal. So thinking about it further, this would probably rely on an implementation that can specialize the callee function based on the known identity of resource parameters passed in. That is something we'll need to get to eventually on Slang, but isn't at the top of my to-do list any time soon.

[tangent-vector]

The IR-based code generator has an initial implementation of this conversion, so I think we can close this specific issue.

StructureBuffer variables declared as global shader parameters should work when cross-compiled to GLSL. We currently don't do a correct conversion when a StructuredBuffer<X> type is used for a function parameter (or a type passed as part of a function parameter), so that would still leave more work...