Blocked CRS SPMV

[otkmesser]

Hi,

I pushed a (to my testing) working converter from crs to blocked crs, as well as interface code
and an untested cpu SPMV for the blocked case to 0953260
I will test the actual kernel in the next days, and probably also push two naive kernel implementations.
Would be nice, if you, @DanecLacey , have a look at the interface and either fix what you dont like or simply tell me.

Greetings
Max

[DanecLacey]

I had a quick look, and it seems very nice! Thank you for your efforts.
We are finishing some small things tomorrow, and then I will have a look in more detail beginning of next week.

[otkmesser]

Hi,

I squashed and rebased my changes in 949e7b7 . From the tests Ive done, conversion as well as CPU and CUDA implementations are working correctly.
What misses are a few decisions how the actual interface should work, mainly:

1. Flag for block column major ordering of the subblocks. For now, this is build in as flag, while it probably should be an actual variable of the internal matrix struct
2. Is bcrs a SparseMatrix subtype or its own type. For now, I implemented the second variant.
3. Should the vectors be a blocked subtype or simply a "DenseMatrix" . In the last case, should the user provide the full array size or only the native row/colum size of the vector ? For now I implemented these as a DenseMatrix where the user has to provide the actual data size.
4. Should the vector and matrices support different padding sizes?

Greetings
Max

[DanecLacey]

Hi @otkmesser,
Per our discussion, lets decide on the following:

1. To restrict our focus to correctness, I would say let's leave this as a flag for now. We can of course "row vs. column" ordering as an API call argument once everything seems to be working well.
2. Like we discussed, I'll fold your work into the SpMV kernel as a matrix format variant.
3. It would be interesting to experiment with this! For now, let's leave it as a DenseMatrix and see what the compiler does.
4. For BCRS, it is my understanding that we just assume the blocks are padded to a divisor of n_rows. Since we do not pad the matrix as of now, what do you mean?

BR,
Dane

[otkmesser]

Regarding 4.:
I have added padding for the actual subblocks, i.e. if you want a 3x3 subblock, can be extended to 4x4, or 4x3 or 3x4 with padded data or in other words, the k-th block entry does not start at (3*3)ksizeof(double) but at (pad_h * pad_w) * k *sizeof(double) .
This might be relevant if you want to force a specific aligment for the start of the subblocks, at least I wanted to experiment with this a bit for the case GPUs.