What Charset is used by OpenCL?

Hello Marco13 :slight_smile:

I’m trying to port your JOCLDeviceQuery.java to scala (just as an exercise), but i’ve got a problem with your „getString“ methods:

    private static String getString(cl_platform_id platform, int paramName)
    {
        [...]
        // Create a buffer of the appropriate size and fill it with the info
        byte buffer[] = new byte[(int)size[0]];
        [...]
        return new String(buffer, 0, buffer.length-1);
    }

Last line seems a little bit problematic to me, because you do not specify the encoding here: my laptop, for example, has some weird charset called „windows-1252“ as default, so the result of the method call is an unreadable sequence of question marks. Using

val charset = java.nio.charset.Charset.forName("US-ASCII")
[...]
new String(buffer, charset)

instead seems to fix it, but i still ask myself: is there an „indigenous“ encoding in OpenCL, used on all platforms, or ist this encoding different on different platforms? If latter is the case, then i would like to know, if there is a possibility to find out what encoding is used, this would help to restore the illusion of platform-independance.

PS: it might well be that the question has nothing to do with OpenCL, i just haven’t seen lot of platform-dependant code yet :confused:

Thanks

greetz, Andrey

Hello

Short answer: It’s most likely ASCII, so using US-ASCII as the charset here should be the appropriate solution.

Long answer: While cl_char is explicitly defined to be 8 bit, the result types of the functions that involve strings is usually ‘char’, and AFAIK, in C the ‘char’ is only defined to have at least 8 bits. I never have seen a ‘char’ in C with more than 8 bits, and assume that any C where it does not have 8 bits would have a problem anyhow.

In any case: Thanks for this hint, I’ll see if I can update the sample accordingly - I’m just wondering what happens to the trailing ‘\0’ in this case, but I’ll find out.

BTW: You probably have seen that there is also a http://code.google.com/p/scalacl/ ?!

bye
Marco

Ok, it’s not a completely satisfying answer yet, but it supports my conjecture that all this ultra-low-level stuff is in ASCII :slight_smile:

In any case: Thanks for this hint, I’ll see if I can update the sample accordingly - I’m just wondering what happens to the trailing ‚\0‘ in this case, but I’ll find out.

0 is probably 0 in every encoding, but these tricks are not needed in java, because a String always stores it’s own size in a separate field. If you feed such ‚\0‘-bytes in an array to a string constructor, it just saves all these bytes as they are, and displays them as question marks later. The String is not „truncated“ because of the trailing ‚\0‘, it seems to have no special meaning in Java.

BTW: You probably have seen that there is also a Google Code Archive - Long-term storage for Google Code Project Hosting. ?!

Yeah, seen it all… thanks for the hint anyway.
I don’t want to use it, i mean, compare linked project with your project:

JOCL:

  1. provides OpenCL-Bindings as they are, zero attempts to be more smart-ass as necessary
  2. works

ScalaCL:

  1. provides an opaque scala-compiler plugin that attempts to „fix“ some general for-loops that aren’t broken
  2. page begins with a huge red warning that probably nothing of it works properly

guess what i like more :wink:
I’m not trying to build some High-Level scala-wrapper around it, but as i started working with OpenCL, i found out very fast, that methods like these „getString“ „getLong“ etc are quite useful, so i’m just trying to hide these strange C-typical „handshakes“ (create pointer to size, obtain size, alloc array of correct size, fill array with output) behind methods that are slightly shorter, but have same name and same „semantic signature“.

PS: i just wanted to add that it’s absolutely ok that JOCL does not attemp to eliminate these (sometimes little bit annoying) „handshakes“, because for different JVM-Languages the most idiomatic way to do this would be different.

[QUOTE=0x7F800000]Ok, it’s not a completely satisfying answer yet, but it supports my conjecture that all this ultra-low-level stuff is in ASCII :slight_smile:
[/quote]

I’ve even looked it up in the spec, but there’s nothing said about this. In doubt, one has to assume that it’s ASCII - what else should they pack into single 'char’s (they certainly will not pack Unicode characters into the Vendor Name String…). What makes me slightly insecure about the encoding is, that the ‚length‘ of the returned strings on some platforms seems not to match the length in „valid ASCII characters“… This also refers to the the trailing ‚\0‘: I just found it annoying that the Strings have been messed up, like
AMD Stream SDK!!!%§$"$!$%%!WTF!=@

  1. provides OpenCL-Bindings as they are, zero attempts to be more smart-ass as necessary

    methods like these „getString“ „getLong“ etc are quite useful, so i’m just trying to hide these strange C-typical „handshakes“

On the one hand, this sounds like a contradiction - on the other hand, you explained it later ;). Of course, the low-level API of OpenCL may be tedious, and one could easily replace 10 lines of cryptic low-level code with one line in Jogamp-JOCL or JavaCL. The drawback of JOCL in this sense is, that most likely nearly everbody will create his „own“ set of „convenience“ methods… But I hoped that mimicing the original API would keep all options open make make it easier to port between languages.

bye
Marco

The drawback of JOCL in this sense is, that most likely nearly everbody will create his „own“ set of „convenience“ methods…

Correct. And i’m another one from this set of „everybody“. And i think it’s allright, as long as everyone experiments with his own convenience methods without flooding the internet with it. I’m not going to publish just-another-one-XYZ-wrapper with huge red warnings, because i don’t like planting endless jungles of incompatible versions: an awful lot of incompatible libraries makes everything even more incomprehensible then complete absence of such libraries.

But I hoped that mimicing the original API would keep all options open make make it easier to port between languages.

Perfect: it simply provides a bomb-proof fundament, and keeps your out of biased discussions about syntactic makeup :slight_smile: