Abstract TextureObject breaks OpenCL interop

[klkblake]

Creating an OpenCL image from an OpenGL texture requires access to the texture ID, which is no longer possible now that TextureObject is abstract.

[svenpanne]

First of all, my knowledge of OpenCL is relatively limited (i.e. next to zero ;-), so I have only a very rough understanding of the things involved.

http://www.khronos.org/registry/cl/specs/opencl-2.0.pdf states that clCreateFromGLTexture2D and clCreateFromGLTexture3D are deprecated, although I don't have a clue what the replacement is. clCreateImage looks close, but I can't figure out if/how one can emulate the previous API entries with that. Are the deprecated API entries the ones you are talking about?

Another point is that Hackage seems to contain several bindings for OpenCL, which is very confusing. Hopefully this will somehow be consolidated and the "dead" packages be clearly be marked as such. Which package do you use?

I just want to understand things a little bit better before exposing the texture ID again.

[klkblake]

clCreateFromGLTexture{2D,3D} were consolidated into clCreateFromGLTexture (previous versions of the spec had 3D image support as an extension, hence the seperate functions). They are pretty much identical in function.

I use this package: http://hackage.haskell.org/package/OpenCL, which is the most active AFAICT.

[svenpanne]

Ah, OK, I was just looking at the wrong part of the OpenCL spec: http://www.khronos.org/registry/cl/specs/opencl-2.0-extensions.pdf contains clCreateFromGLTexture. :-) OK, I'll export the TextureObject constructor again then.