cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

Fr4nz
Journeyman III

"sizeof" bug with uchar vectors?

Hi all!

I've noticed a strange thing: if I write this in a kernel (with cl_amd_printf enabled):

[...]

__local uchar test[256];

printf("%d", sizeof(test));

[...]

the printf will print "4" instead of "256" (as it should do). In other words, it seems that the sizeof operator is returning the size of the pointer to the vector and not the size of the vector...

Any explanation about this?

0 Likes
8 Replies
settle
Challenger

Originally posted by: Fr4nz

 

__local uchar test[256];

 

printf("%d", sizeof(isKmerDuplicated));

 

Maybe that's just a typo, but it seems you have "sizeof(isKmerDuplicated)" when you should instead have "sizeof(test)"; then again your result would make sense if "isKmerDuplicated" is a pointer to uchar.

0 Likes

Originally posted by: settle

Maybe that's just a typo, but it seems you have "sizeof(isKmerDuplicated)" when you should instead have "sizeof(test)"; then again your result would make sense if "isKmerDuplicated" is a pointer to uchar.

Hi settle,

it was just a wrongly made cut/paste (now corrected). Anyway, if you try the testcase I've reported you'll see that the problem exists.

0 Likes

Are you using a OpenCL 1.0 or 1.1? I think cl_khr_byte_addressable_store was an extension in 1.0, but integrated as part of the spec in 1.1.

Anyway, I digress...While a size of 4 is incorrect, it probably has to do with the fact that on the GPU anything less than 32bits (cl_int) is emulated. In this case It seems that not all proceedures (such as sizeof()) is correctly emulated.  I guess you would get the same result with ushort and half data types.

0 Likes

Originally posted by: antzrhere

Are you using a OpenCL 1.0 or 1.1? I think cl_khr_byte_addressable_store was an extension in 1.0, but integrated as part of the spec in 1.1.

Anyway, I digress...While a size of 4 is incorrect, it probably has to do with the fact that on the GPU anything less than 32bits (cl_int) is emulated. In this case It seems that not all proceedures (such as sizeof()) is correctly emulated.  I guess you would get the same result with ushort and half data types.

I'm using OCL 1.1.

While it's true that any type < 32 bit is emulated through an int (or packed into? anyone has an idea?) when using local mem, if you actually try to apply the sizeof operator on a simple uchar variable it will correctly return "1". And, anyway, if promotion to an int should be taken into account, in the example above sizeof should return 4*256="1024" and not "4" for the vector.

So this doesn't appear to be the culprit...

0 Likes

Any news on this?

0 Likes

Originally posted by: Fr4nz Any news on this?

 

Reported to developers. It is expected to return  256 for your code.

0 Likes

Originally posted by: genaganna

Reported to developers. It is expected to return  256 for your code.

Hi genna, thanks for the attention.

I have a little question: how are managed types < 32 bits in shared memory? Are these automatically "expanded" to an int (so, let's say, a char in shared memory occupy 32 bits and not 😎 or are they properly "packed"?

0 Likes

Originally posted by: Fr4nz[/i


Hi genna, thanks for the attention.

 

I have a little question: how are managed types < 32 bits in shared memory? Are these automatically "expanded" to an int (so, let's say, a char in shared memory occupy 32 bits and not 😎 or are they properly "packed"?

 

I'll answer to myself: it seems that datatypes < 32 bits are packed properly into local memory, at least when examining __local pointer values. Obviously this can favour bank conflicts, but it's a reasonable price to pay.



 

0 Likes