KA kernel for add_transform for Abelian symmetries

[kshyatt]

Split off the simpler Abelian component from #509. I've kept the device cache logic for now as it should still apply in this case (if I remember 3 weeks ago correctly...)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

Files with missing lines	Coverage Δ
ext/TensorKitGPUArraysExt.jl	93.68% <100.00%> (+4.59%)	⬆️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[lkdvos]

Update here: I'm trying to work out a way to make the whole TreeTransformer that ends up being cached also depend on the storagetype. This has the added benefit that we can store complex unitaries for complex tensors, therefore enabling this to go through BLAS, while also having the ability to return custom types for host vs device implementations. I'm hoping this will make this PR consist only of the actual kernel implementation

[lkdvos]

question because I'm just trying to understand:

I got somewhat confused by the dense_strides, since I don't think we can guarantee the data is actually laid out in dense-stride-form, but after looking at this a bit more, am I correct that the idea is that you are creating an additional set of linear indices that are related to the GPU workers/threads, and then mapping that to both source and destination data linear indices?
In other words, there are 3 sets of 1:nwork, the first is the data index of the src, the second is the data index of the dst, and then the index of the worker?

It seems like it would be nice to be able to map the worker index to the dst index, so we can guarantee contiguous writes for the workers, but I do agree that it is not obvious how that mapping would work (and if it is even possible to do that efficiently).

Anyways, this is less of a comment about having to change implementation and more just me double-checking I understood this correctly

[kshyatt]

I got somewhat confused by the dense_strides, since I don't think we can guarantee the data is actually laid out in dense-stride-form, but after looking at this a bit more, am I correct that the idea is that you are creating an additional set of linear indices that are related to the GPU workers/threads, and then mapping that to both source and destination data linear indices?
In other words, there are 3 sets of 1:nwork, the first is the data index of the src, the second is the data index of the dst, and then the index of the worker?

Yes, that's the idea.

[kshyatt]

Going to bypass the heckin slow ROCm queue here