Repository navigation
adds a device array type for CuSparseMatrixCSR to support using it in kernel functions - #1106
Conversation
|
umm, not sure what did I break here... anyone might know? |
Codecov Report
@@ Coverage Diff @@
## master #1106 +/- ##
=======================================
Coverage 79.46% 79.47%
=======================================
Files 118 118
Lines 7919 7925 +6
=======================================
+ Hits 6293 6298 +5
- Misses 1626 1627 +1
Continue to review full report at Codecov.
|
|
Nice! Does the existing indexing function just work, or how do you want to use this type on device? Typically I put device-side implementations in And you didn't break anything, if you push a newer commit Buildkite is currently configured to cancel previous builds. |
I mainly just want to make it work when the kernel argument is a function thread_layout(H)
if size(H, 2) < 256
threads = size(H, 2)
nblocks = 1
else
threads = 256
nblocks = ceil(Int, size(H, 2) / 256)
end
return threads, nblocks
end
function update_term_kernel(H, t, subspace_v)
row = (blockIdx().x - 1) * blockDim().x + threadIdx().x
if row > length(H.rowPtr) - 1
return
end
@inbounds for k in H.rowPtr[row]:H.rowPtr[row+1]-1
col = H.colVal[k]
lhs = subspace_v[col]
rhs = subspace_v[row]
H.nzVal[k] = RydbergEmulator.term_value(t, lhs, rhs, col, row)
end
return
end
function RydbergEmulator.update_term!(H::CuSparseMatrixCSR, t::AbstractTerm, subspace_v::CuVector)
LinearAlgebra.checksquare(H) == length(subspace_v) || error("given matrix size does not match subspace size")
threads, nblocks = thread_layout(H)
@cuda threads=threads blocks=nblocks update_term_kernel(H, t, subspace_v)
return H
endbecause so I think I will need to let |
|
ah it seems the test file is added automatically, this test suite tool in CUDA looks quite nice! is there a package for this already? mind me stealing this feature to a package? |
It's quite annoying to figure a good API to extract this into a package, so I didn't bother. Feel free to take the code, it's based on Base's
Ah OK, so you're manually using the internal fields. We should probably add a note/TODO then explaining that the type currently doesn't have any user-facing functionality implemented, in case people expect to be able to pass this to a kernel and use |
OK, yeah, I'm not sure about the APIs for kernel programming regarding to the CSC/CSR struct, in my case I mainly want to use the internal fields directly to make an efficient implementation, and manually using 3 array pointers seems annoying. I think I'll add some docstring too. |
|
actually I'm not sure where should I add the note/TODO, maybe I should put them in the documentation? |
- Add Ti typevar for full generality - Decouple from CUSPARSE: Don't inherit from CUSPARSE abstract types - Move adapt implementation to CUSPARSE to reshuffle includes.
a2d3df3 to
79fc651
Compare
|
I pushed some changes (mostly decoupling from CUSPARSE, we want the generic implementation to be really generic) & clean-ups (e.g. don't use cudaconvert but use adapt). Should be good to go if this suits your needs, but ultimately we'd want some GPU-compatible device functionality too. |
|
Ah thanks! Yeah this looks good to me! I think I can use the CSR directly now. Would this appear in a patch release soon? |
|
This is pretty much a feature, and I wasn't planning on creating a new minor release just yet (it's been only a week). You can't use the |
|
Yeah I was going to depend on a new version in another package but it's not in a hurry. So no problem then. I'll just use the master branch for now |
this adds a device array to support using
CuSparseMatrixCSRin a kernel function, not sure if this is the right place to put it? (I created adevice.jlfile)I guess for other sparse matrix types they would need a similar thing too.