Skip to content

[Common] Optimized kernels for swizzling and remove obsolete narrow scaled kernels - #3682

Open
vthumbe1503 wants to merge 1 commit into
NVIDIA:mainfrom
vthumbe1503:swizzle-per-tile-default
Open

vthumbe1503 wants to merge 1 commit into
NVIDIA:mainfrom
vthumbe1503:swizzle-per-tile-default

Conversation

@vthumbe1503

@vthumbe1503 vthumbe1503 commented Oct 13, 2026 •

Copy link
Copy Markdown
Collaborator

Description

This PR introduced rowwise/colwise swizzling kernels targeted at narrow scale width use-cases. The scope of this PR is to

  • Colwise Swizzling: Enable the colwise swizzling optimized kernel(swizzle_columnwise_chunk_kernel) for both narrow scale-width and wide scale-width use-cases. And completely removes the previously existing kernel for narrow scale width kernel. The previously existing kernel for wide scale-width is retained since that is still used for grouped swizzling. Using the kernel in grouped swizzling will be a follow up PR.
  • Rowwise swizzling: Enable rowwise swizzling optimized kernel(swizzle_rowwise_full_width_kernel) for narrow scale-width use-cases. For wide scale-width, we fall back to our previosuly existing rowwise scaling kernel which operates on 128128N tile where N is vectorization's bit width. Fall back is implemented through shared memory heuristics
    • If scale is sufficiently narrow (smem ~= 128*padded_k <= 17KB), new kernel is better
    • If smem is between (17,30)KB then using the new kernel turns out to be better if the number of row tiles is between 16 and 256.
  • Optimized row scaling kernel is also extended to be use for NVFP4.
    • Apt unit tests are also added

Blackwell Perf results

MXFP8 rowwise

ShapeBefore (µs)After (µs)Speedup
4096×153613.5761.7297.852×
4096×5124.4131.2473.538×
4096×1282.1111.1831.784×
4096×20482.0491.5051.362×
4096×40962.5512.1301.198×
2048×71683.0332.8861.051×
4096×71683.5193.5171.001×

MXFP8 columnwise

ShapeBefore (µs)After (µs)Speedup
4096×153613.7361.6018.580×
4096×5125.5481.6003.467×
4096×20485.1141.6313.135×
4224×20484.9901.6313.059×
4096×71685.3702.4272.213×
7168×40965.2882.4312.175×
2048×71683.4221.6652.055×

MXFP8 multi-tensor rowwise

ShapeNBefore (µs)After (µs)Speedup
7168×409688.3884.4281.894×
4096×204884.8462.5891.872×
4096×12842.4971.4711.697×
16384×12842.4651.4731.673×
256×25642.0791.3771.510×
2048×7168157.2136.1621.171×
4096×716887.1076.0851.168×

MXFP8 multi-tensor columnwise

ShapeNBefore (µs)After (µs)Speedup
4096×204885.9893.1591.896×
4224×2048207.7214.8391.596×
1024×71683210.7777.4191.453×
4224×2048136.1674.5201.364×
4096×716886.5475.1901.262×
7168×409686.5615.8041.130×

Rubin perf results

MXFP8 rowwise

ShapeBefore (µs)After (µs)Speedup
4096×153611.4331.6157.077×
4096×5123.3401.1812.827×
4096×1281.6051.1561.388×
4096×20481.8841.3691.376×
4096×40962.3102.0371.134×
2048×71682.6812.4821.080×
4096×71683.1483.1481.000×

MXFP8 columnwise

ShapeBefore (µs)After (µs)Speedup
4096×153610.3141.4956.900×
4096×20484.4431.5162.931×
4096×5124.2461.4822.864×
4224×20484.3551.5162.873×
4096×71684.8182.2392.152×
7168×40964.7002.2332.105×
2048×71683.0461.5811.926×

MXFP8 multi-tensor rowwise

ShapeNBefore (µs)After (µs)Speedup
7168×409687.0633.7731.872×
4096×204884.3022.4111.784×
4096×12842.1701.3711.583×
16384×12842.1441.4341.495×
256×25641.7691.3601.300×
4096×716886.1745.5291.117×
2048×7168156.2015.5591.115×

MXFP8 multi-tensor columnwise

