copy 2d image to 3d image

Hi,

I'm experimenting with using 3d images, and I noticed that the CLCommandQueue api's only support copying from 2d-2d and 3d-3d images.  As such there seems no direct way to create 3d images on-gpu from 2d images since the 3d image write extension isn't available on my hardware.

I can work around this using the low-level api directly, but there doesn't seem to be much point to the duplicated type specific image copying functions in the API.  Should they reflect the clEnqueueCopyImage() more directly - i.e. accept both 2d and 3d images?  At least in the lowest-level, most general method?

i.e. just change
 putCopyImage(CLImage3d<?> srcImage, CLImage3d<?> dstImage, ...)
to
 putCopyImage(CLImage<?> srcImage, CLImage<?> dstImage, ...)

Speaking of 3d images, there looks to be a bug in createImage3d(int width, int height, int depth, int rowPitch, CLImageFormat, Mem...).  It passes rowPitch as the depth to it's callee, and discards depth.  I've filed a bug (#491).

Cheers,
 Z

  Hello,

the problem here is that the full method definition would look like:

     public CLCommandQueue putCopyImage(CLImage<?> srcImage, CLImage<?>
dstImage,
                                         int srcOriginX, int srcOriginY,
int srcOriginZ,
                                         int dstOriginX, int dstOriginY,
int dstOriginZ,
                                         int rangeX, int rangeY, int
rangeZ, CLEventList condition, CLEventList events) {}


if you would now use this method with 2d images you would have to set
the z-offset to 0 and the z-range to 1 of the 2d image. By using typed
methods the CLCommandQueue can do that for you automatically.

But i could do that if this would help you in your usecase...


The command queue has two code paths, one for 2d and 3d data as you
already mentioned. We could think about merging the impl of both
codepaths into one dispatcher method but it would force us to use
instanceof or similar constructs to get the type of the argument. Since
the impl is so small i see it currently as low priority and would rather
add typed copy2dTo3d and copy3dTo2d methods... but we can talk about
that also..

#491 is fixed, thank you for the report, you are very good in finding
this kind of bugs -> please continue ;)

best regards,
michael

On 04/04/2011 05:48 AM, notzed [via jogamp] wrote:

Thanks for fixing the bug - I had a long break before getting back to work again so i'm bound to come across more.  I just popped back here because I had an issue with LongBuffers but someone beat me to reporting it!

I've left the code in question for now so i'm not in immediate need of 3d images after-all (thankfully, a lot of housework to get them set up), but i just checked the current source and what you've done looks good to me.  Not that it is in any way important - I'm not sure why you need the separate code-paths for 2d and 3d, couldn't the 2d helper methods just call the genereral method with appropriate values as the 3d helpers do?  The only difference I can see is in the exception message and a shallower stack.

Cheers,
 MichaelZ

Michael Bien wrote

Hello,

the problem here is that the full method definition would look like:

     public CLCommandQueue putCopyImage(CLImage<?> srcImage, CLImage<?>
dstImage,
                                         int srcOriginX, int srcOriginY,
int srcOriginZ,
                                         int dstOriginX, int dstOriginY,
int dstOriginZ,
                                         int rangeX, int rangeY, int
rangeZ, CLEventList condition, CLEventList events) {}


if you would now use this method with 2d images you would have to set
the z-offset to 0 and the z-range to 1 of the 2d image. By using typed
methods the CLCommandQueue can do that for you automatically.

But i could do that if this would help you in your usecase...


The command queue has two code paths, one for 2d and 3d data as you
already mentioned. We could think about merging the impl of both
codepaths into one dispatcher method but it would force us to use
instanceof or similar constructs to get the type of the argument. Since
the impl is so small i see it currently as low priority and would rather
add typed copy2dTo3d and copy3dTo2d methods... but we can talk about
that also..

#491 is fixed, thank you for the report, you are very good in finding
this kind of bugs -> please continue ;)

best regards,
michael