Compared to pretty much any other api i've seen opencl is very simple and concise and helpfully the opencl standard document is accurate, complete, and readable: what more could you possible ask for?
I am absolutely happy with it as a developer and it's a big reason I'm actually enjoying hacking again.
The long development cycles is in getting good performance out of the exotic hardware: i've found the opencl api provides a natural mapping to the hardware and it's impact has been small enough not to even notice it's there once you've written a couple of demos (as it should be). More experience makes the development faster.
Pages 76-98 talk about the image object api - i don't really see what you're getting at here about complexity. There are only 10 functions, and it is pretty much bare-bones whilst still being relatively friendly. I mean how could you simplify any of those in any useful way? Perhaps you could drop the copies, but then developers would have to write their own in software instead. Or stick to 3d objects: but they aren't the same thing in the device code/hardware for efficiency reasons, so it doesn't make sense. An api implementer could do any other possible simplification themselves internally if they really wanted to (e.g. map all the image allocators/copies to a 3d version, the information queries to a generic object query, etc).
As for the api user: checking for 'success' vs 'not success' is all you can possibly do anyway: what other checks would you do apart from print a string matching the error code? Many of the errors returned only point to coding errors which is not something you would ever use code to deal with at run-time.
Your link doesn't work btw.
If you want some simplifications on the functions you could use the C++ bindings. I for one never use the C API. There's simply no point and the C++ bindings simplify resource management and reduce the frustrating need for double calls to allocate memory before getting data back. It also gives you more type safety, which is one reason for using multiple functions instead of moving everything into arguments that would lead to more runtime checking.
There are some places where the API could be simplified, and some things along those lines have been discussed at Khronos. Clearly we can't discuss any details. I think in reality they are fairly small. Much of the complexity of the API comes from the fact that it's in C, and this is just unavoidable at that level and given the amount of control developers want.
Thanks for your feebacks guys !
Will the implementation of those functions allow simultaneous usage both for 2D and 3D images ?
Looking forward (as our clients do) to get the first version of OpenCL software and GPU hardware from AMD supporting both 2D and 3D image functions as specified by Khronos and later on the version scaling to multiple GPUs !