Added fbgemm recipe building fbgemm, fbgemm-gpu, and fbgemm-gpu-genai by das-intensity · Pull Request #31820 · conda-forge/staged-recipes

das-intensity · 2026-01-01T18:50:32Z

Checklist

github-actions · 2026-01-01T18:51:54Z

Hi! This is the staged-recipes linter and your PR looks excellent but I have some suggestions.

File-specific lints and/or hints:

recipes/fbgemm/meta.yaml:
- hints:
  - It looks like you are submitting a multi-output recipe. In these cases, the correct name for the feedstock is ambiguous, and our infrastructure defaults to the top-level package.name field. Please add a feedstock-name entry in the extra section.

conda-forge-admin · 2026-01-01T18:52:08Z

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipes/fbgemm/meta.yaml, recipes/asmjit/meta.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipes/fbgemm/meta.yaml:

ℹ️ The recipe is not parsable by parser conda-souschef (grayskull). This parser is not currently used by conda-forge, but may be in the future. We are collecting information to see which recipes are compatible with grayskull.
ℹ️ The recipe is not parsable by parser conda-recipe-manager. The recipe can only be automatically migrated to the new v1 format if it is parseable by conda-recipe-manager.

For recipes/asmjit/meta.yaml:

ℹ️ The recipe is not parsable by parser conda-souschef (grayskull). This parser is not currently used by conda-forge, but may be in the future. We are collecting information to see which recipes are compatible with grayskull.
ℹ️ The recipe is not parsable by parser conda-recipe-manager. The recipe can only be automatically migrated to the new v1 format if it is parseable by conda-recipe-manager.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/20698834647. Examine the logs at this URL for more detail.}

h-vetinari

Thanks for the work on this. This will need some more iteration. Perhaps also consider writing this as a v1 recipe (not required, but should be beneficial, e.g. for things like the git checkout stuff).

h-vetinari · 2026-01-02T01:52:23Z

+  number: 0
+  skip: true  # [py<38]
+  skip: true  # [win]
+  skip: true  # [aarch64]  # git_url source requires git on build system, problematic for cross-compilation


Even if that were the case (which I doubt), we would be able to use $BUILD_PREFIX/bin/git

So interestingly it uses git to clone, but then says git isn't available. See here: https://gist.github.com/das-intensity/7f5a5bc9d238bbcd63940863a6ab3404

Try adding

- git - git-lfs

to the build environment. For whatever reason, the checkout procedure tries to look in there

FileNotFoundError: [Errno 2] No such file or directory: '/home/conda/staged-recipes/build_artifacts/fbgemm_1767418241898/_build_env/bin/git'

git-lfs may not be strictly necessary, but addresses

git: 'lfs' is not a git command. See 'git --help'.

h-vetinari · 2026-01-02T01:53:28Z

+  - name: fbgemm
+    build:
+      script: |
+        git submodule update --init --recursive


conda should normally default to recursive checkouts of submodules? Did you test that this is required?

As an aside, why not start out with a v1 recipe right away?

conda should normally default to recursive checkouts

Right you are, I think I just missed removing this output. Will drop.

why not start out with a v1 recipe right away?

I think I read this: https://github.com/conda-forge/staged-recipes/blob/main/recipes/example-v1/README.md?plain=1#L3

but is not yet fully supported by conda-forge's automation.

and figured I didn't know enough conda-forge to know whether what's "not yet fully supported" would come back to bite me (plus I was more familiar with legacy style).

but is not yet fully supported by conda-forge's automation.

That comment is 2 years old. By now things work pretty much without a hitch.

h-vetinari · 2026-01-02T01:56:01Z

+        - python
+        - pip
+        - setuptools-git-versioning
+        - pytorch
+        - pytorch * *cuda*  # [cuda_compiler_version != "None"]
+        - scikit-build
+        - tabulate
+        - jinja2
+        - pyyaml
+        - cuda-cudart-dev  # [cuda_compiler_version != "None"]
+        - cuda-nvrtc-dev  # [cuda_compiler_version != "None"]
+        - cuda-nvtx-dev  # [cuda_compiler_version != "None"]
+        - libcublas-dev  # [cuda_compiler_version != "None"]
+        - libcusolver-dev  # [cuda_compiler_version != "None"]
+        - libcusparse-dev  # [cuda_compiler_version != "None"]
+        - libcurand-dev  # [cuda_compiler_version != "None"]


all of this should be in host:, not build:

I suspect you're probably right about SOME of these, but I switched from:

build: - {{ compiler('c') }} - {{ compiler('cxx') }} - {{ compiler('cuda') }} # [cuda_compiler_version != "None"] - {{ stdlib('c') }} - cmake - make - ninja - git - python - pip - setuptools-git-versioning - pytorch - pytorch * *cuda* # [cuda_compiler_version != "None"] - scikit-build - tabulate - jinja2 - pyyaml - cuda-cudart-dev # [cuda_compiler_version != "None"] - cuda-nvrtc-dev # [cuda_compiler_version != "None"] - cuda-nvtx-dev # [cuda_compiler_version != "None"] - libcublas-dev # [cuda_compiler_version != "None"] - libcusolver-dev # [cuda_compiler_version != "None"] - libcusparse-dev # [cuda_compiler_version != "None"] - libcurand-dev # [cuda_compiler_version != "None"] host: - python - pip - setuptools - setuptools-git-versioning - wheel - pytorch - scikit-build - numpy - cuda-version {{ cuda_compiler_version }} # [cuda_compiler_version != "None"]

