Start branch for CUDA development

[danpovey]

OK, I have a proposal for how we can start moving things over to the new framework.

We can't do this by incremental changes to existing code; I think it will be easier to start from the code that's currenly in the 'cuda/' subdirectory, move those files up one level and move the existing files down one level into 'old/'. We can do all this in a separate branch, say, a branch called 'cuda'.

Then the initial task is to figure out how to compile it with nvcc, with a dependency on cub (cub is a header library). (Note: we'd plan to put all the source files through nvcc).

Of course it won't compile initially, but that's OK; at least being at the stage where we have compilation errors would be an improvement.

Note: the eventual goal would be to take all the old implementations and have them be the "CPU implementation" (i.e. the one we use by default on CPU) for those algorithms. Most algorithms won't have a GPU version, initially. But of course we'd have to change things to use the types defined in cuda/, e.g. Array1, Context, Region, and so on. I'll work on completing more of the code so it's more obvious how it's supposed to work.

[qindazhu]

I porpose that we name with cpu instead old. We may have a few folders finally: k2/csrc/cpu, k2/csrc/cuda, k2/csrc/core, k2/csrc/util, etc.

[csukuangfj]

Then the initial task is to figure out how to compile it with nvcc, with a dependency on cub (cub is a header library). (Note: we'd plan to put all the source files through nvcc).

I'd like to take care of the build system.

[danpovey]

Thanks a lot!! Mm, OK, name it cpu/, but I'm not committing to keeping that directory structure. The reason is that the algorithms I'm coding for CUDA will also work on CPU, so the distinction is not super clear. Also all the code actually has to be run through NVCC because of the way the toolkit works. But there may be too much code in 1 directory otherwise, so it may make sense to have multiple directories.

…

On Mon, Jul 27, 2020 at 1:43 PM Fangjun Kuang ***@***.***> wrote: Then the initial task is to figure out how to compile it with nvcc, with a dependency on cub (cub is a header library). (Note: we'd plan to put all the source files through nvcc). I'd like to take care of the build system. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://github.com/danpovey/k2/issues/74#issuecomment-664131831>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZFLO6RFEIQMRYYKKTTQVTR5UHYHANCNFSM4PH5EGZA> .

[csukuangfj]

@danpovey
Can we assume that CUDA is a precondition for compiling K2.

If CUDA is not available, can we throw FATAL_ERROR and abort the compilation?

[danpovey]

Yes, assume a precondition. Later on we'll look into compiling without CUDA.

…

On Mon, Jul 27, 2020 at 3:51 PM Fangjun Kuang ***@***.***> wrote: @danpovey <https://github.com/danpovey> Can we assume that CUDA is a precondition for compiling K2. If CUDA is not available, can we throw FATAL_ERROR and abort the compilation? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/danpovey/k2/issues/74#issuecomment-664181074>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZFLO2QE6DHSHLHZ2G4LNDR5UWYXANCNFSM4PH5EGZA> .