Move common member into base and modify launch function

[cameronshinn]

I made a few changes

1. Move common members into the launch_param_base_t class (shared_memory_bytes).
2. Remove context as a member and instead use it as an argument of the launch function. This makes sense because we might want to use multiple contexts with the same launch box, and rather that re-instantiating a new launch box for each context, we can use the same object.
3. Changed the launch function to use a tuple of args rather than a variadic pack of args. This design choice is based around my expectation that most kernels will have a lot of arguments, and it will look cleaner if they are wrapped into a tuple. If this wasn't for launching cuda kernels I would have been able to use std::apply in C++17, but I had to reimplement it to be able to use the chevrons <<<>>>.

The only issue I have still that I'd like to discuss here is how to efficiently declare the launch functions. Currently across the two types of launch boxes the functions are exact copies from one another. The only difference between the classes is that the functions reference member types that are declared in those classes, so they cannot easily be moved into the shared parent class.

[neoblizz]

3. Changed the launch function to use a tuple of args rather than a variadic pack of args. This design choice is based around my expectation that most kernels will have a lot of arguments, and it will look cleaner if they are wrapped into a tuple. If this wasn't for launching cuda kernels I would have been able to use std::apply in C++17, but I had to reimplement it to be able to use the chevrons <<<>>>.

This is cool, I like std::apply, I am just wondering what is the benefit of the tuple versus direct forwarding the arguments? Isn't it less code if I just forward it?

[cameronshinn]

3. Changed the launch function to use a tuple of args rather than a variadic pack of args. This design choice is based around my expectation that most kernels will have a lot of arguments, and it will look cleaner if they are wrapped into a tuple. If this wasn't for launching cuda kernels I would have been able to use std::apply in C++17, but I had to reimplement it to be able to use the chevrons <<<>>>.

This is cool, I like std::apply, I am just wondering what is the benefit of the tuple versus direct forwarding the arguments? Isn't it less code if I just forward it?

Yes it is a bit less code from the user perspective when you just forward it directly, but since I was adding the context argument I thought it would make it clearer which args are for the actual kernel in the case where there are a bunch of them.

[neoblizz]

3. Changed the launch function to use a tuple of args rather than a variadic pack of args. This design choice is based around my expectation that most kernels will have a lot of arguments, and it will look cleaner if they are wrapped into a tuple. If this wasn't for launching cuda kernels I would have been able to use std::apply in C++17, but I had to reimplement it to be able to use the chevrons <<<>>>.

This is cool, I like std::apply, I am just wondering what is the benefit of the tuple versus direct forwarding the arguments? Isn't it less code if I just forward it?

Yes it is a bit less code from the user perspective when you just forward it directly, but since I was adding the context argument I thought it would make it clearer which args are for the actual kernel in the case where there are a bunch of them.

Ok, I'll try it out.