[QST] Will it be merged into nvidia cutlass?

[alanzhai219]

as titled.
Do you think Nvidia will accept 3-party backends? If not, what is the next?

[Ruyk]

We are keen to contribute our work to the official NVIDIA repository and collaborate there, but seems they are not accepting third party backend at this point. If you are interested in seeing the SYCL backend in the official NVIDIA repository do reach out to them and ask about third party support.
In the meantime this repository aims to work as a drop-in replacement of the upstream one so that you can continue to use the NVIDIA backend without any changes.

[alanzhai219]

That is aligned with my expection. NV never thinks about accepting third-party backend. Their ecosystem is good enough. This repo will always follow NV's design and can not avoid diversity. It looks like another pytorch-ipex.

[Ruyk]

This repo will always follow NV's design and can not avoid diversity

Not sure what you mean by diversity. Our plan is to keep the C++ interfaces the same for CUTLASS and CUTE, and diverge only where necessary to express the hardware differences, which will be similarly to what you would expect from one generation of NVIDIA to another in terms of changes.

It looks like another pytorch-ipex.

What do you mean by another pytorch-ipex?

[alanzhai219]

@Ruyk

1. CUTLASS api and design are bound to cuda and nv gpu. It means cutlass won't consider other backend. Your fork repo will always be later than stock cutlass.
2. migration and long term maintain: If cutlass import big changes or low level design refactor, your fork repo will spend lots of time migrating to their latest version.
3. refer to pytorch-ipex. It is a project for extending stock pytorch. But it never catch up stock pytorch. Once pytorch is upgraded, it has to spend time fixing the migration bugs.

[Ruyk]

(1) There will be a lag naturally but upstream CUTLASS repository is not as big and varied as pytorch so its not hard for us to catch up
(2) Our plan is to stick to CUTE and CUTLASS C++ APIs which cannot change fundamentally without affecting existing users, so its easier to stick to (1)