Docu bugs and missing constants

Byte-Welt - Projekte / Projects JOCL
1

Hello Marco13!

I’ve got some problems with JOCL again, in the moment, it seems to me like there are „gaps“ in the code…

Problems i’ve encountered in last hour:

  1. [documentation bug] → class CL → clGetDeviceInfo: „CP_FP_FMA“ instead of „CL_FP_FMA“ (at least 2x times)
  2. [missing code] class CL: constant CL_DEVICE_DOUBLE_FP_CONFIG is missing
  3. [missing code] class CL: constant CL_DEVICE_HALF_FP_CONFIG is missing

(CL_DEVICE_SIMPLE_FP_CONFIG is present, that’s weird)

last two are not documentation bugs, it doesn’t compile at all:

 error: not found: value CL_DEVICE_DOUBLE_FP_CONFIG

althought documentation suggests that it should. I’ve searched for „misspelled“ variants of these constants in your source code, but couldn’t find anything there. Strange coincidence: same constants are missing in the official khronos-documentation: did you use it only to create documentation, or did you generated the code from that somehow? :confused:

I’ve looked in cl.h from this page: http://www.khronos.org/registry/cl/ but this constant isn’t defined there either. Looked this up in OpenCL-spec: the constant is mentioned on page 228, but there’s no explicit value :frowning:

Question: how can i obtain the values of those missing constants?

Thanks!

greetz, 0x7F800000

2

Ah, these two constants are in cl_ext.h, not in cl.h :eek:

3

Hello

As mentioned at the top of the CL class documentation: The documentation is blindly leeched from the Khronos OpenCL documentation website. I did neither check it for typos not write it completely on my own (also see the webseach for „CP_FP_FMA“ :wink: )

The missing constants for HALF and DOUBLE have already (at least implicitly) been mentioned at in this thread: http://forum.byte-welt.de/showthread.php?t=3609 - I still have to find a solution for the extension mechanism in general. Maybe I can at least add the constants from cl_ext for the next release…

bye
Marco

4

I’ve seen that note, still i do not really understand how you did it…

I still have to find a solution for the extension mechanism in general.

Could you please describe what you mean by „extension mechanism in general“? I thought these „extensions“ are just some capabilities of graphic cards, that are not standard yet, but i don’t see any complicated machinery behind that, at least nothing that would affect JOCL to a great extent?

little offtopic: i don’t really understand, why every c-package redefines new aliases for primitive data types, what is all that cl_int good for, if it’s just a normal int with 32 bits? Can i be sure that the output will fit into a Long-Variable, if i try to read a size_t variable with clGetDeviceInfo?

5

With a nasty little program that

  • reads my CL.java file
  • searches for „public static“ methods and extracts their names, e.g. „clEnqueueNDRangeKernel“
  • Reads the HTML from the corresponding website, like clEnqueueNDRangeKernel
  • Replaces the comment before the method in the CL.java with a comment that is built from the HTML of the website
    This might look wierd at the first glance, but … I did not like the useless JavaDoc of other libraries…

glCompressedTexImage2D(…)

Entry point to C language function: void glCompressedTexImage2D(...)

Well :twisted: that does not help so much, and you always have to look up the functions somewhere else…

Could you please describe what you mean by „extension mechanism in general“? I thought these „extensions“ are just some capabilities of graphic cards, that are not standard yet, but i don’t see any complicated machinery behind that, at least nothing that would affect JOCL to a great extent?

Well, some other libraries that are providing Java Bindings for OpenCL or OpenGL use some „tricky“ methods to support the extensions (and, by the way, also much more sophisticated methods for resolving the native functions - this is done rather straightforward in JOCL, whereas, for example, in JOGL, they are using function pointers that are resolved at startup and thus may „wire together“ the bindings more flexibly). Others are using not-so-tricky methods, but instead rather pragmatic ones - like this in LWJGL for the example of CL_DEVICE_HALF_FP_CONFIG that you asked for. I’m not sure whether I want a class like this, or simply add this constant along with the „non-extended“ CL_DEVICE_SIMPLE_FP_CONFIG, where it would belong IMHO…

