Inline array creation not supported in kernels.
shabanovd opened this issue · comments
Is there any elegant way to handle complex numbers operations?
new float[] = new float[2]; is not allowed. Anything else to try?
@shabanovd is there any reason you cant initialize the array before entering the kernel?
nope, because I have heavy complex numbers calculations and initial array will be too big
@freemo how hard to add limited support for primitive types arrays that mapped to OpenCL vectors?
@shabanovd it might not be too hard to add support for OpenCL vectors actually. Id be willing to pay someone a bounty to implement it, wouldnt be a very large bounty but we have had good success with bounties so far. If that doesnt work would you be interested in trying yoru hand at a PR for that support? I could do it myself but im overloaded with work on a few projects right now but might have some time.
@freemo I did investigate it a bit. It should be more or less simple, here jvm patterns:
float[] vector = new float[4];
0 iconst_4
1 newarray
3 astore_1
float[] b = new float[] {0f, 0f, 0f, 0f};
0 iconst_4
1 newarray
3 dup
4 iconst_0
5 fconst_0
6 fastore
7 dup
8 iconst_1
9 fconst_0
10 fastore
11 dup
12 iconst_2
13 fconst_0
14 fastore
15 dup
16 iconst_3
17 fconst_0
18 fastore
19 astore_1
and last one
float[] method(float[] a) {
a[0] = a[0] + 1;
return a;
}
public void run() {
float[] b = new float[4];
b = method(b);
results[y] = b;
}
0 iconst_4
1 newarray
3 astore_1
4 aload_0
5 aload_1
6 invokevirtual
9 astore_1
10 aload_0
11 getfield
14 aload_0
15 getfield
18 aload_1
19 aastore
20 return
0 aload_1
1 iconst_0
2 aload_1
3 iconst_0
4 faload
5 fconst_1
6 fadd
7 fastore
8 aload_1
9 areturn
It's easy to control array size on newarray. And implement handling of aastore pattern.
Is it right direction?
@shabanovd yea looks like a good start. You considering doing the pull request?
@shabanovd I'll post this with a small bounty once I finish the code coverage bounties im trying to do, unless you jump on a pr first.
@freemo I'll be able to make PR in a week or two. Right now, I'm totally overloaded.
@freemo btw, do you know why most test mark Ignore? Is there any plans for redesign? Mean, grab OpenCL code from comments at class that used for OpenCL code generation?
@shabanovd I have a guy working on the unit tests this month. Just all part of the redesign effort, There was an older system in place to run unit tests we didnt like so it is slowly being migrated over. Just got someone on board to put in that work over the next month.
@freemo I see, ok
My guess is that @ignore was something we acknowledged, but we did not think should stop us releasing/committing code.
@grfrost the ignore was something I added, I have a bounty being implemented to redo the unit tests. I mostly just wanted to draw your attention to the thread as we were discussing the possibility of implementing OpenCL vectors here. So thought you might want to follow the thread.
@freemo here first step shabanovd@6b1fa8b
@shabanovd I've made you a collaborator on the project and assigned this ticket to you and myself.
@freemo here the test and generated OpenCL code
There are number of tests, for example ReturnBooleanNewArray, that pass before and fail now because start to generate OpenCL code. Should I add @Ignore or add expected OpenCL code?
Also, I have battle between float[16] vs float16. There is no clear performance difference but float16 will require different access (.xyz...).
I didn't test yet, but think that arrays should work already ;-)
@shabanovd I'd say update the unit test so it works. It will be evaluated in the pull request.
Hey @grfrost I now you had some ideas on vector implementation. I'd love to get your thoughts on this.
@shabanovd should we change the title of this issue to "Array creation support" and then close it once you finish your PR? If you would still like to see complex number support perhaps we open a separate ticket (and PR) for that?
This ticket is being resolved in PR: #63