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
We should add support for global variables. A common pattern is to have the Root node have input attributes, which is set by host code at runtime. Then each node in the tree pushes this value down to its children.
This pattern is so common, we should implement language support for it. The easiest option for this is creating a macro for the push-down code, so that we simply annotate the 'global' attributes in the root, and then the macro will take care of making sure each node in the tree has a copy of them assigned to it. However, this still has the problem that we're duplicating every global variable for every node in the tree, taking space and time.
The other option is to implement compiler/backend support for globals wherein we have a memory location accessible to every node. Global values exist in this buffer only, and access to them by FTL code is rewritten to be an access of this global buffer. Before committing to this, we should investigate performance characteristics (e.g., to avoid memory access bottlenecking, or if we should have this global buffer copied to thread group local memory at the start of computation, etc.)
The text was updated successfully, but these errors were encountered:
We should add support for global variables. A common pattern is to have the Root node have input attributes, which is set by host code at runtime. Then each node in the tree pushes this value down to its children.
This pattern is so common, we should implement language support for it. The easiest option for this is creating a macro for the push-down code, so that we simply annotate the 'global' attributes in the root, and then the macro will take care of making sure each node in the tree has a copy of them assigned to it. However, this still has the problem that we're duplicating every global variable for every node in the tree, taking space and time.
The other option is to implement compiler/backend support for globals wherein we have a memory location accessible to every node. Global values exist in this buffer only, and access to them by FTL code is rewritten to be an access of this global buffer. Before committing to this, we should investigate performance characteristics (e.g., to avoid memory access bottlenecking, or if we should have this global buffer copied to thread group local memory at the start of computation, etc.)
The text was updated successfully, but these errors were encountered: