How to translate GLSL buffer_reference with header, unsized array member and specified alignment to slang? #5705
-
I'm currently looking into switching an existing project from GLSL to slang. In it we have code that looks like the following:
From the documentation I know that with slang I can use a struct plus pointers. However, it appears that in all of the examples the pointers point to the start of an array with elements of fixed size. Can slang do things like the example above, i.e. trailling unsized arrays? Or do I have to do some pointer magic, e.g. make the unsized a single element and take the adress of it via the ampersand operator or adding an offset to the orignal pointer? Also, how would I specify the alignment or does slang only support the default 16 byte alignment? I hope this is the right place to ask these kind of questions and sorry if parts of it are actually related to HLSL since I'm not that proficient with it. Slang looks like a great way to get rid of the macro logic we currently have to use and it would be nice if we can test it without needing to change the code on the host side. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 2 replies
-
Slang does support trailing unsized arrays. At the moment we don't have an attribute for specifying struct alignment (however we do output alignment specification on the backend for buffer pointer types). The best design for specifying struct alignment did come up in conversation recently however, so I wouldn't be surprised if we implement something along those lines in the future. |
Beta Was this translation helpful? Give feedback.
-
To perform aligned load/stores, you can use |
Beta Was this translation helpful? Give feedback.
Slang does support trailing unsized arrays.
At the moment we don't have an attribute for specifying struct alignment (however we do output alignment specification on the backend for buffer pointer types). The best design for specifying struct alignment did come up in conversation recently however, so I wouldn't be surprised if we implement something along those lines in the future.