Request for branches in repo

[bdbowyer]

I would like to have TritonBench branches that match Triton branches so I can generate baseline profile data with previous releases. Ideally with the same naming convention: "release/3.3.x", "release/3.4.x".

It should be OK to branch from the head of main for the release branches. Only one small patch is needed for release 3.3.x, at least as far as I can tell. The latest version of TritonBench includes triton.tools.tensor_descriptor, which was added in Triton 3.4.x. Running with Triton 3.3.x requires a guard in warp_spec_persistent_matmul.py.

[FindHao]

@xuzhao9 @adamomainz We also discussed this issue today. This kind of issue also causes the internal build failures. IMO, we better to have a middle layer like triton.compact or tritonbench.compact to manage those API changes. @njriasan has experience on adding this middle layer.

What do you guys think?

[adamomainz]

I think compact might be too complex here? is the ask really just to freeze the code in the repo at specific versions when we doo a pin update?

Think it would make sense to create a new branch when we change pin but make sure we keep the main branch here as latest. We can just branch right before making the new pin update change. This way we get the best version of every kernel that works with a given version and can move on and iterate on the next. Would also mean we should definitely lock down those branches with branch protections too just so we keep them frozen.

[xuzhao9]

@FindHao I don't think we need to build that middle layer, it will be very costy to maintain them.

Instead, we may want to freeze this branch, and limit this branch to run only custom Triton kernels, that is to say, clearly indicate that CUTLASS, CK, or PT2-Triton kernels are not supported.

If so, branching with Triton version sounds good to me, but we will not have bandwidth to maintain it or run CIs.