Complete/fix the CUDA mesh signed-distance host launcher (`sdt`)

[balbasty]

Confirmed by the fable review; substantial and GPU-unverifiable, so tracked rather than fixed in the correctness pass.

fastfields-cuda-impl/distance_mesh.h: distance_mesh::dt correctly throws "not implemented" today, but the sdt launcher above it (intended to be the complete one) is internally inconsistent and would not work if wired up:

• the kernel call (~line 591-613) omits the _treetrace/treesize args of sdt_kernel (21-param signature invoked with 19 args) and passes host pointer tree_host instead of the copied tree_device;
• lines ~528/532/533/543 re-declare faces_device/faces_host/verts_host/tree_host, shadowing the outer cleanup variables (leaks; outer frees see nullptr);
• line ~527 initializes offset_t stride_mat[2] with 3 values;
• sdt_kernel (~line 282) uses runtime nbatch as a template argument (index2offset);
• GET_BLOCKS(nbatch) (~line 592) sizes the grid from the batch rank, not the element count.

None is caught because the templates are never instantiated (the honest throw keeps the build green). Needs a careful pass plus real-hardware validation against the naive mesh SDT. Until then the throw stub is correct behaviour.

Workstream: claude-jitfields-to-fastfields

[balbasty]

Reopening, as suggested in fastfields-cuda-impl#40.

Every bullet in the original description is now genuinely fixed — the first three by fastfields-cuda-impl#23, and the remaining compile blockers by fastfields-kernels#76 + fastfields-cuda-impl#42. But this issue was closed as completed while its own acceptance bar — "needs a careful pass plus real-hardware validation against the naive mesh SDT" — had not been met, and there is no other open issue tracking that. So rather than filing a replacement, I am reopening this one to carry the residual work.

Done

from the original list	status
kernel call omits _treetrace/treesize; passes host tree_host	fixed, fastfields-cuda-impl#23
shadowed faces_device/faces_host/verts_host/tree_host (leaks)	fixed, #23
offset_t stride_mat[2] initialized with 3 values	fixed, #23
sdt_kernel uses runtime nbatch as a template argument	fixed, #23
GET_BLOCKS(nbatch) sizes the grid from the batch rank	fixed, #23

Plus three defects found afterwards, none of which were in the original list:

• MeshDist::build_tree and the 3D MeshDistUtil::build_normals were hidden from both of nvcc's passes by #ifndef __CUDACC__, so sdt() did not compile at all — fastfields-kernels#76.
• copyTensorToContiguous called with ndim where it wants the tensor rank, reading one past a 2-element stack array and producing a garbage cudaMalloc size — fastfields-cuda-impl#42.
• stride_faces / stride_vertices never used, so non-contiguous input tensors would be misread — reg_field/reg_flow: add matvec_add/matvec_sub device dispatch + bump pins #42.

The last of these is the reason the closure looked safe: distance_mesh::dt throws "not implemented", so nothing ever instantiated sdt and CI was green regardless. #42 adds a compile-only probe TU (tests/compile_probe_mesh.cu) that instantiates the mesh launchers for D ∈ {2,3} × {float/int, double/long}, so this class of defect is now caught by CI instead of by re-review.

Still open — what this issue now tracks

1. dt is still a throw stub. distance_mesh::dt in the CUDA path still raises "distance_mesh::dt (CUDA) not implemented"; sdt compiles but is unreachable. Wiring up the entry point was deliberately kept out of reg_field/reg_flow: add matvec_add/matvec_sub device dispatch + bump pins #42.
2. The launcher has never been executed. No GPU in CI — everything above is compile+link evidence only. The atomics, the stream plumbing and the tree walk all remain unvalidated, and the original bar (validate against the naive mesh SDT on real hardware) still stands.
3. Blocker: fastfields-kernels#75. The host→device cudaMemcpy of host-constructed polymorphic Node / BoundingSphere bytes copies objects with vptrs across address spaces, which is UB. fastfields-kernels#76 only made those destructors callable from device code; it did not make the memcpy sound. This needs resolving before (2) can mean anything.

Until then the throw stub remains the correct behaviour, exactly as the original description says.

🤖 Generated with Claude Code

https://claude.ai/code/session_016AjQcY78NgbagPSbPJRr6Z

---

Generated by Claude Code

[balbasty]

PR #86 moves two of the three residual items, and deliberately leaves the third alone. Not closing this — the acceptance bar is still unmet.

What #86 does

• sdt_naive gets a CUHOST launcher, and dt's signed+naive branch dispatches into it instead of throwing. Structural mirror of cpu-impl's sdt_naive + build_sdt_naive: contiguous device gather → D2H → shared-kernels normal build → upload → grid from prod(size, nbatch) → sdt_naive_kernel. sdt_naive_kernel gained the nearest_vertex / stride_nearest pair it was missing relative to the CPU worker. This is the brute-force reference that item 2 below wants sdt checked against, so it needed to exist first.
• A real defect in the already-dispatched sdt: the vertex pseudonormals are accumulated into (normvertices[v].add_(normal) per incident face), but the buffer came from allocHost (cudaMallocHost), which does not zero — cpu-impl uses new scalar_t[...]() for exactly this reason. It would have perturbed the sign of the returned distance near vertices and edges. Not a class of bug compile+link can see, which is worth noting given that is the whole gate here.
• tests/impl-cuda/compile_probe_mesh.cu instantiates the new launcher for all four (dim × dtype) combinations plus the null-nearest_vertex shape.

Item 1 (dt still a throw) — now partly closed

dt no longer throws for signed+naive. It still throws for the two unsigned branches (udt, udt_naive), which have device kernels and no launcher. The table in the file header is updated to match.

Item 3 (kernels#75, polymorphic Node memcpy) — no longer a blocker

The DeviceNode POD mirror + flatten_tree already removed the host→device copy of polymorphic Node bytes: nothing memcpys a Node any more. That is not what stands in the way now.

The precomputed-tree sdt overload — left throwing, on purpose

Its signature does not carry what a correct body needs, and none of the gaps is discoverable from a call site:

1. const void * tree — sdt_kernel wants a device array of the POD DeviceNode mirror, not the polymorphic host Node[] build_tree produces. A void * cannot tell those apart (fastfields-cuda-impl#44 removed exactly that ambiguity from sdt_kernel), and nothing in the repo hands a caller a DeviceNode array — flatten_tree + upload are private to the other sdt.
2. void * treetrace / treesize — the trace is per lane, interleaved across lanes, so the buffer must be GET_BLOCKS(numel) * CUDA_NUM_THREADS * treesize bytes: a size determined by the launch configuration the launcher itself picks.
3. faces must be the BVH-sorted list — build_tree reorders in place and its leaves index the sorted order.

Two ways out, both design changes rather than fill-in-the-body work: (a) type the parameters (const DeviceNode<...> *, char *) and give it an in-repo caller by making the outer sdt delegate to it — i.e. adopt cpu-impl's sdt / build_sdt split, renaming it build_sdt to match; or (b) drop the overload, which has no caller, no producer for its tree argument and no test. The TODO comment (which recorded only the previous bad attempt) now states all of the above so the next person does not have to re-derive it.

Still open, and why this stays open

Nothing here has been executed. No GPU in CI; the evidence is nvcc compile+link. The tree walk, the atomics, the stream plumbing and the normal-buffer lifetimes are unverified, and the original bar — sdt vs sdt_naive agreement on real hardware — is exactly as open as it was. Both sides of that comparison now exist and are reachable through ff::dt_mesh, which is the part that was missing.

---

Generated by Claude Code