Sounds great, I hope we can soon work together on this! My biggest problem right now, is a very limited time budget though. But I hope to have more time in a couple of weeks!
Ideally, Khronos would just merge OpenGL and OpenCL at some point ;) But I guess that's something far in the future. Anyways, I also hope for a unified GPUArray+Texture type, and probably also even a more generic GPUProgram type. OpenGL and OpenCL programs shouldn't be too different. Another issue is, to have Julia types with the right memory alignment, that can be uploaded directly to VRAM, but are also well supported by Julia in terms of functions defined on them. So far, Julia's arrays have been working great for me, but I don't really have enough know-how, to evaluate all cons and pros. One reason against Julia arrays I came across so far is, that there are not fixed in length, which is basically what all the GPU arrays are. Also, there need to be some decisions about representing color values and values in general. Color.jl seems to be really magnificent, but nevertheless, I started using my own color representation, as it was sometimes simply more convenient. Also, I'd sometimes like to treat colors just like a vector, or a normal positional vector as a color, which isn't possible with Color.jl without conversions. In some packages, I saw a few reimplementations of Vectors and the like, so it seems that there is a certain danger of an early fragmentation. But I think this kind of redundancies should be avoided at any cost. Nothing would be more annoying, than having different GPU packages with different linear algebra/image/color representations as a foundation. Similarly, we need a good numeric type mapping for the different back-ends. Right now the situation is quite messy, with a lot of aliases, but without the respective convert shortcuts like uint(). Ideally, we would have a mapping like c-name --> julia-name --> name in kernel-language. But I'm not sure how to treat this issue on a higher level. Is it better to always use Julia's numeric type names, and then convert them on a lower level, or is it better to propagate all the c-names up to higher level packages. This is quite a difficult decision, and so far I copied the approach from OpenGL.jl, where all arguments of the functions are untyped, so that that you can input any type, which then gets checked and converted by the ccall. Maybe we should create a package, addressing all these issues in an unified way for all back-ends. This could be a great foundation for any GPUArray type and automatic kernel generation. Best, Simon
