Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

clEnqueueCopyBufferToImage and the like not exposed in Image2D, Image3D and Buffer #28

Open
royerloic opened this issue May 7, 2015 · 2 comments

Comments

@royerloic
Copy link

Dear Olivier,

Is there a way to use clEnqueueCopyBufferToImage (and related) in here:
http://nativelibs4java.sourceforge.net/javacl/api/development.old/com/nativelibs4java/opencl/library/OpenCLLibrary.html

on Image2D, Image3D objects?

Ideally these opencl functions should be implemented in Image2D, Image3D to expose this very important functionality.

What do you think?

Thanks in advance for your help!

@ochafik
Copy link
Member

ochafik commented May 8, 2015

Hi @royerloic ,

Thanks for reporting this omission! Should definitely be supported, will take a look (feel free to send a PR if it takes too long)

I guess it should be implemented as CLBuffer.copyToImage(CLQueue, CLImage, ...)

@royerloic
Copy link
Author

Hi Olivier!

Thanks a lot!

On 08 May 2015, at 14:30, Olivier Chafik notifications@github.com wrote:

Hi @royerloic https://github.com/royerloic ,

Thanks for reporting this omission! Should definitely be supported, will take a look (feel free to send a PR if it takes too long)

I guess it should be implemented as CLBuffer.copyToImage(CLQueue, CLImage, ...)

I would also add the symmetric:

CLBuffer.copyFromImage(CLQueue, CLImage, ...)

Something else entirely:

Please also have a look at the other issue with concerning Pointers versus NIO,
as I explained, I LOVE your Pointer class in BridJ, extremely powerful and not limited
in size/indexing as the NIO buffers. It would be a real pity to have JavaCL not fully support
it - also at the high level. I would suggest having version sof the functions that take a Pointer
instead of a NIO Buffer… What do you think? This is much lower priority, but still would help
a lot in many cases where BridJ-based code and JavaCL code are exchanging data… :-)

I would like to acknowledge your project in our own project website:
https://clearvolume.github.io/ClearVolume/ https://clearvolume.github.io/ClearVolume/

Should I point to the github or google code page?

Thanks!!

Loic


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

Dr. Loïc Alain Royer

Post-Doc - Myers Lab
Max Planck Institute
of Molecular Cell Biology
and Genetics
Pfotenhauerstr. 108
01307 Dresden

Too short? Here's why: http://emailcharter.org/

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants