First of, the only way the struct will actually end up in private memory is by copying it from global or constant memory. Second, every thread has its own private memory so the struct will be duplicated for each thread wasting memory space. Third, a struct with array components that are accessed in a dynamic way (through a pointer for example) cannot be stored in registers anyways, so it will reside in global memory.
Making things worse is that private memory that is spilled to global memory will not be cached because it makes no sense to do so, since each thread has its own copy.

Regarding: “This is ok for me, since ‘constant’ is a special type of ‘global’ and reading it comes at a performance penalty anyway.”
Yes it is global memory but there is a special constant cache (usually 8kb) on each multiprocessor which is as fast as L1 cache.
So storing the struct in constant memory is in fact the most efficient way (those GPU designers have done their homework after all).

Please don’t take my comment the wrong way, i’ve done some crazy “optimizations” myself in the past :)

Here are the most relevant points from the host code:

typedef struct{
cl_uchar cDist;
cl_uchar cClass
float y[N_POINTS_DEPTH];
float x[N_POINTS_RANGE];
float c1D[N_POINTS_DEPTH];
}myStruct_t;


The test kernel takes only 2 arguments, the struct as for input, and another struct of the same type to hold some test data computed from the input. Here’s the host-side memory allocation:

//instantiate a struct for input:
myStruct_t a;
a.y[0] = 1.4;
a.y[1] = 2.5;

//allocate memory for output:
cl_mem out = clCreateBuffer(context, CL_MEM_READ_WRITE, sizeof(myStruct_t), NULL, &errNum);
if(errNum != CL_SUCCESS){
fatal(clError(errNum));
}else{
DEBUG(2, "Successfully allocated memory for output.\n");
}


Then, set the kernel args:

errNum = clSetKernelArg(kernel, 0, sizeof(myStruct_t), &a);
errNum |= clSetKernelArg(kernel, 1, sizeof(cl_mem), &out);
if (errNum != CL_SUCCESS){
fprintf(stderr, "Error setting kernel arguments.\n");
fatal(clError(errNum));
exit(EXIT_FAILURE);
}else{
DEBUG(2, "Successfully defined kernel arguments.\n");
}


The kernel:

__kernel void testStructs( private myStruct_t soundIn,
global myStruct_t *result){
local myStruct_t ssp;

*result = ssp;
}


So from my tests i figured out that apparently you cannot actually use the ‘constant’ qualifier when passing in a struct, it has to be ‘private’. This is ok for me, since ‘constant’ is a special type of ‘global’ and reading it comes at a performance penalty anyway. To me it makes sense to have a settings struct in the fastest available memory.
I tested this on an Nvidia GPU with OpenCL 1.1 and on a Intel Ivy Bridge CPU also with a OpenCL 1.1 implementation.

I looked at the OpenCL conformance tests and couldn’t find any place that tests that feature. It’s possible that it’s broken in some implementations :(

As far as passing in a struct not as an array, I have tried many different combinations to no avail. If someone can give me an example which works I will gladly update the tutorial but we’ve had to play this trick finding no alternative.

Also thanks for pointing out the constant args device info, that’s good to know. 9 still seems rather small.

Thanks again
Ian

Even though we only want one structure, we still need to pass it in as a buffer to appease OpenCL.

I don’t think there’s anything in the OpenCL spec preventing you to pass a struct as a kernel argument. For instance, section 5.7.2 lists how to pass different types of arguments to clSetKernelArg. After listing all built-in types and pointers, it says “For all other kernel arguments, the arg_value entry must be a pointer to the actual data to be used as argument value.” Additionally, section 6.8-p reads “Arguments to __kernel functions that are declared to be a struct do not allow OpenCL objects to be passed as elements of the struct”, which implies that it’s okay to pass structs as kernel arguments.

When interpreting a struct, OpenCL accesses the memory in blocks of 16 bytes, which is the same as 4 floats (each 4 bytes).

That is not correct either. What OpenCL requires is that each struct member must be naturally aligned. For example, a float variable, since it has a size of 4 bytes, must be aligned to a 4-byte boundary. Your example struct could be defined just fine as

typedef struct Params
{
float A;
float B;
int C;
} Params;

Keep in mind that, in accordance to C99 rules (of which OpenCL C is a derivative), compilers are free to insert padding between struct members and at the end of the struct. It wouldn’t be surprising at all if the particular compiler you are using has decided to pad the struct size to 16 bytes.

If you want to pass structs to kernels it makes sense to specify alignment attributes, as explained in section 6.10.1 rather than attempting to guess what the particular OpenCL compiler you have installed is doing. Inserting hand-crafted padding members means that your program may not work correctly in a different computer.

Additionally, at least on some implementations there seems to be an arbitrary limit of 9 constant (non-buffer) parameters, which using a struct will help you avoid.

This limit is not arbitrary. It can be queried through clGetDeviceInfo() and CL_DEVICE_MAX_CONSTANT_ARGS.

If you have any other doubts or questions about the OpenCL standard, please refer to the Khronos message boards where people will be happy to help.