little offtopic: i don’t really understand, why every c-package redefines new aliases for primitive data types, what is all that cl_int good for, if it’s just a normal int with 32 bits? Can i be sure that the output will fit into a Long-Variable, if i try to read a size_t variable with clGetDeviceInfo?

The answer to the first question might be: Because those who defined the C standard failed to provide a reliable definition :wink: For example, a ‚char‘ must have at least 8 bits, but it may have 13 bits and this would still be legal according to C :suspect: The sizes of different data types are difficult, especially now (at the border between 32 and 64 bits - but between 16 and 32 it was the same…). And size_t itself is again not specified to have a specific number of bits or bytes, just to be ~„…large enough to describe the size of any object“. Thus, when a ‚size_t‘ is used in OpenCL, it is usually translated into a ‚long‘ in Java, simply because ‚int‘ would be too small on 64bit systems… However, sometimes care might have to be taken, especialy when dealing with arrays of size_t values. The Sizeof#size_t constant might come in handy there, although it still contains the implementation comment:

/**
 * Size of a size_t, in bytes
 */
// TODO: This is assumed to be the same as the pointer size,
// although this is not clearly specified in the C standard.
public static final int size_t = POINTER;

Any suggestion for a more … „profound“ solution would be welcome…

bye
Marco

6

Okay, but it was „only“ about documentation (which is at least as important as code itself, usually…), you didn’t generate the code (the /*Doc/-Tokens excluded) automatically…

Well :twisted: that does not help so much, and you always have to look up the functions somewhere else…

yeah, that’s annoying… if one doesnt want to type anything, and has no time for careful html-extraction, one can at least leave a link to the original documentation and the right method, or something like that

I’m not sure whether I want a class like this, or simply add this constant along with the „non-extended“ CL_DEVICE_SIMPLE_FP_CONFIG, where it would belong IMHO…

Well, constants are not such a big problem for me right now, i’ve just defined them in a separate file called CL_Ext, just like all the other constants from CL. Not such a big difference… What about „wiring bindings“, i’m afraid that i dont have enough practice with JNI to understand all the details right now :confused: So i just save this information in passive memory, and hope, that i’ll understand it later, when i know more about implementation of (J)OCL and similar projects (like JOGL).

The answer to the first question might be: Because those who defined the C standard failed to provide a reliable definition :wink:

Ah, so that’s the other way around: guys from khronos try to define the standard primitive data types, and the guys who defined C are the crazy ones who allowed 13bit-characters, okay^^ :slight_smile:

Thus, when a ‚size_t‘ is used in OpenCL, it is usually translated into a ‚long‘ in Java, simply because ‚int‘ would be too small on 64bit systems…

ok, that’s exactly what i thought

However, sometimes care might have to be taken, especialy when dealing with arrays of size_t values.

Thanks for the hint, i’ve thought about that too, so now i use a separate „Array[Long]-Extractor“ exactly for that purpose.

/**
 * Size of a size_t, in bytes
 */
// TODO: This is assumed to be the same as the pointer size,
// although this is not clearly specified in the C standard.
public static final int size_t = POINTER;

Nope, no suggestions. It seems to make perfect sense, so i simply assume that it’s true, and stick to this assumption until i find a platform that clearly disproves it :wink:

Thank you a lot! no further questions for the moment… :slight_smile:

7

Currently, the native implementations of all functions are simply and plainly calling their native counterparts. But in fact, the functions, for example, in OpenGL, are not „usual“ C functions, but instead they are function pointers that look like functions… Unfortunately, I currently can’t remember where and how I was made aware of this, and whether it was Guest2 (aka Fancy) from the other forum or Michael Bien from JOGL (I searched some threads, mails and PNs but didn’t find it again … should have made some bookmark or so :(). I have not yet studied the details of this, but JOGL initializes some function pointers at startup, and then does not directly call the native methods, but uses the function pointers instead. This brings more flexibility, for example, for determining the „GL Profile“ which is used, and (maybe even more importantly for OpenCL: ) could allow to gracefully throw an exception when the implementation only supports OpenCL 1.0, but a 1.1 function is called.
I already considered some refactoring for JOGL and JCuda, but first have to figure out how exactly this works, and in any case, I’ll need some more time for that.
There are still some other open issues, it won’t become boring too soon :wink:

bye
Marco