cuBLAS gemv incx != 0 restriction

What’s the reason behind the restriction incx != 0 in cublas*gemv functions?

It’s obvious that output vectors must have inc* != 0 (e.g. incy in cublas*axpy functions). But for input vectors incx == 0 can be used for passing vectors with constant values without array allocation.

And, for instance, we can use cublas*gemv to calculate sum of matrix rows/columns.

And it’s not obvious what lead to such restrictions, because code like x + i * incx is gonna work anyway. May be these restrictions can be lifted without changes in the kernel code?

You might wish to express your desires by filing a bug.

Where are you seeing this restriction?

Under cublasXdgmm, Example 2: if the user wants to perform α × A , then there are two choices, either cublasgeam with *beta=0 and transa == CUBLAS_OP_N or cublasdgmm with incx=0 and x[0]=alpha.

Please provide an example of what you’d like to do, but can’t.

My bad. I mixed up the functions. dgmm can’t be used to calculate sum of matrix rows/columns. I was talking about gemv (I’ve also fixed the first post). incx==0 in cublas*gemv leads to CUBLAS_STATUS_INVALID_VALUE.

We follow the netlib definition of gemv, which also explicitly states that inc{x,y} cannot be 0:

On entry, INCX specifies the increment for the elements of
X. INCX must not be zero.

On entry, INCY specifies the increment for the elements of
Y. INCY must not be zero.

1 Like

Got it.

I was curious, because I thought like ‘How this function can be implemented in a way, where incx==0 will lead to errors?’.

Now I see that it’s more like ‘this restriction is derived from standard BLAS implementation’. Thanks!