fix setup build error when setuptools version is lower - #36
Merged
Merged
Conversation
LyricZhao
added a commit
that referenced
this pull request
Apr 16, 2026
* Use std::filesystem::directory_iterator instead of std::filesystem::recursive_directory_iterator to avoid an ABI breakage we met (#131) * Code lint --------- Co-authored-by: Chenggang Zhao <chenggangz@deepseek.com>
qiushixiaoyu
added a commit
to qiushixiaoyu/DeepGEMM
that referenced
this pull request
Jun 22, 2026
Co-authored-by: yinding <yinding@bytedance.com>
qiushixiaoyu
added a commit
to qiushixiaoyu/DeepGEMM
that referenced
this pull request
Jun 30, 2026
Co-authored-by: yinding <yinding@bytedance.com>
lengrongfu
added a commit
to lengrongfu/DeepGEMM
that referenced
this pull request
Aug 31, 2026
Ports upstream PR sgl-project#36 ("Sm90 mega moe on sgl dev"), which added a Hopper FP8xFP8 fused MoE GEMM kernel on the old `dev` branch layout (tvm_ffi_api.cpp / sgl_deep_gemm), onto nv_dev's current layout (csrc/apis/*.hpp, csrc/python_api.cpp, deep_gemm/mega). nv_dev already had MegaMoE, but only for SM100 (Blackwell), built on a ring-buffer / cluster-pair-interleaved persistent-grid scheduler and a UE8M0/FP4-oriented workspace layout. The SM90 kernel in PR deepseek-ai#36 instead uses a simpler pool-based workspace and per-expert-wave scheduler with float (non-UE8M0) scale factors, FP8-only weights (no FP4), and no 2-CTA clusters or shared-expert support -- these are not compatible data layouts, so the SM90 path is added as a fully parallel path alongside (not replacing) the SM100 one. New files (ported from the PR's `.cuh`/`.hpp`, adapted to nv_dev's current naming/dispatch conventions and symbol-renamed to avoid colliding with SM100's `layout::Workspace` / `sched::MegaMoEScheduler` / `sched::BlockPhase`): - deep_gemm/include/deep_gemm/layout/sm90_mega_moe.cuh (`layout::MegaMoESM90Workspace`, pool-based; reuses the existing shared `layout::Data`/`layout::Buffer`/`layout::TokenSrcMetadata` and `layout::get_num_max_pool_tokens` from layout/mega_moe.cuh) - deep_gemm/include/deep_gemm/scheduler/sm90_mega_moe.cuh (`sched::MegaMoESM90Scheduler` / `sched::MegaMoESM90BlockPhase`) - deep_gemm/include/deep_gemm/impls/sm90_fp8_mega_moe.cuh (the ported kernel, ~1935 lines, WGMMA/TMA-based Hopper impl) - csrc/jit_kernels/heuristics/sm90_mega_moe.hpp (`MegaMoESM90Config` and block/pipeline/wave heuristics, mirroring csrc/jit_kernels/heuristics/mega_moe.hpp's structure) - csrc/jit_kernels/impls/sm90_fp8_mega_moe.hpp (JIT host runtime, mirroring csrc/jit_kernels/impls/sm100_fp8_fp4_mega_moe.hpp) - tests/test_mega_moe_hopper.py (correctness test with an SM90 capability guard; skips cleanly on non-Hopper GPUs) Modified files: - csrc/apis/mega.hpp: adds `get_symm_buffer_size_for_sm90_mega_moe` and `fp8_mega_moe_sm90`, registered via the existing `deep_gemm::mega::register_apis` (already wired into csrc/python_api.cpp, so no python_api.cpp changes were needed). - deep_gemm/mega/__init__.py + deep_gemm/__init__.py: expose `Sm90SymmBuffer`, `get_symm_buffer_for_sm90_mega_moe`, `transform_weights_for_mega_moe_sm90`, `fp8_mega_moe_sm90`, following the existing SM100 exposure pattern. - deep_gemm/include/deep_gemm/comm/barrier.cuh: generalizes `grid_sync`/`nvlink_barrier` to a templated workspace type (instead of hard-coding `layout::Workspace`) so the SM90 kernel can reuse them with `layout::MegaMoESM90Workspace`; existing SM100 call sites are unaffected (the type is still deduced from the argument). Also ports the PR's ARCH 900-1000 guarded trap-instead -of-printf change to the NVLink barrier timeout path. Not ported: shared-expert support and the `situ` activation (the PR does not implement either for SM90). No GPU/CUDA toolchain is available in this environment, so this is a best-effort, close-reading port verified via `python3 -m py_compile`, brace/paren balance checks on all new/modified C++/CUDA files, and confirming `import deep_gemm` fails identically (missing compiled `_C` extension) before and after these changes -- i.e. no regression introduced. It has not been compiled or run on real Hopper hardware. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
qiushixiaoyu
added a commit
to qiushixiaoyu/DeepGEMM
that referenced
this pull request
Sep 4, 2026
Co-authored-by: yinding <yinding@bytedance.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When setuptools==59.6.0,
include/deep_gemm/**/*, It will not copy .cuh file from the include directory。If use new version, such as 75.8.2, it work ok。
I suggest use
include/deep_gemm/*, will have better compatibility.