PDA

View Full Version : Access to Intermediate Language under Xcode / 10.7 ???



Photovore
08-31-2012, 03:56 PM
I have an OpenCL kernel that runs well but I want to look at the intermediate code. I use clGetProgramInfo with CL_PROGRAM_BINARIES to pull out the binary and save it to a text file. I've tried this with nVidia, AMD, an i7 and a Xeon.

In all of these cases the binary is unreadable --

I understand that on OS X the chunk of data returned is actually a binary plist. I've found instructions for using plutil to convert it to xml, and the conversion works...

But, that result is still unreadable ... I should see the PTX code there when I compile for AMD (for example). There's the expected clBinaryData key but the data under that key is still one big chunk of stuff, not human-readable IL instructions in text form.

I'd really like to examine the intermediate representation to assess inefficiencies in my use of the gpu. Is this simply not possible under Xcode? Or, what am I doing wrong? [Same problem under 10.7.3 and 10.7.4]

Thanks for any information!...

bmerry
09-19-2012, 06:56 AM
Under Linux on NVIDIA (and possibly Windows, never tried) you get back PTX, so if you can get access to such a machine it might help. Of course, the fact that the OSX implementation is doing something different means you can't be sure that the PTX you get on Linux is actually corresponding to the binary you get on OSX, but it might be a start.

Photovore
09-27-2012, 12:48 AM
1) I think what I may be getting under OSX (when I use the cl functions to compile the kernel)* may be Apple's "bitcode"; in any case it's a valid compilation. Yesterday I finally tried caching it and using clCreateProgramWithBinary, and it does work.

2) It seems that, by changing build settings, the .cl file can be compiled by xcode at build time instead of by the driver at runtime! At that point, there is the option of saving the IL/IR and being able to read it more easily with your own brain and eyes. However, there is an error using that compiler; it spits out an intermediately generated header file, which contains a struct definition, and it has mangled the declaration of arrays within that struct, such that it seems no arrays are allowed. Here is a taste of that intermediate file:

typedef struct bonx {
float [4][3] xc; <-- xcode flags this line with an error, and so would I....
float [4][3] yc; <-- (this line flagged with the same error)
...
cl_float aAngle; <- it likes this fine
cl_float bAngle; <- this, too
...
}

-- that is obviously messed up, and must have been created from these lines in the kernel:

struct bonx
{
float xc[4][3], yc[4][3];
...
float aAngle, bAngle;
...
}

*so*, it seems there may be a bug in that compiler. (Using c_float in the struct def didn't help.)

3) No access to a linux machine, but I think I'm losing interest in this line of pursuit. I think I can do better by (a) getting an nV 570 or 680 [this code seems to get ~50% more of theoretical flops on nV hardware I have than on AMD] and (b) solving cl/gl interoperation problem! (see fresh question-post if you can help!)