# Pointnet2_PyTorch: the CUDA port everyone still points at, and why it is unmaintained > A PyTorch and PyTorch Lightning implementation of Pointnet++ that pairs hand-written CUDA kernels with Hydra-configured training, left frozen by its author on purpose rather than by accident. **erikwijmans/Pointnet2_PyTorch** — PyTorch implementation of Pointnet2/Pointnet++ - Repository: https://github.com/erikwijmans/Pointnet2_PyTorch - Stars: 1,813 · Forks: 399 - Language: Python - License: Unlicense - Published: 2026-10-06 · Updated: 2026-10-06 · Language: en - Canonical page: https://hysenlabs.com/projects/erikwijmans-pointnet2-pytorch ## The status line that decides how you read everything else The second line of the README settles the question: the project status is unmaintained, the author writes that finite time means there are no plans to update the code, and that issues will not get a response. That sentence is the single most important fact in the repository and it belongs at the top of any evaluation. The repository is not archived, so it stays visible in search results and still receives forks, but nothing about the open issue count should be read as a queue that will be worked through. The last push was on 2026-05-18, which tells you the tree is not rotting in place, but a recent push and an intent to support the project are different things. The author removed himself from the maintenance question explicitly, and nothing in the repository contradicts that. The licence is the Unlicense, and the file appears in the tree as UNLICENSE. There are no usage obligations attached to the code itself, which matters here more than the norm, because the only thing a frozen research repository can still offer a reader is permission to read it, copy it, and build something else from it. ## Pointnet++ in PyTorch, with the official TensorFlow release as the reference The repository is a PyTorch implementation of Pointnet2 and Pointnet++, written by Erik Wijmans. The citation block at the bottom of the README points at the NeurIPS 2017 paper, Pointnet++: Deep hierarchical feature learning on point sets in a metric space, by Qi, Li, Su, and Guibas, and gives the year of this implementation as 2018. The README is careful about the relationship between this code and the original. It directs readers to the official code release for the paper, which is a TensorFlow repository under a different owner, for the official model definitions and hyper-parameters. That is an unusually clean separation of concerns for a research port, and it tells you what to trust for what. The architecture and its hyperparameters come from the TensorFlow release. The PyTorch code is the thing you would read to understand how that architecture maps onto PyTorch modules. Topics on the repository are hydra, point-cloud, pointnet2, pytorch, and pytorch-lightning, which is an accurate summary of the dependency surface. One capability is listed that matters for cluster work: multi-GPU support through `nn.DataParallel`. That is the older mechanism, which splits a batch across devices inside a single process, and it is worth noticing that it is chosen here rather than the distributed data parallel machinery that came later. ## The custom ops that only run on a CUDA GPU The most consequential line in the README is the restriction: the custom ops used by Pointnet++ are currently only supported on the GPU using CUDA. This is not a soft caveat. Pointnet++ depends on neighbourhood grouping and local aggregation operations over point sets, and this repository implements them as compiled kernels rather than pure PyTorch tensor operations. Those kernels are CUDA. There is no CPU path. If you were planning to run this on a laptop CPU, or to smoke-test the code on CI without a GPU, you are out of luck and you will find that out after the install step rather than before it. The repository does contain a tests directory and a tox.ini, but the constraint applies to the operations the tests exercise. The build step is separate from the Python package install, and the README treats it as a first-class operation with its own heading. The kernels can be installed from the local directory: ```bash pip install pointnet2_ops_lib/. ``` The alternative form installs from git and points at the same subdirectory, which the README notes is the form to use in a requirements.txt: ```bash pip install "git+git://github.com/erikwijmans/Pointnet2_PyTorch.git#egg=pointnet2_ops&subdirectory=pointnet2_ops_lib" ``` Note that the second line still refers to this repository's default branch, so it inherits the same frozen state. ## Dependencies pinned to a narrow window of 2019 tooling requirements.txt is short and the pins are the interesting part: ```bash numpy msgpack-numpy lmdb h5py ``` then hydra and pytorch lightning at exact versions, followed by a local path install of the ops library. setup.py agrees with that list, naming hydra-core and pytorch-lightning as its install requirements and reading the package version out of `pointnet2/_version.py` rather than hard-coding it. Those two pins are dated versions, and they tell you the era this code targets. The README states the testing window plainly: Python 3.6 and 3.7, and PyTorch 1.4 and 1.5, with the note that it may work with versions newer than 1.5 but that this is not guaranteed. PyTorch itself is a soft requirement of at least 1.0.0, and for anything older the README points at the v1.0 release. That single release explains an otherwise baffling branch of the repository's history. It is tagged v1.0, published on 2019-01-08, named for PyTorch up to 0.4, and its description says it uses the old style of PyTorch bindings via cffi that were deprecated in PyTorch 1.0.0. So there are two coherent versions of this project: a pre-1.0 PyTorch line that builds bindings a completely different way, and the current line. That is the only release in the repository. ## Training through Hydra task and model overrides The install step for the package itself is an editable install, and the README points at `pointnet2/train.py` as the training entry point. The configuration system is Hydra, with PyTorch Lightning running the loop, and the README is explicit that the training examples are built with both. Overriding configuration from the command line is how the script is meant to be driven, and the README gives three forms. Task selects the problem, so classification and semantic segmentation are the same script with a different task: ```bash python pointnet2/train.py task=cls python pointnet2/train.py task=semseg ``` The model key selects between plain classification and multi-scale grouping: ```bash python pointnet2/train.py task=cls model=msg ``` Multi-GPU training takes a list of device ids: ```bash python pointnet2/train.py task=cls gpus=[0,1,2,3] ``` For someone reading the repository today, this is the most transferable part. A Hydra override is a command-line argument, so every experiment variant in the paper is reproducible as a string you can paste, and the classification and segmentation paths being one script keeps the data loading and model definition logic in a single place. ## Style tooling and what the repository is actually for The tree carries the scaffolding of a serious code review culture, which is a hint about how the author expected the code to be handled. There is a `.pre-commit-config.yaml` and a `tox.ini` for test orchestration, a `.travis.yml` for continuous integration, and a `MANIFEST.in` for packaging. pyproject.toml configures black with an exclusion list covering build directories, and configures isort with a known-third-party list naming h5py, hydra, lmdb, numpy, pytest, torch, and torchvision among others. The README describes the style policy in one sentence: black for Python, clang-format for C++ and CUDA, and pre-commit as the simplest way to comply. The hook install is two commands: ```bash pip install pre-commit pre-commit install ``` What none of this machinery does is keep the project current, and it would be misleading to read the presence of a tests directory and a tox.ini as a sign of ongoing care. They describe the project at the moment it was frozen. So the honest framing is this. Pointnet2_PyTorch is the port that a great many PyTorch point cloud projects have historically pointed at, and it remains a readable answer to the question of how Pointnet++ is expressed in PyTorch with compiled neighbourhood ops. It is not somewhere to file an issue about a modern PyTorch version. If the point of the exercise is running Pointnet++ on recent hardware, the CUDA-only kernels and the 2019 pins are the two walls you will hit first. ## Conclusion Read this as a reference implementation rather than a dependency. The value that survives the freeze is architectural: it shows how a point cloud network gets its own compiled kernels, how those kernels are packaged as a Python extension, and how Hydra and PyTorch Lightning fit together for a research codebase. Start from requirements.txt, because the pinned hydra-core and pytorch-lightning versions tell you immediately which era of those tools this expects, then read the CUDA-only restriction in the README before you plan an experiment on CPU. If you need Pointnet++ today with current PyTorch, the official TensorFlow release named in the README is where the model definitions and hyper-parameters come from, and the open issue count suggests the PyTorch port has become the usual place people ask what to do next. ## FAQ ### Can Pointnet2_PyTorch run on a CPU without a GPU? No. The README states that the custom ops used by Pointnet++ are currently only supported on the GPU using CUDA, and no CPU path is documented. You will need an NVIDIA GPU with CUDA for the operations this implementation relies on. ### Is this repository still being maintained? No, and the README says so directly: the project status is unmaintained, the author has no plans to update the code due to finite time, and will not be responding to issues. The repository is not archived, but the author has withdrawn from the maintenance question. The last push was on 2026-05-18. ### What Python and PyTorch versions does it support? The repository is tested with Python 3.6 and 3.7 and PyTorch 1.4 and 1.5, with the README noting it may work on versions newer than 1.5 without guarantee. PyTorch 1.0.0 or newer is required for the current code, and the v1.0 release exists for older versions using cffi bindings. ### How do I train for semantic segmentation instead of classification? Both use the same script, pointnet2/train.py, and the task is a Hydra override on the command line. Use task=semseg for semantic segmentation and task=cls for classification, adding model=msg if you want the multi-scale grouping variant. ### Where should I get the official model definitions and hyperparameters? The README directs you to the official TensorFlow code release for the paper, charlesq34/pointnet2, for the official model definitions and hyper-parameters. This repository is the PyTorch implementation of that work. ## Sources - [erikwijmans/Pointnet2_PyTorch on GitHub](https://github.com/erikwijmans/Pointnet2_PyTorch) - [Issues](https://github.com/erikwijmans/Pointnet2_PyTorch/issues) - [License: Unlicense](https://github.com/erikwijmans/Pointnet2_PyTorch/blob/master/LICENSE) - [README](https://github.com/erikwijmans/Pointnet2_PyTorch/blob/master/README.md) - [Releases](https://github.com/erikwijmans/Pointnet2_PyTorch/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/erikwijmans-pointnet2-pytorch