to

build: - {{ compiler('c') }} - {{ compiler('cxx') }} - {{ compiler('cuda') }} # [cuda_compiler_version != "None"] - {{ stdlib('c') }} - cmake - make - ninja - git host: - python - pip - setuptools - setuptools-git-versioning - wheel - pytorch - pytorch * *cuda* # [cuda_compiler_version != "None"] - scikit-build - numpy - tabulate - jinja2 - pyyaml - cuda-version {{ cuda_compiler_version }} # [cuda_compiler_version != "None"] - cuda-cudart-dev # [cuda_compiler_version != "None"] - cuda-nvrtc-dev # [cuda_compiler_version != "None"] - cuda-nvtx-dev # [cuda_compiler_version != "None"] - libcublas-dev # [cuda_compiler_version != "None"] - libcusolver-dev # [cuda_compiler_version != "None"] - libcusparse-dev # [cuda_compiler_version != "None"] - libcurand-dev # [cuda_compiler_version != "None"]

but the cuda build failed with:

[ 7%] Building CXX object CMakeFiles/asmjit.dir/home/conda/staged-recipes/build_artifacts/fbgemm_1767562352076/work/external/asmjit/src/asmjit/core/builder.cpp.o /home/conda/staged-recipes/build_artifacts/fbgemm_1767562352076/_build_env/bin/x86_64-conda-linux-gnu-c++ -DPROTOBUF_USE_DLLS -DUSE_C10D_GLOO -DUSE_C10D_NCCL -DUSE_DISTRIBUTED -DUSE_RPC -DUSE_TENSORPIPE -Dasmjit_EXPORTS -isystem /home/conda/staged-recipes/build_artifacts/fbgemm_1767562352076/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/python3.11/site-packages/torch/include -isystem /home/conda/staged-recipes/build_artifacts/fbgemm_1767562352076/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/python3.11/site-packages/torch/include/torch/csrc/api/include -isystem /home/conda/staged-recipes/build_artifacts/fbgemm_1767562352076/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/include -isystem /home/conda/staged-recipes/build_artifacts/fbgemm_1767562352076/_build_env/targets/x86_64-linux/include -DNO_AVX512=1 -O3 -DNDEBUG -std=c++20 -fPIC -Wno-deprecated-anon-enum-enum-conversion -Wno-deprecated-declarations -D_GLIBCXX_USE_CXX11_ABI=1 -MD -MT CMakeFiles/asmjit.dir/home/conda/staged-recipes/build_artifacts/fbgemm_1767562352076/work/external/asmjit/src/asmjit/core/builder.cpp.o -MF CMakeFiles/asmjit.dir/home/conda/staged-recipes/build_artifacts/fbgemm_1767562352076/work/external/asmjit/src/asmjit/core/builder.cpp.o.d -o CMakeFiles/asmjit.dir/home/conda/staged-recipes/build_artifacts/fbgemm_1767562352076/work/external/asmjit/src/asmjit/core/builder.cpp.o -c /home/conda/staged-recipes/build_artifacts/fbgemm_1767562352076/work/external/asmjit/src/asmjit/core/builder.cpp In file included from /home/conda/staged-recipes/build_artifacts/fbgemm_1767562352076/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/include/ATen/cuda/CUDAContext.h:3, from /home/conda/staged-recipes/build_artifacts/fbgemm_1767562352076/work/fbgemm_gpu/src/embedding_inplace_ops/embedding_inplace_update_gpu.cpp:11: /home/conda/staged-recipes/build_artifacts/fbgemm_1767562352076/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/include/ATen/cuda/CUDAContextLight.h:7:10: fatal error: cusparse.h: No such file or directory 7 | #include <cusparse.h> | ^~~~~~~~~~~~ compilation terminated.

h-vetinari · 2026-01-02T02:01:21Z

+        - test -f $PREFIX/lib/libfbgemm${SHLIB_EXT}  # [unix]
+        - test -f $PREFIX/include/fbgemm/FbgemmBuild.h  # [unix]
+
+  - name: fbgemm-gpu


I suspect it might be better to use the name fbgemm for this output (though we can keep fbgemm-gpu as an alias wrapper if necessary)

That does sound like a logical answer, but fbgemm_gpu is the actual module name.

If we changed fbgemm -> libfbgemm like you suggested, it would free up the package name, but from a user standpoint, the docs clearly show 3 related but distinct pacakges:

FBGEMM

FBGEMM_GPU <--- this output package

FBGEMM_GPU_GENAI

(don't shoot me, I'm just the ~~messenger~~ maintainer)

So given this, calling this fbgemm would be confusing to users.

