Move CUDA Low Level API to other namespace

The cupy.cuda namespace is confusing.

1. cupy.cuda is not in NumPy
2. Mixing Low Level API and CuPy original wrapper

Especially solving the second problem simplifies CuPy development. (The first problem is a bit difficult because it requires design discussion.)

The implementation of some features on CuPy does not provide CUDA’s Low Level API. Therefore, I think it is better to start with partial separation first.

With this change, CuPy may be able to provide Cython CUDA API in the future #130.

[okuta]

The cupy.cuda namespace is confusing.

1. cupy.cuda is not in NumPy
2. Mixing Low Level API and CuPy original wrapper

These were the problems I wanted to solve. However, I gave up moving the whole cupy.cuda because cupy.cuda has a dependency on cupy.core.ndarray. A circular reference exists when cupy.cuda is moved to another namespace (e.g., cupy_XXXX).

Therefore, I introduced cupy_backends.cuda.api and backends.cuda.libs. I moved low-level CUDA API wrappers. The problem of the Stream was avoided by introducing a flag.

cupy_backends.cuda is a useful namespace. Wouldn’t it be a good idea to cut out features that could be used in other libraries? #3584 is an example implementation of this.

I think it’s good to put the following items in cupy_backends.cuda.

• An object with a life cycle. It hides the create-destroy method call. For example, Stream/Event/Memory etc.
• Thin Pythonic wrappers. Like this. For example, compiler/profiler etc.

I’d like to get your opinion. I’m going to make a different issue because it’s not on the same topic as the original.

[okuta]

I agree with you.

We are currently experiencing a dependency from a Stream issue. A Stream dependency now exists. I will send a PR that resolve it.