an opencl binding - zcl/panama

[Maurizio Cimadamore]

Thanks for putting the time on doing the conversion work (bleeding bonus 
point since we're in such an early stages) - and more importantly, for 
writing all the feedback up. I will be reading that carefully (and post 
some comments in here).

This is what contributing looks like, kudos.

Thanks again
Maurizio

On 24/01/2020 03:45, Michael Zucchi wrote:
>
> Hi guys,
>
> I've been waiting on work to organise themselves this year so i've had 
> plenty more free time and it's been too cold to drink beer, alas.  
> Rather than poke the emailing list I've been busy porting zcl over to 
> use jdk.incubator.foreign.
>
> I wrote a fairly detailed overview of the issues and problems at the 
> link below.  It also has some details on obtaining the source. The 
> source is modular and builds on gnu/linux/amd64 using gnu make and 
> perl.I could provide a pre-generated netbeans 11 compatible 
> source-tree if asked and it will already open in netbeans after you 
> get 'make gen' to run.
>
>   https://www.zedzone.space/software/panama.html
>
> In summary: I solved every problem and mostly present the same api but 
> a lot of it wasn't particularly fun to solve or write.  I use low 
> level stuff directly with no Pointer or similar abstractions and have 
> a thread-specific stack allocator thing for argument construction.
>
> This is very much work in progress, a lot is missing (although mostly 
> clEnqueue* variants) and what isn't hadn't been tested.  I have an old 
> gpu and the only driver i have is Mesa OpenCL 1.1, and even then that 
> has no support for images so i'm severely restricted in what i can 
> even check (i do have access to other machines*).  I don't really have 
> any demo code but now I have a base working I can make some up ... if 
> i can think of anything. I didn't include the source but i have 
> successfully compiled a kernel, invoked it, had an event invoke a 
> callback, and accessed results, and had things collected properly.  
> Although that was before i re-arranged it from a testbed to branch on 
> zcl so i might've broken everything in the move.
>
> For this project perhaps some benchmarks of the api would make more 
> sense than anything.  It uses the lowest level api's almost directly 
> so it might be a good candidate for comparison to others that use 
> abstractions. I didn't choose this route for performance, it was just 
> easier to write and is infact the second attempt after throwing away a 
> whole pile of abstraction code that just got in the way.
>
> Cheers,
>  Z
>
> * stairs in the way, broken hip, on crutches for last 3 months, nearly 
> @#$@# over
>