[metal] Add SNodeRep_pointer

[k-ye]

SNodeRep_pointer is functionally equivalent to LLVM's https://github.com/taichi-dev/taichi/blob/master/taichi/runtime/llvm/node_pointer.h. There are a few implementation details specific to Metal, though:

• Like the LLVM backend, each cell of a pointer SNode stores only the pointer to the data, not the data itself. However, unlike LLVM, this is not a real pointer, but merely an int32_t that indexes into somewhere in the Metal buffer memory. The NodeManager instance passed to this Rep's init() knows how to recover the data address from this int32_t. See child_or_ambient_addr().

• In [metal] Refactor sparse shader impl in prep for pointer SNode #1994, I added NodeManager::ElemIndex, which has a notion of raw vs index value. They differ by kIndexOffset.
  

  taichi/taichi/backends/metal/shaders/runtime_structs.metal.h

  Lines 89 to 99 in 16af509

  	inline int32_t index() const {
  	return raw_ - kIndexOffset;
  	}
  	inline int32_t raw() const {
  	return raw_;
  	}
  	inline bool is_valid() const {
  	return raw_ >= kIndexOffset;
  	}

  
  This shift is necessary for ElemIndex to know if its raw_ is a valid index in the memory or not. A valid raw_ value is always greater than or equal to kIndexOffset, while values below that represents special values that are necessary for the memory allocation ([Metal] Support dynamic memory allocation on GPU #1174) to work (0: nullptr; 1: allocation in progress).

• A pointer SNode cell stores the raw value of its ElemIndex, which is initialized to 0. Inside activate(), if the allocation succeeds, it will store nm_idx_raw = nm_.allocate().raw() into the cell. As a result, in to_nodemgr_idx(), we read the cell's int32_t, and uses ElemIndex::from_raw(), instead of ElemIndex::from_index(). Same for deactivate().

Related issue = #1740

[Click here for the format server]

---

[codecov]

Codecov Report

Merging #2000 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #2000   +/-   ##
=======================================
  Coverage   43.50%   43.50%           
=======================================
  Files          45       45           
  Lines        6266     6266           
  Branches     1109     1109           
=======================================
  Hits         2726     2726           
  Misses       3367     3367           
  Partials      173      173           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 16af509...e939071. Read the comment docs.

[yuanming-hu]

LGTM!

Just curious: it seems that Metal doesn't support 64-bit data types, but there are indeed pointers in the code. Are all pointers 32-bit in Metal?

[k-ye]

Just curious: it seems that Metal doesn't support 64-bit data types, but there are indeed pointers in the code. Are all pointers 32-bit in Metal?

I believe the pointers are still 64bit, we just don't have 64bit data support (at least not in the Metal buffer :-/ )