• State Accepted Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 6 replies
  • Subscribers 138 subscribers
  • Views 8309 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

On Mali-G76, it will take 2 cycles for 2-D bi-linear filtering per 4 sample quad. Does it mean that read_imagef() and write_imagef() have the same cycles in doing 2-D bi-linear filtering?

xwentian

Hi,

When I read the materials about G76, especially about its texture unit. I encountered a question about its performance in doing 2-D Bi-linear interpolation. It was said that for Mali-G76 the best case performance (bi-linear filtered samples) is 0.5 cycles per sample. Some other related descriptions were given as well, like that this counter increments for every texture filtering issue cycle, that some instructions take more than one cycle due to multi-cycle data access and filtering operations, and that  the costs per 4 sample quad are:(i) 2D bilinear filtering takes two cycles, (ii)2D trilinear filtering takes four cycles; (iii) 3D bilinear filtering takes four cycles, and (iv) 3D trilinear filtering takes eight cycles. So my question is whether the OpenCL API read_imagef() and write_imagef() has the same performance in using texture unit on 2-D bi-linear interpolation.

Thanks.

  • 0 Arm Employee Badge in reply to xwentian

    Yes, don't copy read-only data into local memory - there is no dedicated local memory in the Mali hardware, so this just wastes cycles. 

  • 0 in reply to xwentian

    BTW. The input data to be interpolated is a little bit larger than 3840x2160 in size and the result is a 4K NV21 image. This interpolation is a step in an image stablization application on Android. 

  • 0 in reply to Peter Harris

    Hi, Pete

    Thanks for your reply. I parsed the way of using OpenCL to implement the bi-linear interpolation and its maximal performance. As for your suggestion, I think you recommend that the input image should be kept in the texture memory, a read-only on-chip memory space to the GPU threads, rather than the common way of puting the input image data in the local memory. Am I right in thinking your recommendation so?

  • +1 Arm Employee Badge in reply to xwentian

    Hi xwentian, 

    If you use imageLoad/Store to access the data, then yes, that sounds correct (albeit the bilinear filtering would be done manually by the application in shader code in this case).

    It's worth noting that the imageLoad/Store path is slower than texture reads and framebuffer writes on newer Mali GPUs. Mali-G77 can load 4 bilinear texture() samples per clock, vs 1 imageLoad() sample per clock. For simple filtering, it is therefore recommended to use textures for input, and framebuffers for outputs when possible.

    HTH, 
    Pete

  • 0 in reply to Peter Harris

    Hi, Peter

    Thanks for your explanation.  It will take 1 cycle to load raw data, 0.5 cycle for bi-linear filtering, and 1 cycle to keep the result on one sample, so totally it will take 2.5 cycles per pixel? 

  • 0 Arm Employee Badge

    Hi xwentian, 

    The imageLoad/imageStore for all current Mali GPUs path runs at 1 sample per cycle.

    Kind regards, 
    Pete