It just seems strange to have reads included but not writes.
When a feature is made optional or an extension it usually means that some hardware in the market does not support it.
Ah ok, this post is just the culmination of a lot of annoyance with this command. Only having a read command and not a write as well seems very inconsistent to me.
Do you know anyway of emulating the use of 3d images on cards that don’t support the extension?
Why don’t you simply use the extension and forget about the (hopefully) few graphics cards that cannot write into 3D images?
All you need to do is start your OpenCL programs with:
#pragma OPENCL EXTENSION cl_khr_3d_image_writes : enable
When you say few do you mean all of the nvidia cards with public drivers and anything but the last 2 generations of ati cards?
Nvidia’s support for OpenCL extensions are abysmal.
Sigh. I suspected that the extension would not be very widely available. Thanks for the info.
Going back to my first comment: when a feature is exposed as optional or as an extension it means that there’s hardware that doesn’t support that feature. From what you say, it looks like recent NVidia cards cannot write into 3D images natively, so NVidia doesn’t want to expose that extension.
The only workaround I can think of is accessing the data as a regular buffer instead of as a texture. This means that you won’t get the performance benefits of using the texture pipes, but at least your program will be functional.
With some preprocessor macros you would be able to switch from 3D images to buffers quite easily.
Yer i know, its such a shame.
The strange thing is that with Nvidia the hardware supports it and since GTC 09 they have said that they do have a code.
If I used buffers would I be getting a big performance hit or is it just the added complexity of the code needed?
The performance hit is going to depend a lot on the algorithm you are implementing, and also on whether it runs on Fermi or older cards. Fermi has global memory caches while older generation cards do not.