Versioned API

[vchuravy]

This PR implements parts of #40. The code for OpenCL versions 1.1 and 1.2 is conditionally loaded if a platform is found that supports them.

Changes:

• splitting up api.jl into api.jl, opencl_10.jl, opencl_11.jl and opencl_12.jl
• adds a functional @ocl_func_deprecated
• removes @ocl_func_1X and changes @ocl_func to evaluate the expr in the api module
• adds OpenCL.api.OPENCL_VERSION
• adds @has_ocl12? macros

[vchuravy]

The Travis breakage looks unrelated.

Also @deprecate currently doesn't work the way it is supposed to.

[vchuravy]

I added three macros for my most common use case.

using OpenCL; const cl = OpenCL

platform, device, ...

const image = cl.@min_v12? device begin
   cl.api.clCreateFromGLTexture(...)
end : begin
     cl.api.clCreateFromGLTexture2D(...)
end

[vchuravy]

the @deprecate macro is doing the wrong thing for this use case. Instead of just warning that you are using a deprecated function it actually reroutes the call to the new function. So I will have to add a deprecation macro that mimics Base.@deprecate, but doesn't reroute the call.

[vchuravy]

An interesting approach is what OpenCL.jl took.

using OpenGL
@OpenGL.version "1.0"
@OpenGL.load

We could then check if the version specified is supported by at least on available platform and then load the api.

https://github.com/rennis250/OpenGL.jl/blob/master/src/OpenGL.jl

@jakebolewski What do you think about the whole approach outlined in this PR? Worth pursuing?

[vchuravy]

So I am happy with the functionality gain vs complexity added. The only thing I am unhappy about is that this needs eval inside a macro to put the code in the right context, but if we want something like this I don't see any way around this.

@jakebolewski Final call is yours :)

[jakebolewski]

@vchuravy I finally got a new computer so I can actually work on this again! I had a closer look at your pull request and pushed a couple of changes to jcb/versioned_api.

Just a note. eval inside a macro is bad, in this case you wanted everything to be included in toplevel module scope which is why eval was necessary.

This looks pretty good, but I still have reservations. The main is that we now have to execute code at Module load time which you generally want to avoid. It takes a bit longer to load (~10%) which is not terrible but I feel that static compilation might be coming in the next release and this will complicate things if we want to take advantage of that. I don't know if it would be worth waiting until conditional modules arrive, it seems like a better solution than what we can do now.

[vchuravy]

I like your changes :)

Yes I was wondering how this might play with static compilation. But my intuition would be to fix this when and if conditional modules and static compilation is available.

[jakebolewski]

Ok fair enough. I guess this doesn't really break any valid use of the low
level API. We should fix the travis build and then merge this. I'm also
getting a segfault in the Program tests on OS X but I think that is
unrelated.

On Sat, Aug 23, 2014 at 10:08 AM, Valentin Churavy <[email protected]

wrote:

I like your changes :)

Yes I was wondering how this might play with static compilation. But my
intuition would be to fix this when and if conditional modules and static
compilation is available.

—
Reply to this email directly or view it on GitHub
#42 (comment).

[vchuravy]

superseded by #54