A proposal for allowing library extensions to be added.

[gfrost]

I just added this proposal for how we might allow new extensions to be
added to Aparapi. For example this would allow third-parties to
create FFT, BLAS type libraries using hand crafted/optimized OpenCL
and have these available to developers of Kernel code.

I would welcome feedback on this proposal.

Issue #24 (http://code.google.com/p/aparapi/issues/detail?id=24)
touched on this

The proposed API is shown here http://code.google.com/p/aparapi/wiki/AparapiExtensionProposal

Gary

[Witold Bołt]

Hi.

This idea is really good. API proposal also looks quite good with exception of "getOpenCL()" method.

I would rather see the FFT class like this:

public class FFT {
@OpenCL(signature="//function signature - OPTIONAL", body="{ // body of function goes here }")
public void forward(
@Global @ReadWrite float[] _data,
@Global @ReadWrite float[] _imaginary) {
// java implementation
}

@OpenCL(function="{ // body of function goes here }")
public void reverse(
@Global @ReadWrite float[] _data,
@Global @ReadWrite float[] _imaginary) {
// java implementation
}
}

Signature of OpenCL function is defined separately so that Aparapi could auto-generate it for common cases. This is better then getOpenCL() approach since there is no risk that we mix up naming of functions (names are generated from package, class and method names - and we don't need to force the coders to understand this). Also in future it would be good to support non-debug class files or even obfuscated files (where class/method names could change). If we keep function names auto-generated we are on the safe side. If we hardcode them… we need to be careful.

The other idea is to have something like this:

@OpenCL(preload="somefile.cl")

… as a parameter of the class. This would load a OpenCL auxiliary file via class loader from current class package directory. In such file you could define all your utility / auxiliary stuff that your methods would be using.

What do you think?

Br,

Wiadomość napisana przez gfrost w dniu 3 gru 2011, o godz. 18:30:

[gfrost]

Witold

Your proposal is elegant and covers 99% of code (it was actually the
first idea I came up with), I decided on adding the getOpenCL()
method for the cases where we wanted to create the OpenCL 'On the
fly' rather than having it pre-canned.

The FFT algorithm is a good example. One could paramaterize the FFT
instance so that the 'radix' (2,4 8 for example) of the FFT is passed
to the FFT at construction time. The OpenCL code for a radix 2 or
radix 4 FFT might be 'similar' but parameterized differently by
allowing the getOpenCL() method (using a StringBuilder and some simple
logic to handle the differences).

After consideration I think this requirement is likely to be rare and
we probably should encourage multiple classes for this ( FFTRadix2,
FFTRadix4 ... etc for these...). So I prefer your solution, it is
cleaner to use annotations for this and provide explicit method
bindings.

Your @OpenCL at the Class level also covers my other concern, I could
not see how to declare common code (methods, #pragmas, contant fields)
if the code was only provided for each method. We needed somewhere
for declaring common method declarations (foo() in the example below
called from both forward() and reverse()). We can use the Class level
@OpenCL annotation for this.

@OpenCL(common="/* common void foo(){} + maybe #pragmas + accessable
global fields declared here */")
public class FFT {
@OpenCL(signature="//function signature - OPTIONAL", body="{ /*
uses foo(); */ }")

public void forward(
@Global @ReadWrite float[] _data,
@Global @ReadWrite float[] _imaginary) {
// java implementation
}

@OpenCL(function="{ /*uses foo(); */) }")

public void reverse(
@Global @ReadWrite float[] _data,
@Global @ReadWrite float[] _imaginary) {
// java implementation
}
}

Gary