Results 1 to 6 of 6

Thread: RGB Image2d?

  1. #1
    Junior Member
    Join Date
    Feb 2018
    Posts
    7

    RGB Image2d?

    Hello everyone

    I'm new to OpenCL, so this might be a novice question.
    I'm working on some image processing algorithms in OpenCL, and for what I understand it's a better choice to use textures instead of buffers whenever it's possible. The thing is the images I want to process have 3 1-byte channels (RGB), and I read that's not a supported format for an Image2d in OpenCL:

    https://www.khronos.org/registry/Ope...geFormats.html

    These are my ideas to get through this:
    1. Preconvert in CPU my RGB image to RGBA, as RGBA is supported. I'd rather not. Sounds costly when performance is what I'm looking for.
    2. Use a regular buffer instead of a texture. I want textures
    3. *out of ideas*


    I must be missing something here, because 3-channels images are pretty common. Is there a way to use RGB format?

    Thank you for reading

  2. #2
    Senior Member
    Join Date
    Dec 2011
    Posts
    249
    That table is the _minimum list of supported image formats_. Many implementations support many more, including CL_RGB. Check yours using that API (clGetSupportedImageFormats), or use clInfo. If you want to run on any hardware found in the field, then you must stick to the minimum list of supported formats, in which case you can have an CL_RGBA fallback, or upload a buffer of RGB and have a kernel that converts it to a CL_RGBA image.

    BTW, the advantages of images of buffers: cached fetches (nearby reads will be faster), one kernel can work with many different formats (uint8, half float, full float; CL_RGB vs. CL_RGBA), and bilinear interpolation using read_imagef. On the other hand, if you don't need any of those, and are doing aligned coalesced accesses, buffers can be faster. But go outside that, and they are slower than images.

  3. #3
    Junior Member
    Join Date
    Feb 2018
    Posts
    7
    Hi Dithermaster, thank you for your reply. I'm looking for a portable code so I prefer to stick to the minimum list (NVIDIA doesn't support RGB anyway, and that's what I'm using). I still find it strange that a 3-channel image is not a standard ; I guess alpha channel is far more common in Computer Graphics.

    I didn't understand quite well everything you said about buffers vs textures. Few questions:
    1. What do you mean when you say that a kernel can work with many different formats? I don't see any limitations on this with normal buffers. Aren't those just the arguments data types?
    2. Billinear Interpolation? I'm familiar with image and math theory but I didn't get what you meant by a billinear interpolation using read_imagef.
    3. Long one: I suppose a single cache memory is used by many kernels, so I would guess if two "nearby" kernels read two nearby pixels they take advantage of the cache memory, even if each kernel is performing a single read, right? Also, are non-cached reads the same speed in a normal buffer and in a texture? Lastly, why aren't normal buffer reads cached?

    Thanks again

  4. #4
    Junior Member
    Join Date
    Feb 2018
    Posts
    7
    Quote Originally Posted by naicolas12 View Post
    Hi Dithermaster, thank you for your reply. I'm looking for a portable code so I prefer to stick to the minimum list (NVIDIA doesn't support RGB anyway, and that's what I'm using). I still find it strange that a 3-channel image is not a standard ; I guess alpha channel is far more common in Computer Graphics.

    I didn't understand quite well everything you said about buffers vs textures. Few questions:
    1. What do you mean when you say that a kernel can work with many different formats? I don't see any limitations on this with normal buffers. Aren't those just the arguments data types?
    2. Billinear Interpolation? I'm familiar with image and math theory but I didn't get what you meant by a billinear interpolation using read_imagef.
    3. Long one: I suppose a single cache memory is used by many kernels, so I would guess if two "nearby" kernels read two nearby pixels they take advantage of the cache memory, even if each kernel is performing a single read, right? Also, are non-cached reads the same speed in a normal buffer and in a texture? Lastly, why aren't normal buffer reads cached?

    Thanks again
    I think I just answered 1. myself. When you write a kernel code you don't specify the image format. Great.

  5. #5
    Senior Member
    Join Date
    Dec 2011
    Posts
    249
    1. Right
    2. If you use read_imagef with float2 coord and CLK_FILTER_LINEAR, it read 4 pixels instead of 1 and blends between them based on the fractional component. Check the specification for CLK_FILTER_LINEAR.
    3. I think caching is mostly for within a kernel, but probably bridges across them too. Buffer reads can be cached in some hardware, but image reads have 2D locality (due to internal tiling) while buffer reads have 1D locality.

  6. #6
    Junior Member
    Join Date
    Feb 2018
    Posts
    7
    Thank you for your help Dithermaster, I guess I'll have to convert my images to RGBA or use a normal buffer.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Proudly hosted by Digital Ocean