mxGPUGetDimensions returns an array with zeroes in between the dimension sizes

Question

So I pass a 5 by 6 (host) matrix to my mex function. (Part of) my code:

const mxGPUArray* A;

A=mxGPUCreateFromMxArray(prhs[0]);
const mwSize* img_size =  mxGPUGetDimensions(A);
const int M=img_size[0];
const int N=img_size[1];
const int O=img_size[2];
const int P=mxGPUGetNumberOfDimensions (A);

mexPrintf("\n %i %i %i %i \n",M,N,O,P);

My output is:
5 0 6 2

And if I set P to be img_size[3] I get 0, img_size[0 to 3]= 5,0,6,0

even though the number of dimensions according to:

mxGPUGetNumberOfDimensions (A);

is

2

The documentation doesn't mention anything about this. Why is this? Is mwsize actually not equivalent with size_t or something? Does it refer to the memory pitch? Am I actually using a flat 4D array?

Answer 1

I have to preface this by saying that I have never worked with the Matlab mex interface before, however....

What is clearly happening is that there is a mismatch in size between what mxGPUGetDimensions is returning, and what you code is using for mwSize. The result you get [5, 0, 6, 0] is actually [5,6] if the return values were 64 bit integers (size_t on a 64 bit platform for example), rather than 32 bit. The Matlab documentation for mwSize says the following:

By default, mwSize is equivalent to int in C. When using the mex -largeArrayDims switch, mwSize is equivalent to size_t in C.

Because I know absolutely nothing about Matlab, I can't tell you how to fix this beyond (a) making sure that your compiler/toolchain is building 64 bit code, and (b) try using that largeArrayDims option.

If none of that works, I would suggest contacting Mathworks support. Something is clearly broken in either your build environment or Matlab itself.

Answer 2

Okay, so I added the

-largeArrayDims

switch, and now the values are correct, i.e.

img_size[0]

and

img_size[1]

correspond with the correct values.