Need to support local shared memory

[GoogleCodeExporter]

In our Kernel code, we need to have a way to access local shared memory buffers 
for thread access within an individual group.

This would allow us to perform calculations on data stored in memory that is 
local to each thread group, for example in reduction phases of map/reduce and 
would also allow us to use the available Kernel.localBarrier() effectively.

It appears that right now, all variables exist solely in global memory.

Original issue reported on code.google.com by ryan.lam...@gmail.com on 17 Nov 2011 at 10:29

[GoogleCodeExporter]

We used to have some notion of this using annotations (@Local, @Global and 
@Constant) in the alpha release. The usage pattern was confusing and code with 
@Local was difficult to describe to Java developers. 

I do agree that some algorithms do benefit greatly from the use of @Local 
(along with barriers).

We need to also address how to deal with groupsize efficiently (this was the 
point of confusion in the alpha version). The size of a group is hard to 
predict (although for AMD devices we know the algorithm and can recreate it). 
Typically local buffer size is some function of the group size, so we need some 
way of expressing this. 

I like the idea of using divisors/multipliers in the @Local annotation. 

So 
@Local(groupMultiplier=128) int localBuf[];

This would translate to the localBuf array being 128*get_group_size.

Or 
@Local(groupDivisor=4) int localBuf[];

Would translate to a buffer which is 1/4 of get_group_size.

Original comment by frost.g...@gmail.com on 23 Nov 2011 at 4:55

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Why does this level of configuration need to be exposed to the Java developer?

What I'm thinking is that since we already define __global variables 
implicitly, wouldn't it make sense to simply define @Local annotated parameters 
as __local?

For most cases, all that would be needed in the Java code would be access to 
the following:

- get_global_id
- get_global_size
- get_local_id
- get_local_size
- barrier(CLK_LOCAL_MEM_FENCE)

It sounds like the sticking point is the calculation of get_local_size? Is that 
normally handled by the developer or implicitly within the framework?

Original comment by ryan.lam...@gmail.com on 25 Nov 2011 at 1:57

[GoogleCodeExporter]

I believe that the implementation of this enhancement will require the 
completed implementation of http://code.google.com/p/aparapi/issues/detail?id=14

See comment #6 http://code.google.com/p/aparapi/issues/detail?id=14#c6

Original comment by ryan.lam...@gmail.com on 25 Nov 2011 at 6:12

[GoogleCodeExporter]

I added support for this in the recent r#258 merge of MultiDim and LocalMemory 
support. 

We can now either annotate with @Local or decorate with _$local suffix. 

I do need to add a Wiki page to describe this. 

Original comment by frost.g...@gmail.com on 14 Feb 2012 at 5:45

• Changed state: Fixed

[GoogleCodeExporter]

Thanks Gary!

Original comment by ryan.lam...@gmail.com on 14 Feb 2012 at 9:48