fbgemm_gpu_cpu is braindead naming for something CPU-only, and the rest is not much better. There's a fundamental difference between fbgemm (what I call libfbgemm), the C++ library, and fbgemm_gpu (what I want to call fbgemm), the python bindings. The upstream naming does not reflect that at all.

So given this, calling this fbgemm would be confusing to users.

I don't think so, or rather, it doesn't matter. If a user installs fbgemm (in my proposed naming), they'd get both the library that the want, as well as the python bindings (that they perhaps don't need). If that user cares about slimming down their environment, they can learn about the libfbgemm naming.

Summing up, this is what I mean. We can't stop upstream from loading a shotgun and blowing their feet off, but we don't have to follow suit on this particular aspect.

thing name upstream name conda-forge
(proposed)

library fbgemm
(not installable via PyPI) libfbgemm

python bindings
(CUDA) fbgemm-gpu fbgemm (build string cuda*)
(possible to keep upstream name as compat. wrapper)

python bindings
(CPU) fbgemm-gpu-cpu fbgemm (build string cpu*)
(possible to keep upstream name as compat. wrapper)

genAI extension fbgemm-gpu-genai fbgemm-genai
(depending on fbgemm)

CC @conda-forge/pytorch-cpu for viz.

I guess the lack of any fbgemm-gpu will ensure that users wanting that "perhaps look harder", and then perhaps we can start the description field with:

Upstream name FBGEMM_GPU

so it shows up on anaconda search pages e.g. https://anaconda.org/search?q=pytorch

Will make the change!

h-vetinari · 2026-01-02T02:03:16Z

+  - name: fbgemm-gpu-genai
+    build:
+      skip: true  # [cuda_compiler_version == "None"]
+      script: |
+        cd fbgemm_gpu
+        python setup.py --package_variant=genai --package_channel=release install --prefix=$PREFIX --single-version-externally-managed --record=record.txt


This looks problematic to me; how does the genai variant interact with the cpu/cuda variants? I would have expected this output to depend on the the previous one. Otherwise, we would have to implement pretty complex mutex rules, which is definitely not the right approach here.

See my above comment #31820 (comment), while it uses the same setup.py file it's really a whole different codebase.

I will say there's some overlap, but fbgemm-gpu and fbgemm-gpu-genai both have lots that the other doesn't.

h-vetinari · 2026-01-02T02:05:08Z

+          -DCMAKE_PREFIX_PATH=$PREFIX \
+          -DCMAKE_BUILD_TYPE=Release \
+          -DFBGEMM_LIBRARY_TYPE=shared \
+          -DASMJIT_STATIC=OFF \


Can we build this on top of #31498 (comment)? You can have several recipes per PR; if fbgemm depends on asmjit, CI here will determine the DAG and build the recipes in the correct order (so that fbgemm can depend on asmjit)

das-intensity · 2026-01-03T02:27:30Z

The cuda build timed out after 6hrs. Unfortunately I'm not surprised. It didn't take quite that long on my local machine IIRC, but my local is pretty powerful.

How can I go about debugging the pipeline machines? E.g. how can I know if it's fully pegging the CPU, such that perhaps a cmake/etc flag might help.

h-vetinari · 2026-01-03T02:43:48Z

How can I go about debugging the pipeline machines? E.g. how can I know if it's fully pegging the CPU, such that perhaps a cmake/etc flag might help.

Most effective is reducing the GPU arches for now (to a single one). We can switch to cirun once the feedstock is created.

das-intensity mentioned this pull request Jan 2, 2026

Adding asmjit #31498

Open

10 tasks

h-vetinari reviewed Jan 2, 2026

View reviewed changes

das-intensity added 5 commits January 4, 2026 12:29

Added asmjit recipe

47de7ee

Added fbgemm recipe building fbgemm, fbgemm-gpu, and fbgemm-gpu-genai

e2ae6b8

disabled osx build temporarily

c486b95

removed redundant skip py<38, submodule update, and command imports

5b89244

renamed fbgemm packages to be more clear

deda36f

das-intensity force-pushed the fbgemm branch from 8608773 to deda36f Compare January 4, 2026 20:39

restricted fbgemm arch list to speed up CI while fixing misc PR issues

aae5a8f

thing	name upstream	name conda-forge (proposed)
library	`fbgemm` (not installable via PyPI)	`libfbgemm`
python bindings (CUDA)	`fbgemm-gpu`	`fbgemm` (build string `cuda*`) (possible to keep upstream name as compat. wrapper)
python bindings (CPU)	`fbgemm-gpu-cpu`	`fbgemm` (build string `cpu*`) (possible to keep upstream name as compat. wrapper)
genAI extension	`fbgemm-gpu-genai`	`fbgemm-genai` (depending on `fbgemm`)

Uh oh!

Conversation

das-intensity commented Jan 1, 2026

Uh oh!

github-actions Bot commented Jan 1, 2026

Uh oh!

conda-forge-admin commented Jan 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

h-vetinari left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

das-intensity commented Jan 3, 2026

Uh oh!

h-vetinari commented Jan 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

conda-forge-admin commented Jan 1, 2026 •

edited

Loading

h-vetinari commented Jan 3, 2026 •

edited

Loading