Just responding on the "small fixed size vector" thing. I believe this is something so important that it should go directly to base. See https://github.com/JuliaLang/julia/issues/5857 for recent discussion.
I am currently porting some code from C++ to Julia that involves calculating coordinate transforms and directly thought this is something that will also be needed for the OpenGL package. For now I use the Vector3 type from ImmutableArrays. Am Samstag, 19. April 2014 20:39:47 UTC+2 schrieb Simon Danisch: > > 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 > > >
