for (int i = 0; i < N; i++) {
for (int j = 0; j < N; j++) {
long sum = 0;
for (int k = 0; k < N; k++) {
sum += a[i][k] * b[k][j];
}
c[i][j] = sum;
}
} Kernel kernel = new Kernel() {
@Override
public void run() {
int i = getGlobalId(1);
int j = getGlobalId(2);
int k = getGlobalId(3);
c[i][j] += a[i][k] * b[k][j];
}
};
@grfrost I have never examined the "output" value of any (primitive) kernel field - for the reasons you state they would be meaningless. In fact, I'd be surprised if the JNI code copies anything in to them (what would if copy the value from?).
In fact, if the run() method was one monolithic method which didn't call other methods (as in fact is the case with the compiled OpenCL - every single method call gets inlined when OpenCL is compiled - hence recusrsion not allowed!) then there would be no need for setting field values. In fact, local variables would do.
But for maintaining state between method calls, field setting is invaluable (especially as Java has no "out parameter" semantics for returning multiple values from a method). It's especially important for polymorphic Kernels ... most of my Kernels extend base Kernel classes and the base classes often have methods which mutate fields.
I'm basically certain kernel fields use private memory in Aparapi (i.e. no modifier - as private memory space is the default memory space) . Though I haven't double checked the code, none of my Kernels would work if they weren't!
Incidentally, when doing JTP execution, of course, the Kernels are clone()d, so theoretically something meaningful could be "returned" in primitive fields, though obviously we throw away the clones.
@gfrost No, I definitely want them for the kernel code path! (Pretty sure you are right that Aparapi only complains if the putfield is actually used on the kernel execution path.)
I never care about Java accessing the "output" values of primitive fields. But I very much care about OpenCL accessing them. E.g. public void run() {
writeToSomeFields();
doSomethingWithModifiedFields();
}
