[RFC] Argument pack API

[bobcao3]

Similar to how we currently declare arguments for kernels in Taichi CGraph, we can use something similar for the regular kernel launch (with some additions). This API can be used to simplify kernel arguments and passing of resource for larger production projects, such as a raytracer or a production level PBD simulator.

The idea is that the user can create "argument templates", and "argument packs" that instantiates a template (or construct one implicitly by its content). When launching kernels, the argument templates can be used as the argument type, and the kernel should be able to access its members using subscript or .member

In addition, we should support cascading argument packs just like structs in C, and we should let the ordinary kernel arguments syntax be an implicit argument pack. This way we get a consistent semantics for all arguments.

Here is an example:

# Create templates
view_params_tmpl = ti.types.argpack({ view_mtx : ti.mat4, proj_mtx : ti.mat4, far : ti.f32 })
scene_data_tmpl = ti.types.argpack({ n_objects : ti.i32, verticies : ti.types.resource_heap(ti.ndarray(...), dynamic_size=True), textures : ti.types.resource_heap(ti.types.texture(2), dynamic_size=True) })

# Instantiate packs
view_params = view_params_tmpl(view_mtx, ...)
textures = ti.arg_array()
textures.append(...)

...
scene_data = scene_data_tmpl(n_objects, verticies, textures)

renderA(view_params, scene_data, 2.0) # -> creates implicit argpack and its template { view_params :  view_params_tmpl, scene_data : scene_data_tmpl, c : ti.f32 }
renderB(scene_data) # -> always creates implicit argpack for kernel arguments { scene_data : scene_data_tmpl }

[bobcao3]

I think we can approach this in steps. First step is to support basic argpacks without nesting and resource heaps. Second step is to support resource heap, and the third step would be to support nesting and implicit argument templates

[listerily]

Argument pack is implemented in these Pull Requests.

• [lang] [ir] Support argpack nesting #8273
• [llvm] [ir] Implemented argpack buffer load on llvm devices #8267
• [lang] Argpacks stores scalar values only in cpp implementation, and passes ndarray values by 'virtual parameters' #8266
• [test] Recover skipped argpack tests (spir-v backends only) #8265
• [Bug] Fix argpack nesting issues #8264
• [spirv] [ir] Support argpack buffer load for spir-v backends #8263
• [Bug] Convert matrices to structs in argpack type members, Fixing layout error #8262
• [lang] Add arg_depth property to Expressions and Statements #8259
• [lang] Add is_argpack property to Argument and pass argpack ptrs to LaunchContextBuilder #8257
• [bug] Fix indexing crash in TaskCodeGenLLVM::get_struct_arg #8256
• [lang] Add set_arg methods to ArgPack and pass scalar values to ArgPack buffer #8255
• [lang] Instantiate a runtime ArgPack object when a python ArgPack is created #8241
• [refactor] Renamed allocate_memory_ndarray to allocate_memory_on_device #8240
• [lang] Link cpp ArgPackType object to python ArgPackType #8178
• [lang] Add cpp impl of ArgPackType #8176
• [refactor] Enhance argument data structures, replacing vector styled arguments with nestable styled arguments #8216
• [refactor] Make arg_id a vector #8204

However, this requirement is not implemented yet.

All parameters of a kernel will be implicitly constructed as an ArgPack; same for return values

[listerily]

Should we mark Argument Pack is completed, ignoring this requirement?

All parameters of a kernel will be implicitly constructed as an ArgPack; same for return values

Or keep this issue open?