[Mesa-dev] unlock android graphic buffer spend too much time

[Zong, Wei]

Hi Dear Mesa experts,



I'm reading android graphic buffer by calling “GraphicBuffer::lock” with parameter "GRALLOC_USAGE_SW_READ_OFTEN | GRALLOC_USAGE_SW_WRITE_NEVER", I copied the buffer into a CPU allocated memory only cost less than 1 millisecond. the resolution of this graphic buffer is 1280×800, and the image format is “V4L2_PIX_FMT_NV12”



After finishing memory copy, I called “GraphicBuffer::unlock”, this operation spent more than 3 milliseconds, I guess this unlock operation would not do much work, I'm wondering if this 3ms can be saved? Or this 3ms is sure necessary for such operation?



The hardware I’m using is Broxton, and graphic driver is Mesa 18.1.0-devel.



Thanks,

Zong Wei

[Tapani Pälli]

Hi;

Post by Zong, Wei
Hi Dear Mesa experts,
I'm reading android graphic buffer by calling “*GraphicBuffer::lock”
*with parameter "GRALLOC_USAGE_SW_READ_OFTEN |
GRALLOC_USAGE_SW_WRITE_NEVER", I copied the buffer into a CPU allocated
memory only cost less than 1 millisecond. the resolution of this graphic
buffer is 1280×800, and the image format is “V4L2_PIX_FMT_NV12”
After finishing memory copy, I called*“GraphicBuffer::unlock*”, this
operation spent more than 3 milliseconds, I guess this unlock operation
would not do much work, I'm wondering if this 3ms can be saved? Or this
3ms is sure necessary for such operation?

This is not really a Mesa question so I think you want to ask this also
on some other list, not sure which one though. This is specific to
gralloc implementation. I'm guessing this is about Android-IA so you
probably want to discuss this with minigbm module maintainers and
checking what happens during your usecase there.

Note that there are also async versions of lock and lockYCbCr available
.. but hopefully you could just avoid such copy.

// Tapani