Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEA] Migrate All PyTorch-Dependent Code to cuGraph-GNN #4822

Open
alexbarghi-nv opened this issue Dec 10, 2024 · 1 comment
Open

[FEA] Migrate All PyTorch-Dependent Code to cuGraph-GNN #4822

alexbarghi-nv opened this issue Dec 10, 2024 · 1 comment
Assignees
Labels
feature request New feature or request

Comments

@alexbarghi-nv
Copy link
Member

alexbarghi-nv commented Dec 10, 2024

We continue to have issues with PyTorch in this repository's CI. In addition, the code that depends on PyTorch is really only used by cuGraph-GNN and does not really fit the mission of this repository. As discussed over the past few months, we want to migrate as much GNN code as possible to the cugraph-gnn repository.

There are three key pieces of code affected:

  1. The FeatureStore class which is about to be deprecated (in release 25.02)
  2. The BulkSampler class which is also about to be deprecated (in release 25.02)
  3. The DistSampler class, the replacement for BulkSampler, which is a fundamental piece of our GNN infrastructure.

There is also going to be some additional code in the very near future supporting GNN use cases related to GraphRAG, graph databases, and other frameworks (beyond DGL and PyG). This would also better fit within cugraph-gnn.

We propose creating a new package, pylibcugraphgnn, which will contain the bulk sampling code, as well as any other framework-agnostic code and/or thin wrappers around our C++ code for GNN operations. This package will presumably launch with release 25.04.

@rlratzel
Copy link
Contributor

rlratzel commented Feb 5, 2025

Would pylibcugraph-gnn be used by any other package beyond cugraph-gnn? For example, we created pylibcugraph so the same Cython bindings could be used by multiple higher-level APIs (cugraph, nx-cugraph, cugraph-pyg, etc.). If the PLC-gnn code is only (and always?) used by cugraph-gnn, can it just be part of the same package? I'm not seeing the advantage of another package if it's only used by cugraph-gnn (and presumably not optional), or maybe I'm missing something?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants