8 Replies Latest reply on Oct 26, 2011 11:14 AM by Fr4nz

    "sizeof" bug with uchar vectors?

    Fr4nz

      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?

        • "sizeof" bug with uchar vectors?
          settle

           

          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.

            • "sizeof" bug with uchar vectors?
              Fr4nz

               

              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.

                • "sizeof" bug with uchar vectors?
                  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.

                    • "sizeof" bug with uchar vectors?
                      Fr4nz

                       

                      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...

                        • "sizeof" bug with uchar vectors?
                          Fr4nz

                          Any news on this?

                            • "sizeof" bug with uchar vectors?
                              genaganna

                               

                              Originally posted by: Fr4nz Any news on this?

                               

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

                                • "sizeof" bug with uchar vectors?
                                  Fr4nz

                                   

                                  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 8) or are they properly "packed"?

                                    • "sizeof" bug with uchar vectors?
                                      Fr4nz

                                       

                                      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 8) 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.