ShapeNBefore (µs)After (µs)Speedup
4096×204885.5252.7312.023×
4224×2048207.8354.6091.700×
4224×2048135.3493.5721.498×
4096×716885.7044.2941.328×
1024×7168328.7246.6891.304×
7168×409685.6654.8371.171×
One note on the perf of the rowwise scaling kernel 4096 * 1536 has much better speed up compared to 4096*2048: This is because narrow width kernel is chosen up until about 1536 columns. After that limit the generic kernel is used. Generic kernel parallelizes decently well but still not better than the newly introduced kernel at 2048 width. Hence 2048 has a lesser speedup relative to baseline Fixes # (issue)

Type of change

  • Documentation change (change only to the documentation, either a fix or a new content)
  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Infra/Build change
  • Code refactoring

Changes

Please list the changes introduced in this PR:

  • Change B

Checklist:

  • I have read and followed the contributing guidelines
  • The functionality is complete
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes

@vthumbe1503 vthumbe1503 changed the title [Pytorch][Common] Get rid of Narrow width Swizzle kernels for the newly optimized kernels [Common] Get rid of Narrow width Swizzle kernels for the newly optimized kernels Oct 13, 2026
@vthumbe1503 vthumbe1503 changed the title [Common] Get rid of Narrow width Swizzle kernels for the newly optimized kernels [Common] Optimized kernels for Narrow width row scaled swizzling and columnwise swizzling Oct 14, 2026
@vthumbe1503 vthumbe1503 changed the title [Common] Optimized kernels for Narrow width row scaled swizzling and columnwise swizzling [Common] Optimized kernels for swizzling and remove obsolete narrow scaled kernels Oct 14, 2026
@vthumbe1503
vthumbe1503 marked this pull request as ready for review October 14, 2026 06:19
@vthumbe1503

Copy link
Copy Markdown
Collaborator Author

/te-ci

@greptile-apps

greptile-apps Bot commented Oct 14, 2026 •

Copy link
Copy Markdown
Contributor

RetriggerView in GreptileConfidence Score: 5/5

[Medium impact] The PR appears safe to merge; no outstanding actionable findings remain.

Summary

The PR enables optimized scale-swizzling kernels and removes obsolete narrow-width kernels.

  • Scale swizzling now chooses optimized kernels from the workload.
  • Batched swizzling now uses optimized paths for MXFP8 and NVFP4.
  • Swizzle calls now require 16-byte-aligned scale buffers.

No new actionable issues were found. CUDA tests were not run.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Check tensors and alignment] --> B{Scale layout}
  B -->|Columnwise MXFP8| C[Columnwise chunk kernel]
  B -->|Rowwise or NVFP4| D{Width and tile count}
  D -->|Fits heuristic| E[Rowwise full-width kernel]
  D -->|Otherwise| F[Generic rowwise kernel]
Loading

Reviews (6) · Last reviewed commit: "Optimize scale swizzle kernels" · Reviewed by Greptile

Comment thread transformer_engine/common/swizzle/swizzle.cu Outdated
Comment thread tests/cpp/operator/test_swizzle.cu
@ptrendx

ptrendx commented Oct 16, 2026

Copy link
Copy Markdown
Member

@vthumbe1503 Please sign every commit in this PR. See https://github.com/NVIDIA/TransformerEngine/blob/main/CONTRIBUTING.rst#sign-your-work

@vthumbe1503
vthumbe1503 force-pushed the swizzle-per-tile-default branch from 12213fd to 540f974 Compare October 16, 2026 21:50
@vthumbe1503
vthumbe1503 requested a review from ptrendx October 16, 2026 21:55
Comment thread transformer_engine/common/swizzle/swizzle.cu Outdated
@vthumbe1503

Copy link
Copy Markdown
Collaborator Author

/te-ci L0

@vthumbe1503
vthumbe1503 force-pushed the swizzle-per-tile-default branch from e5fe40f to d586c99 Compare October 23, 2026 16:19
Comment thread transformer_engine/common/swizzle/swizzle.cu Outdated
Use per-tile swizzle kernels for small MXFP8 scale tensors and multi-tensor cases. Require 16-byte alignment for every present input and output scale buffer, including buffers unused by a mixed batch.

Signed-off-by: Varun Thumbe <vthumbe@nvidia.com>
@vthumbe1503
vthumbe1503 force-pushed the swizzle-per-tile-default branch from 0391c75 to a7fd8fb Compare October 23, 2026 17:28

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants