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:

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

INCY is INTEGER
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!