Another issue, especially relevant if you throw CUDA into the mix, is that there may be some tension between "making a common interface," "exposing the functionality in the underlying toolkit," and "making it familiar to people migrating to Julia with experience in other domains." There will be some inevitable tradeoffs, but that doesn't mean it's not worth thinking about.
With regards to array/datatypes, I'm a bit skeptical that there will be such a thing as "seamless" interoperability. Because of the overhead of transport, I suspect that it's too important to know whether your array is in main memory or is on the device. As an example, in my own work I've avoided implementing `getindex` for arrays that are living on the device. But that doesn't mean that you can't have a rich range of operations possible with arrays on the device, it just means you have to provide the functionality in terms of device code. Of course, getting to the point of being able to compile Julia code to kernel code will change everything :). Looking forward to that day. --Tim On Thursday, April 17, 2014 08:07:01 AM Simon Danisch wrote: > Hi, > I wondered, if it isn't about time to sit together and discuss the bindings > between Julia, OpenGL and OpenCL and define APIs and a general structure. > I'm always tending to ignore CUDA, as I don't like to support something > that tries to enforce a monopoly, but I guess it can't be ignored it should > be put into the mix as well... > > When I read through the mailing-list, it seems that there are multiple > people working on this, but without a lot of inter communication between > the parties. > I hope we can change this, as for example the OpenGL and OpenCL packages > should be developed very congruently. > A lot of things are very similar between OpenGL and OpenCL. > For example, automatic kernel/shader generation, or Arrays, that need to be > uploaded/downloaded to video memory. > It would be a pity, if we develop completely different APIs for these > operation, and even worse, have redundant code. > I must admit, planning this all out goes a little bit over my expertise and > time budget. > But I would be very happy to participate in a discussion and redefine the > OpenGL package accordingly. > It would be incredibly awesome, if we can build an API with an unified and > concise way of defining kernels, that can be run in parallel on any kind of > back-end. > The final transformations of the data for a nice visualization should also > work hand in hand with this. > > Topics that need to be discussed (that I can think of, there are definitely > more) > > - What is the right platform to discuss this? (a new mailing-list? > Julia-dev? Github?) > - Is it possible to create efficient kernel code from LLVM code for > OpenGL, CUDA, OpenCL > - What are the alternatives > - How does an array/datatypes need to be designed, to work with > Julia/OpenCL/OpenGL seamlessly > - How to glue everything together > - Syntax for choosing the device and operation > - Make more hardware information available in Julia, to enable macros > like @OpenGL3.3? > > I hope we can find a few people and work together on this! > > Best, > Simon
