A proposal for adding local memory and barrier access to Aparapi
gfrost
how to support local memory and barriers in Aparapi Kernels. I would
welcome discussions/comments here or as Wiki comments on the page
itself.
http://code.google.com/p/aparapi/wiki/LocalMemoryAndBarrierProposal
Gary
tdeneau
I recall another issue we wrestled with at Alpha time was that arrays
that were annotated @Local in their declaration could be also be
passed as parameters to methods inside the kernel or could be assigned
to aliases. So we would need some way to track what the @local array
gets passed to and assigned to. And if you had a parameter that was
sometimes used for a global array and other times local, you would
have to deal with that. Ideally you would want to find mismatches at
javac time rather than at execution time.
The OpenCL language itself addresses this by requires the address
space qualifier to appear on every pointer or parameter to which the
__local pointer could be assigned.
-- Tom
gfrost
I think in the end this was the rationale for banning all possible
forms of Array aliasing (and I believe this is still the case) so you
can't assign arrays "int[] arr = myLocal;" in a Kernel. You can't
pass arrays as args to methods. You can't return arrays from methods.
But you are right this becomes even more scary when we essentially
have two different types (__local and __global) from OpenCL point of
view, with Java oblivious to the distinction.
I really wish Java extended the reach of annotations, for example
restrictions which allows only parameters which matched some
annotation be passed to a method.
So if we had
@Local buf[];
@Global otherBuf[];
We could extend annotation engine so that it would only allow us to
pass args with the matching Annotation.
int method(=@Local) int arg[]){ // I made up the =@ prefix ;)
}
method(buf); // OK
method(otherBuf); // invalid.
Whatsmore we could overload based only on annotation matching, so we
could add.
int method(=@Global) int arg[]){
}
And then dispatch to each using
method(buf); // calls int method(=@Local) int arg[]){}
method(otherBuf); // calls int method(=@Global) int arg[]){}
rlamothe
would it be possible to use AOP to solve these issues? Creating this
kind of check sounds very similar to the intent of parameter
validation in JavaEE 6 javax.validation.constraints annotations (or
Hibernate Validation)...these annotations support the following
@Target(value={METHOD,FIELD,ANNOTATION_TYPE,CONSTRUCTOR,PARAMETER})
Either way, we could potentially create a pointcut which uses @Before
or @Around advice and a custom validator in the aspect.
Gary Frost
I am not sure i would want a dependency between aparapi and aspectj. Me sidetrack here was merely that, something i wish that java allowed. Aparapi will still restrict array aliasing so i dont think this will be an issue. For example we wont allow arrays to be passed to methods ( we might make exceptions for the new extension mechanism).
Of course we could achieve this using the 'secret bcel classes shipped in rt.jar' :)
Gary
tdeneau
address spaces the only reason we banned aliasing arrays, passing
arrays as args, etc? I ask because if this is the only reason for
this restriction
and people think this restriction is painful, we experimented in the
pre-Alpha days with
an address space API based on Buffers. For example there was a
LocalFloatBuffer, LocalIntBuffer, etc. These buffers were also
extended to
support other OpenCL address spaces, eg, PrivateFloatBuffer.
I will try to post some API documentation from that.
On Dec 6, 2:50 pm, Gary Frost <frost.g...@gmail.com> wrote:
> I am not sure i would want a dependency between aparapi and aspectj. Me
> sidetrack here was merely that, something i wish that java allowed. Aparapi
> will still restrict array aliasing so i dont think this will be an issue.
> For example we wont allow arrays to be passed to methods ( we might make
> exceptions for the new extension mechanism).
>
> Of course we could achieve this using the 'secret bcel classes shipped in
> rt.jar' :)
>
> Gary
> > > > -- Tom- Hide quoted text -
>
> - Show quoted text -
tdeneau
I just created Wiki page for a proposal to solve the AddressSpace
issues (like __local) with classes that derive from Java Buffers.
Some advantages are that arrays (or buffers) within the same address
space can still be aliased or passed as parameters. Perhaps more
important, the LocalXXXBuffer constructor can be defined so as to
eliminate the need for the programmer to know localSize.
Please take a look at
http://code.google.com/p/aparapi/wiki/AddressSpacesUsingBuffers
-- Tom
Gary Frost
I edited your page a little to use {{{code }}} instead of
<pre>code</pre> it automatically colorizes Java code.
So because we have explicit types representing local/global buffers we
can use Java's normal overloading rules to allow distinct method
calls, and to check that we don;t pass a 'global' to a method
expecting a 'local'.
Also I think we spent some effort arranging for these buffers to use
direct buffers underneath (like NIO) so that we did not have to pin
them.
Remind me again why we cant's use generics?
class LocalBuffer<T> {
}
Was this because we can't use templates for primitives? Is that right?
Gary
tdeneau
prevented us using generics.
rlamothe
<Integer>? AFAIK, in Java 7 you can use <int>, so it is something we
should consider looking forward...
Gary Frost
If we had something like
class Buf<T extends Number>{ // to allow Float/Double/Integer
T[] array;
};
When we declare
Buf<Integer> myInts = new Buf<Integer>();
The array inside the Buf class is an array of objects (of type
java.lang.Integer) not 'int' (primitive). The Integer objects
referenced from this array are not in contiguous memory ( the object
references are) so we can't push the integers to the GPU in one txfer.
The 'May 2008 comment' here
http://bugs.sun.com/view_bug.do?bug_id=4487555 proposes a solution
(smart compiler creating an int[] when type is an int).
BTW this is the same problem with Java 2D arrays. Java does not have
pure primitive rectangular arrays so the primitive values are not in
one contiguous region. So a transfer of 512x512 array of floats would
result in 512 copies (of 512 floats) into a single interim buffer,
copied to GPU, executed, copied back into interim buffer and then
copied back to the original java array objects.
Gary
Gary
rlamothe
Thanks, but I am curious about the exact performance problems it would
cause? Has Aparapi written both implementations and gathered any
performance metrics?
For example, even if Aparapi has to copy the ArrayList<Integer> to an
int[] using ArrayList.toArray() and execute on the int[] internally,
how much of a hit is it...and at what point does it start becoming a
problem?
I'm asking this in the spirit of Aparapi making the usage of OpenCL
intuitive and natural for Java developers (who are used to using Java
Generics).
On Dec 14, 10:21 am, Gary Frost <frost.g...@gmail.com> wrote:
> This will be a performance issue I think.
>
> If we had something like
>
> class Buf<T extends Number>{ // to allow Float/Double/Integer
> T[] array;
>
> };
>
> When we declare
>
> Buf<Integer> myInts = new Buf<Integer>();
>
> The array inside the Buf class is an array of objects (of type
> java.lang.Integer) not 'int' (primitive). The Integer objects
> referenced from this array are not in contiguous memory ( the object
> references are) so we can't push the integers to the GPU in one txfer.
>
gfrost
changes to test it. I would be interested in the results of the
test ;)
Gary
> Gary,
>
> Thanks, but I am curious about the exact performance problems it would
> cause? Has Aparapi written both implementations and gathered any
> performance metrics?
>
> For example, even if Aparapi has to copy the ArrayList<Integer> to an
> int[] using ArrayList.toArray() and execute on the int[] internally,
> how much of a hit is it...and at what point does it start becoming a
> problem?
>
> I'm asking this in the spirit of Aparapi making the usage of OpenCL
> intuitive and natural for Java developers (who are used to using Java
> Generics).
>
> On Dec 14, 10:21 am, Gary Frost <frost.g...@gmail.com> wrote:
>
>
>
>
>
>
>
> > This will be a performance issue I think.
>
> > If we had something like
>
> > class Buf<T extends Number>{ // to allow Float/Double/Integer
> > T[] array;
>
> > };
>
> > When we declare
>
> > Buf<Integer> myInts = new Buf<Integer>();
>
> > The array inside the Buf class is an array of objects (of type
> > java.lang.Integer) not 'int' (primitive). The Integer objects
> > referenced from this array are not in contiguous memory ( the object
> > references are) so we can't push the integers to the GPU in one txfer.
>