Add taichiCourse01 & marching_squares release tests

Author: L2ncE

.github/workflows/scripts/ghstack-perm-check.py

@@ -92,8 +92,10 @@ def must(cond, msg):
         for cr in checkruns["check_runs"]:
             status = cr.get("conclusion", cr["status"])
             name = cr["name"]
+            if name == "Copilot for PRs":
+                continue
             must(
-                status == "success",
+                status in ("success", "neutral"),
                 f"PR #{n} check-run `{name}`'s status `{status}` is not success!",
             )
         print("SUCCESS!")

.github/workflows/scripts/ti_build/entry.py

@@ -32,7 +32,7 @@ def build_wheel(python: Command, pip: Command) -> None:
     Build the Taichi wheel
     """
 
-    git.fetch("origin", "master", "--tags")
+    git.fetch("origin", "master", "--tags", "--force")
     proj_tags = []
     extra = []
 

.github/workflows/scripts/unix-perf-mon.sh

@@ -17,6 +17,8 @@ export ANDROID_NDK_ROOT=/android-sdk/ndk-bundle
 python -m pip uninstall -y taichi taichi-nightly || true
 python -m pip install dist/*.whl
 
+TAG=$(git describe --exact-match --tags 2>/dev/null || true)
+
 git clone --depth=1 https://github.com/taichi-dev/taichi_benchmark
 
 cd taichi_benchmark
@@ -28,7 +30,6 @@ if [ "$GITHUB_EVENT_ACTION" == "benchmark-command" ]; then
     cd ..
     python .github/workflows/scripts/post-benchmark-to-github-pr.py /github-event.json result.json
 else
-    TAG=$(git describe --exact-match --tags 2>/dev/null || true)
     if [ ! -z "$TAG" ]; then
         MORE_TAGS="--tags type=release,release=$TAG"
     else

c_api/include/taichi/taichi_opengl.h

@@ -32,7 +32,8 @@ typedef struct TiOpenglImageInteropInfo {
 
 // Function `ti_import_opengl_runtime`
 TI_DLL_EXPORT TiRuntime TI_API_CALL
-ti_import_opengl_runtime(TiOpenglRuntimeInteropInfo *interop_info);
+ti_import_opengl_runtime(TiOpenglRuntimeInteropInfo *interop_info,
+                         bool use_gles);
 
 // Function `ti_export_opengl_runtime`
 TI_DLL_EXPORT void TI_API_CALL

c_api/src/taichi_opengl_impl.cpp

@@ -18,11 +18,22 @@ taichi::lang::gfx::GfxRuntime &OpenglRuntime::get_gfx_runtime() {
   return gfx_runtime_;
 }
 
+TiRuntime ti_import_opengl_runtime(TiOpenglRuntimeInteropInfo *interop_info,
+                                   bool use_gles) {
+  TI_CAPI_TRY_CATCH_BEGIN();
+  TI_CAPI_ARGUMENT_NULL_RV(interop_info);
+  taichi::lang::opengl::imported_process_address = interop_info->get_proc_addr;
+  taichi::lang::opengl::set_gles_override(use_gles);
+  TI_CAPI_TRY_CATCH_END();
+  return ti_create_runtime(TI_ARCH_OPENGL, 0);
+}
+
 void ti_export_opengl_runtime(TiRuntime runtime,
                               TiOpenglRuntimeInteropInfo *interop_info) {
   TI_CAPI_TRY_CATCH_BEGIN();
   // FIXME: (penguinliogn)
-  interop_info->get_proc_addr = taichi::lang::opengl::kGetOpenglProcAddr;
+  interop_info->get_proc_addr =
+      taichi::lang::opengl::kGetOpenglProcAddr.value();
   TI_CAPI_TRY_CATCH_END();
 }
 

docs/cover-in-ci.lst

@@ -1,5 +1,6 @@
 docs/design/llvm_sparse_runtime.md
 docs/lang/articles/about/overview.md
+docs/lang/articles/advanced/argument_pack.md
 docs/lang/articles/advanced/data_oriented_class.md
 docs/lang/articles/advanced/dataclass.md
 docs/lang/articles/advanced/meta.md

docs/lang/articles/advanced/argument_pack.md

@@ -0,0 +1,61 @@
+---
+sidebar_position: 6
+---
+
+# Taichi Argument Pack
+
+Taichi provides custom [argpack types](../type_system/type.md#argument-pack-type) for developers to cache unchanged parameters between multiple kernel calls.
+
+Argument packs, also known as argpacks, are user-defined data types that act as wrappers for parameters. They allow multiple parameters to be stored and used as a single parameter. One key advantage of using argpacks is their ability to buffer parameters. If you have certain parameters that remain unchanged when calling kernels, you can store them in argpacks. Taichi can then cache these argpacks, resulting in improved program performance by making it faster.
+
+## Creation and Initialization
+
+You can use the function `ti.types.argpack()` to create an argpack type, which can be utilized to represent view params. The following is an example of defining a Taichi argument pack:
+
+```python
+view_params_tmpl = ti.types.argpack(view_mtx=ti.math.mat4, proj_mtx=ti.math.mat4, far=ti.f32)
+```
+
+You can then use this `view_params_tmpl` to initialize an argument pack with given values.
+
+```python cont
+view_params = view_params_tmpl(
+    view_mtx=ti.math.mat4(
+        [[1, 0, 0, 0],
+         [0, 1, 0, 0],
+         [0, 0, 1, 0],
+         [0, 0, 0, 1]]),
+    proj_mtx=ti.math.mat4(
+        [[1, 0, 0, 0],
+         [0, 1, 0, 0],
+         [0, 0, 1, 0],
+         [0, 0, 0, 1]]),
+    far=1)
+```
+
+## Pass Argument Packs to Kernels
+
+Once argument packs are created and initialized, they can be easily used as kernel parameters. Simply pass them to the kernel, and Taichi will intelligently cache them (if their values remain unchanged) across multiple kernel calls, optimizing performance.
+
+```python cont
+@ti.kernel
+def p(view_params: view_params_tmpl) -> ti.f32:
+    return view_params.far
+
+
+print(p(view_params))  # 1.0
+```
+
+## Limitations
+
+Argpacks are not commonly used types. They are primarily designed as parameter containers, which naturally impose certain limitations on their usage:
+
+- Argpacks can only be used as kernel parameters
+- Argpacks cannot be used as return types
+- Argpacks cannot be nested in Compound Types, but can be nested in other argpacks.
+
+:::note
+
+While argument pack interfaces are currently supported in Taichi, the internal caching mechanism is still being developed. This feature is planned to be implemented in future versions of Taichi.
+
+:::

docs/lang/articles/advanced/dataclass.md

@@ -12,6 +12,12 @@ Taichi provides custom [struct types](../type_system/type.md#compound-types) for
 
 To achieve the ends, Taichi enabled the `@ti.dataclass` decorator on a Python class. This is inspired by Python's [dataclass](https://docs.python.org/3/library/dataclasses.html) feature, which uses class fields with annotations to create data types.
 
+:::note
+
+The `dataclass` in Taichi is simply a wrapper for `ti.types.struct`. Therefore, the member types that a `dataclass` object can contain are the same as those allowed in a struct. They must be one of the following types: scalars, matrix/vector types, and other dataclass/struct types. Objects like `field`, `Vector field`, and `Ndarray` cannot be used as members of a `dataclass` object.
+
+:::
+
 ## Create a struct from a Python class
 
 The following is an example of defining a Taichi struct type under a Python class:
@@ -72,6 +78,7 @@ get_area() # 201.062...
 ## Notes
 
 - Inheritance of Taichi dataclasses is not supported.
+- Default values in Taichi dataclasses are not supported.
 - While it is convenient and recommended to associate functions with a struct defined via `@ti.dataclass`, `ti.types.struct` can serve the same purpose with the help of the `__struct_methods` argument. As mentioned above, the two methods of defining a struct type produce identical output.
 
 ```python

docs/lang/articles/basic/ndarray.md

@@ -223,3 +223,12 @@ test(e) # New kernel compilation
 ```
 
 The compilation rule also applies to external arrays from NumPy or PyTorch. Changing the shape values does not trigger compilation, but changing the data type or the number of array dimensions does.
+
+
+## FAQ
+
+### How to use automatic differentiation with ndarrays?
+
+We recommend referring to [this project](https://github.com/taichi-dev/taichi-nerfs/blob/main/notebooks/autodiff.ipynb).
+
+Currently, the support for automatic differentiation in Taichi's ndarray is still incomplete. We are working on improving this functionality and will provide a more detailed tutorial as soon as possible.

docs/lang/articles/kernels/kernel_function.md

@@ -348,3 +348,23 @@ Type hinting is a formal solution to statically indicate the type of value withi
 #### Can I call a kernel from within a Taichi function?
 
 No. Keep in mind that a kernel is the smallest unit for Taichi's runtime execution. You cannot call a kernel from within a Taichi function (in the Taichi scope). You can *only* call a kernel from the Python scope.
+
+#### Can I specify different backends for each kernel separately?
+
+Currently, Taichi does not support using multiple different backends simultaneously. Specifically, at any given time, Taichi only uses one backend. While you can call `ti.init()` multiple times in a program to switch between the backends, after each `ti.init()` call, all kernels will be recompiled to the new backend. For example:
+
+```python
+ti.init(arch=ti.cpu)
+
+@ti.kernel
+def test():
+    print(ti.sin(1.0))
+
+test()
+
+ti.init(arch=ti.gpu)
+
+test()
+```
+
+In the provided code, we begin by designating the CPU as the backend, upon which the `test` function operates. Notably, the `test` function is initially executed on the CPU backend. As we proceed by invoking `ti.init(arch=ti.gpu)` to designate the GPU as the backend, all ensuing invocations of `test` trigger a recompilation of the `test` kernel tailored for the GPU backend, subsequently executing on the GPU. To conclude, Taichi does not facilitate the concurrent operation of multiple kernels on varied backends.