Allocating memory from a double pointer on Device

1

Hello all
I have a struct that looks as follows and I wish to allocate memory for certain members of the struct -

    char mode[IMAGING_MODE_LENGTH]; 
                                       
    int type;                       
    int depth;                      
    int bands;                      
    int xsize;                   
    int ysize;

    ImagingPalette palette;

    /* Data pointers */
    UINT8 **image8;  /* Set for 8-bit images (pixelsize=1). */
    INT32 **image32; /* Set for 32-bit images (pixelsize=4). */

    /* Internals */
    char **image;               /* Actual raster data. */
    char *block;                /* Set if data is allocated in a single block. */
    ImagingMemoryBlock *blocks; /* Memory blocks for pixel storage */

    int pixelsize; /* Size of a pixel, in bytes (1, 2 or 4) */
    int linesize;  /* Size of a line, in bytes (xsize * pixelsize) */

    void (*destroy)(Imaging im);

And as it can be seen, it has a lot of double pointers which contain the actual image data. I want to transfer that data to the GPU for further processing.

I am not clear as to how to transfer data from a double-pointer array in SYCL as it is (i.e. without flattening the array)

Thanks In Advance

2

I suppose the first question would be do you need to use the double pointer indirection or are you using some existing code that requires that?
It is possible you could use Unified Shared Memory to handle the pointers to the memory but we haven’t actually tried it with that level of indirection.
If you want to learn about USM you could try the lessons and exercises we presented at IWOCL+SYCLcon 21 or read the SYCL book.

3

Hello Rod,
Thank you for replying.

I am writing kernels for an existing code base and unfortunately cannot do away with the double pointers.
I will have a look at the USM and try to make it work.

Thanks a lot.

4

Sure that sounds good. Let us know if you have any specific questions about using USM in this way. Also if you come across any problems it would be good for us to know about these, as I say we have not tested this scenario yet.