Archives Discussions

[dragonxi4amd]

Less might be more!

Hi,

Referring to http://www.khronos.org/registry/cl/specs/opencl-1.1.pdf

and for example pages 76 - 98,  the number of combinations for the caller (application programmer) and for the implementation (programmer of functions) to code and to test is demanding - even if the programmer uses copy/paste as most obviously has been used in writing the specifications !

Note for example:

A. there might exist a dedicated function for 3D and for 2D image, whereas some functions handle both 2D and 3D images based on given parameters

B. a new function has been specified for example to copy although

one copy function might have been able to handle copy operation using parameters

C. amount of data to be checked by caller and by each function is huge! 

Referring to some other topics in this forum, the complexicity of OpenCL specifications might be one of the reasons to developent times ?

QUESTIONS:

Q1. Would it be possible to simplyfy the specifications ?

Q2. Are all happy with http://www.khronos.org/registry/cl/specs/opencl-1.1.pdf

specifications:

a) AMD developers ?

b) application developers ?

c) tool developers ?

d) hardware developers ?

e) others such as those waiting for OpenCL software and hardware ?

Feedbacks wellcome!

Ronnie

[notzed]

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.

[LeeHowes]

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.

[dragonxi4amd]

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 !

Ronnie