Hello:
Attached I send a simple testing program for magmablas_dswap. I think that the function has several bugs.
First of all, if I try to use magmablas_dswap with increments equals zero or positive in vector x and y, tha result is that the vector x is copied into y but y is not changed to x, so the result is x in x and x in y.
Second, if I try to operate with increments equals 1, an error CUBLAS_STATUS_MAPPING_ERROR occurs (code error 11 in cublas_api.h).
This tests can be done in the attached file changing the value of the variable 'incCalc' in order to try differents increments (1, 0, 1)
Cheers
PS: I'm using CUDA 4.1 and gcc 4.6.3 from Debian Sid
Possible bug in magmablas_dswap [MAGMA 1.1.0 and 1.2*]
Possible bug in magmablas_dswap [MAGMA 1.1.0 and 1.2*]
 Attachments

 test_dswap.c
 Simple magmablas_dswap test
gcc test_dswap.c o test_dswap lmagma lmagmablas lmagma lopenblas lcuda lcublas llapack  (2.43 KiB) Downloaded 179 times
Last edited by jgpallero on Tue Jul 17, 2012 7:51 am, edited 1 time in total.
Re: Possible bug in magmablas_dswap [MAGMA 1.1.0 and 1.2*]
Hello again:
The reported bug in magmablas_dswap is presented in magma 1.2.1 too
Cheers
The reported bug in magmablas_dswap is presented in magma 1.2.1 too
Cheers

 Posts: 263
 Joined: Fri Aug 21, 2009 10:39 pm
Re: Possible bug in magmablas_dswap [MAGMA 1.1.0 and 1.2*]
Hello,
I think the bug is actually in the example file, in particular, you have used expressions like sizeof(x1), which in your case is 32 (4 doubles), instead of sizeof(x[0]) or just sizeof(double).
Stan
I think the bug is actually in the example file, in particular, you have used expressions like sizeof(x1), which in your case is 32 (4 doubles), instead of sizeof(x[0]) or just sizeof(double).
Stan
Re: Possible bug in magmablas_dswap [MAGMA 1.1.0 and 1.2*]
You are right (partially). I have changed the sizeof calls to sizeof(double), but I have two problems.Stan Tomov wrote:Hello,
I think the bug is actually in the example file, in particular, you have used expressions like sizeof(x1), which in your case is 32 (4 doubles), instead of sizeof(x[0]) or just sizeof(double).
Stan
1 When the increment between the elements of the vectors is 0, the reference BLAS does no computations, so the output vectors are the same than the input ones. But MAGMA swaps the two first elements x[0] and y[0] and does no operations with the remaining. I think that the behavior should be the same as in reference BLAS for increments equals 0, so I think that this is a bug in MAGMA
2 When the increments are 1 I obtain an cublasGetVector error, status=11. I think that all the code is correct and I suspect a bug too.
Attached I send the new fixed test_dswap.c code (only the incCalc=*; line is need to change)
Cheers
 Attachments

 test_dswap.c
 gcc test_dswap.c o test_dswap lmagmablas lmagma lopenblas lcuda lcublas llapack
 (2.52 KiB) Downloaded 137 times
Re: Possible bug in magmablas_dswap [MAGMA 1.1.0 and 1.2*]
incx = 0 is an error condition; you are not passing a vector. Most of the BLAS routines such as DGEMV explicitly state that INCX must not be zero. The CPU implementation actually DOES swaps of the first element, but for even n, it does an even number of swaps, so the end result is the same. Try with n=3 to see that the first element is swapped. Nonetheless, the user should not call dswap with incx=0 or incy=0.
I agree that negative increments are not handled by the current MAGMA BLAS dswap code.
Note that the cublasDswap routine works correctly for negative increments, so I recommend using that one. (The MAGMA BLAS dswap routine probably dates from a time before CUBLAS was fully implemented.)
mark
I agree that negative increments are not handled by the current MAGMA BLAS dswap code.
Note that the cublasDswap routine works correctly for negative increments, so I recommend using that one. (The MAGMA BLAS dswap routine probably dates from a time before CUBLAS was fully implemented.)
mark
Re: Possible bug in magmablas_dswap [MAGMA 1.1.0 and 1.2*]
But in my tests with magma_dswap() the first element is always interchanged, with N odd or even. Although incX and incY are wrong values I think that reproduce the same results as the reference netlib BLAS is a good featuremgates3 wrote:incx = 0 is an error condition; you are not passing a vector. Most of the BLAS routines such as DGEMV explicitly state that INCX must not be zero. The CPU implementation actually DOES swaps of the first element, but for even n, it does an even number of swaps, so the end result is the same. Try with n=3 to see that the first element is swapped. Nonetheless, the user should not call dswap with incx=0 or incy=0.