I'm getting back into trying out the Magma library (been about a month now) and am having some confusion with sgemm. In general, I'm trying to write an example similar to the one in the example directory in the original distribution where there is a CPU interface and a GPU interface (to zgesv).
My basic code for the cpu_interface is:
1. malloc host spaces via magma_smalloc_cpu()
2. fill inputs via sfill_matrix() - copied from example zfill.c file
3. magma_sgemm() - input and output array spaces from step 1.
4. Clean up via magma_free_cpu
My basic code for the gpu_interface is:
1. malloc GPU space via magma_smalloc()
2. fill inputs via sfill_matrix_gpu - copied from example zfill.c file
3. magma_sgemm() - input and output array spaces from step 1.
4. Clean up via magma_free()
This leaves me with a couple of questions to start with:
1. Where does the code executing magma_sgemm() run for both the CPU and GPU interfaces?
2. If I replace a call to magma_sgemm with magmablas_sgemm(), what is supposed to happen?
I have other questions, but maybe the answers to the first two above will lift enough fog to help out.
sgemm confusion
Re: sgemm confusion
There is no CPU interface for magma_sgemm. The data must be allocated on the GPU. It executes a kernel on the GPU.
magma_sgemm is a wrapper around cublasSgemm.
magmablas_sgemm is our own implementation, circa 2010. The cublas implementation has incorporated our code, plus added newer optimizations for the Kepler architecture, so it is preferred now. We do not use magmablas_sgemm anymore. However, we still find it valuable to have an open-source implementation of gemm available.
-mark
magma_sgemm is a wrapper around cublasSgemm.
magmablas_sgemm is our own implementation, circa 2010. The cublas implementation has incorporated our code, plus added newer optimizations for the Kepler architecture, so it is preferred now. We do not use magmablas_sgemm anymore. However, we still find it valuable to have an open-source implementation of gemm available.
-mark