I would be up for working together to implement OpenGL <--> OpenCL
integration. No work has been done in this area because I don't need it
and no-one has stepped up to implement it. Another stumbling block is that
the only GPU's I have access to run on a headless remote cluster.
The surface area for OpenGL interop in the OpenCL API is pretty small, a
handful of functions. The main source of commonality between the OpenCL /
OpenGL would be how to define the texture image datatypes. This would be a
great area to collaborate as we could share datatypes between the two
libraries. This functionality could be split out in its own package so
OpenGL does not become a dependency for OpenCL. It is useful to use
Texture memory ("Images" in OpenCL parlance) in situations that do not
require OpenGL, although as caches on GPU's increase in size the advantages
of using Texture memory are diminishing. I've implemented partial texture
support in a branch of OpenCL.jl so that could be a point of discussion if
you want to push things further.
As for collaboration between higher level API's, I think that some
commonality can be found between OpenCL, OpenGL, and CUDA. All libraries
have to copy data back and forth over some type of channel (a "stream" in
CUDA, or a "queue" in OpenCL) and have some operations to manually manage
(free). These operations are not conceptually different from copying data
to / from a remote processor so it would make sense for the API's of these
libraries to align with what is in Base. Cuda and OpenCL have to launch
kernels over a range of data, so it might make sense to align these two
API's. I hope eventually we can implement a common GPUArray datatype with
Cuda / OpenCL backends so this could be re-used as a common datatype for
CUDA / OpenCL math libraries (BLAS, FFT) and common gpu array functions.
On Thursday, April 17, 2014 11:28:53 AM UTC-4, Tim Holy wrote:
>
> 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
>
