Fix Windows/MSVC build: template disambiguator and C++20 flags

[rwfsmith]

Summary

Two small changes needed to build the CUDA extension on Windows with MSVC. Both are build-time only — no runtime behavior change, and Linux flags are untouched.

1. template disambiguator on dependent data_ptr<T>() calls

flex_gemm/kernels/cuda/spconv/sparse_neighbor_map.cu has four calls of the form:

hashmap_keys.data_ptr<T>()

inside the function templates hashmap_build_sparse_conv_out_coords<T> and expand_unique_build_sparse_conv_out_coords<T>. MSVC (with /permissive-) fails to compile these — it doesn't parse <T> as a template argument list in this context. Adding the explicit template disambiguator resolves it:

hashmap_keys.template data_ptr<T>()

This is valid, well-formed C++ and a no-op for GCC/clang, which already parse the original form fine. Four call sites, lines 114 / 128 / 327 / 341.

2. C++20 for the Windows compile flags

The Windows branch of setup.py sets /std:c++17 and -std=c++17. Current PyTorch headers require C++20, so that block no longer compiles against recent PyTorch (2.13 here). Bumped the three Windows flags to C++20.

Scoped to if platform.system() == "Windows": — the Linux branch below it is unchanged, so existing builds are unaffected.

Verification

Builds and runs on Windows 11 / Python 3.13 / CUDA 13.0 / MSVC (VS2022) / PyTorch 2.13 / RTX 5090 (sm_120), exercised through TRELLIS.2's sparse convolution backend (CONV = 'flex_gemm') and the grid-sample path in its renderers — full image-to-3D generation end to end.

I have not rebuilt on Linux. The template change is compiler-agnostic and the flag change is inside the Windows-only branch, so neither should affect Linux builds, but a CI run would confirm.

Note

If you'd rather keep C++17 for compatibility with older PyTorch, the flag bump could be made conditional on the detected torch.__version__. Happy to rework it — I went with the straight bump since the Windows block is already separate and PyTorch itself has moved on.