[CUSOLVER] Add a structure CuSolverParameters fro the generic API

[amontoison]

@maleadt I'm wondering if we should provide the new structure CuSolverParameters as a keyword argument such that the users can provide different parameters if they want.
We can only use the default parameters with the current implementation.

function Xpotrf!(uplo::Char, A::StridedCuMatrix{T}; parameters::CuSolverParameters=CuSolverParameters()) where {T <: BlasFloat}
  ...
end

What do you think?

[maleadt]

I'm wondering if we should provide the new structure CuSolverParameters as a keyword argument such that the users can provide different parameters if they want.

Do these parameters apply to multiple CUSOLVER calls? If it's more like the CUBLAS math mode, we may want to do something task-local instead (or using dynamically scoped values at some later point).

[amontoison]

Multiple CUSOLVER routines are concerned by this parameter structure but it's not like the CUBLAS math mode because each CUSOLVER routine requires it as an argument.
The parameters also depend on the CUSOLVER routine:

• https://github.com/JuliaGPU/CUDA.jl/blob/master/lib/cusolver/libcusolver.jl#L51-L54

What is very similar to the CUBLAS math mode in CUSOLVER is the deterministic mode:

• https://github.com/JuliaGPU/CUDA.jl/blob/master/lib/cusolver/libcusolver.jl#L56-L59
• https://github.com/JuliaGPU/CUDA.jl/blob/master/lib/cusolver/libcusolver.jl#L194-L198

[maleadt]

each CUSOLVER routine requires it as an argument

That doesn't matter; the wrappers could query the task-local value and pass it to every API, just like we pass stream(). If it's a single or unified parameter that's used across APIs though, I think it's better to store it globally instead of having to pass it to every CUSOLVER.jl function.

[amontoison]

@maleadt I think that we can merge the PR like this for now.