@CoreRasurae I dont think so, you need an account on our gitlab instance is all but not permission I dont think: https://git.qoto.org
@CoreRasurae the reason for th emove to gitlab is mostly for the CI since i can run GPU enabled runners for CI. Something that last i checked travis doesnt offer. Plus I like the gitlab CI system overall and many other features.
no problem
too
yup, it and all the other projects are int he Aparapi group: https://git.qoto.org/aparapi?nav_source=navbar
@freemo tomorrow will add the fix in aparapi-native
@freemo Only Aparapi-Native has code modification to fix the issue and a small refactoring with no functionality change
@freemo It is simply something that is really unsupported in Aparapi
@freemo To have multi-dimensional arrays where inner arrays dimensions vary with the index of the outer dimension
@freemo Well if you want to, but I think it something that doesn't make sense, it is simply inefficient in terms of memory accesses, to which GPUs are quite sensitive, and multi-dimensional arrays are already inefficient because OpenCL 1.x can only deal with 1D arrays, so that Aparapi needs to convert them forth and back at each kernel execution.
@freemo It is something unusual to have an array like:
int x[][][] = new int[2]; x[0] = new int[100][200]; x[1]=new int[200][100];
@freemo It would also impact OpenCL kernels because the kernel would have to keep this variable dimension mapping by index, which would make the kernel really slow
I'm also working on other project now
but feel free to comment, I'll be around
@CoreRasurae so far everything looks good, ill approve. I also agree tha tthe ticket doesnt make sense as a feature. Ill labe it as a feature we wont do
@CoreRasurae ill run the tests manually for now. You tested on linux only i presume?
just trying to manually test for this one merge
Should have it merged soon just need to get my windows box back up
Doing that now and will be merged later today if it passes tests
@freemo cool
@CoreRasurae and @freemo I agree with Jeffrey here. We tried to allow this in the original Aparapi, but dropped it. It makes coding easier but is very inneficient. Ideally you can replace this with a single array (100x200)+(200x100) in length and manage the indices yourself. This would only prove viable on a HSA compatable device with fully coherent memory. The other advantage of a single block of memory is that it is less likely to be moved by the garbage collector. The bigger the object the more likely it will be allocated (or quickly moved to) perm-gen.
@jchan007 The code has already been merged. You can find it in: https://git.qoto.org/aparapi/aparapi-native
@grfrost I also agree with what you say