You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A couple of things I noticed while experimenting with structs. I'll mostly be using code from the webgpu_compute_water sample as my test case here...
Ability To Label Structs:
I'm not totally familiar with an alternative solution with setLayout, but currently, I can only make the return type a struct by setting the function's output type to the auto-generated name of the struct within the code output. Ideally, the user should be able to name the struct and use that name as the output type for their function, rather than waiting to see the index the struct resolves to once the code is constructed by its respective NodeBuilder.
// CURRENT CASE: constHeightStruct=struct({heightIndex: 'uint',prevHeightIndex: 'uint'});constGetHeightIndices=Fn(([index])=>{consths=HeightStruct();hs.get('heightIndex').assign(index);hs.get('prevHeightIndex').assign(index);returnhs;}).setLayout({name: 'GetHeightVariables',// The name the NodeBuilder provides the structtype: 'StructType0',inputs: [{name: 'index',type: 'uint'}]});// IDEAL CASEconstHeightStruct=struct({heightIndex: 'uint',prevHeightIndex: 'uint'}).label('Height')constGetHeightIndices=Fn(([index])=>{
...
}).setLayout({type: 'HeightStructType',});
Despite being called only once, the function is executed inline each time its corresponding TSL variable is referenced, even though half of the work of each function call is being unused. Adding a .toVar() declaration to the GetHeightIndices(instanceIndex) call will fix this issue.
Perhaps this is more of a problem with setLayout than the structs themselves, but I feel like the intention behind calling a function is somewhat different than the intention behind a generic mathematical operation in that the user would probably expect the function to only be called once in this case. However, given the brevity and efficiency of inlining these function calls when the outputs are base types, perhaps this issue can simply be resolved by calling out this behavior somewhere in the documentation.
Potential Mathematical Bugs
Thought I'd flag this even though I'm not sure whether my TSL is semantically correct, as to me this seems like a bug. When I attempt to use the element types of a struct in a mathematical calculation, the code output seems to break.
The section on labeling structs and and issues with setLayout are mostly self-contained, existing merely as minor modifications of the first part of the computeHeight function, with all the relevant code contained therein. For the section on using struct values in mathematical operations, I've simply replaced the functions with TSL suffixes with their counterparts as seen in the example code in the Mathematical bugs section.
I'm not totally familiar with an alternative solution with setLayout, but currently, I can only make the return type a struct by setting the function's output type to the auto-generated name of the struct within the code output. Ideally, the user should be able to name the struct and use that name as the output type for their function, rather than waiting to see the index the struct resolves to once the code is constructed by its respective NodeBuilder.
You could use the second parameter name of struct( members, name ) as done in webgpu_struct_drawindirect.
Can you confirm if this solved the problem? It seems that the other problems related to members were also because of .toVar().
Yes that seemed to solve the issue. I removed the toVars() on struct() calls, but the main issue was the return value of the GetNeighborValues(). I tested with toVar() and without toVar(), and the sample now works.
Description
Related PRs: #30394
A couple of things I noticed while experimenting with structs. I'll mostly be using code from the webgpu_compute_water sample as my test case here...
Ability To Label Structs:
I'm not totally familiar with an alternative solution with setLayout, but currently, I can only make the return type a struct by setting the function's output type to the auto-generated name of the struct within the code output. Ideally, the user should be able to name the struct and use that name as the output type for their function, rather than waiting to see the index the struct resolves to once the code is constructed by its respective NodeBuilder.
Functions Matching Equivalent TSL Calls:
In WGSL, the following TSL code....
resolves to this WGSL output
Despite being called only once, the function is executed inline each time its corresponding TSL variable is referenced, even though half of the work of each function call is being unused. Adding a .toVar() declaration to the GetHeightIndices(instanceIndex) call will fix this issue.
Perhaps this is more of a problem with setLayout than the structs themselves, but I feel like the intention behind calling a function is somewhat different than the intention behind a generic mathematical operation in that the user would probably expect the function to only be called once in this case. However, given the brevity and efficiency of inlining these function calls when the outputs are base types, perhaps this issue can simply be resolved by calling out this behavior somewhere in the documentation.
Potential Mathematical Bugs
Thought I'd flag this even though I'm not sure whether my TSL is semantically correct, as to me this seems like a bug. When I attempt to use the element types of a struct in a mathematical calculation, the code output seems to break.
TSL FUNCTION
TSL INPUT 1
TSL INPUT 2
WGSL OUTPUT 1
WGSL OUTPUT 2
Reproduction steps
The section on labeling structs and and issues with setLayout are mostly self-contained, existing merely as minor modifications of the first part of the computeHeight function, with all the relevant code contained therein. For the section on using struct values in mathematical operations, I've simply replaced the functions with TSL suffixes with their counterparts as seen in the example code in the Mathematical bugs section.
Code
// NA
Live example
Live WebGPU Example
Screenshots
No response
Version
r173
Device
Desktop
Browser
Chrome
OS
Windows
The text was updated successfully, but these errors were encountered: