cuBLAS new API syntax

Accelerated Computing HPC Compilers Legacy PGI Compilers
1

Hi All,

Would it be possible to update the syntax for the new cuBLAS API within CUDA FORTRAN to conform more closely to that of CUDA C as given in the CUDA Toolkit Documentation cuBLAS :: CUDA Toolkit Documentation? Changes might include:

  1. Using a module called cublas_v2 rather than using the current cublas module for both the legacy and new APIs. This would allow (for example) istat=cublasgemm() to be used rather than istat=cublasgemm_v2() (I know that cublas_v2.h just defines cublasgemm() as cublasgemm_v2 and that they’re the same thing, but I think it would be nicer and easier if the CUDA FORTRAN syntax matched the CUDA C syntax).

  2. Suffix cuBLAS datatypes (such as cublasHandle) in the cublas_v2 module with _t (cublasHandle_t). Again, I know this doesn’t add functionality, but I feel like it might improve usability.

All the best,
Kyle

2

bump…

3

Hi Kyle,

I got Greg’s input on this. He doesn’t think this would help much since wouldn’t introduce any new functionality and would break peoples existing code.

“Cublas is heavily overloaded already, as you can call sgemm(), cublasSgemm(), or cublasSgemm_v2(). Anyone can add on their own preferences and write a generic interface to do what they want to do.”

As for #2, this is pretty common when interfacing C and Fortran, and stems from how the instances of types/structs are declared:

C:
cudaEvent_t myEvent;

Fortran:
type(cudaEvent) :: myEvent

The “type()” in Fortran takes on the role of “_t” in C. Having both would be redundant in some sense. All of the data types in cudafor do not have the “_t”, i.e. cudaEvent, cudaDeviceProp. This naming scheme is consistent with that.

Best Regards,
Mat

4

Hey Mat,

Thanks for the response and thanks for clearing up why “_t” wouldn’t be appropriate.

Regards,
Kyle