How to access(zero copy) AHardWareBuffer and ANativeWindow_Buffer, with Mali OpenCL?

Hi,

The short answer is that there is no clear, easy and guaranteed-to-work way of importing one of these without a copy.

We are currently working on adding support to our memory import extension [1] for importing an AHardwareBuffer directly. This will exist in upcoming versions of the driver. You can contact our customer support to learn more about this.

Until the extension is available,  there are a number of workarounds that you can try:

For AHardwareBuffer

With help from the platform vendor you should be able to get hold of the underlying dma_buf file descriptor. You can then import it using cl_arm_import_memory [1].

If you have access to VNDK functions or can get some help from the platform vendor (or maybe by reading the Android source code), you can:

get a native handle from the AHardwareBuffer:

                const struct native_handle *native_hnd = AHardwareBuffer_getNativeHandle(m_ahb);

cast that to a buffer handle:

                buffer_handle_t buffer_hnd = static_cast<buffer_handle_t>(native_hnd);

from which you can extract a dma_buf file descriptor that you can import with help from your platform vendor.

I should emphasize that it is definitely not a clean or portable solution but it would allow you to get things working before the extension is available.

For ANativeWindow_Buffer

You can *try* to import ANativeWindow_Buffer::bits as a host pointer with clImportMemoryARM selecting CL_IMPORT_TYPE_HOST_ARM. This is however unlikely to work as on most platforms bits is a mapping of an underlying dma_buf allocation that clImportMemoryARM won’t be able to import.

You can pass ANativeWindow_Buffer::bits as host_ptr when creating a CL buffer with CL_MEM_USE_HOST_PTR. This should work but the OpenCL runtime will currently make a copy in most scenarios.

Lastly, and I know that’s ultimately what you’re trying to avoid, you can always create a buffer and copy data in and out.

Hope this helps and sorry there is no good solution currently.

Regards,

Kévin

[1] www.khronos.org/.../cl_arm_import_memory.txt

there is some info below, about AHardwareBuffer, on https://developer.android.google.cn/ndk/guides/stable_apis#hardware_buffer_apis,

"You can allocate an AHardwareBuffer and use it to obtain an EGLClientBuffer resource type via the eglGetNativeClientBufferANDROID extension. You can pass that buffer to eglCreateImageKHR to create an EGLImage resource type, which may then be bound to a texture via glEGLImageTargetTexture2DOES on supported devices. This can be useful for creating textures that may be shared cross-process"

2, About ANativeWindow_Buffer.

Is there any other way to render the preview, with OPENCL? For real time preview, i wonder how to directly write the display buffer, with openCL.

there is a opencv sample , opencl can precess GL texture, but the preview is rendered via OpenGL textures other than OPENCL.
docs.opencv.org/.../tutorial_android_ocl_intro.html

[1] github.com/.../ComputeLibrary

The Mali OpenCL driver now supports Importing AHardwareBuffer: www.khronos.org/.../cl_arm_import_memory.txt

yes, I have read the develope guide,  and can   AHARDWAREBUFFER_FORMAT_Y8Cb8Cr8_420 be  Imported with the extention for R/W?

It look like that, AHARDWAREBUFFER_FORMAT_Y8Cb8Cr8_420  can't be import by the extention.

As ION can be imported, Can I import a NV21(YVU420P) image with graphic buffer,  in such way:

get file handle of the ION from gb(graphic buf), the import the ION buffer with fd: 

int fd =( (private_handle_t*) gb->handle)->fd;

AHARDWAREBUFFER_FORMAT_Y8Cb8Cr8_420  is very important because android camera provide the image data in this format. For Other format such as RGBA8888, It's not difficult and not nessesary to use the cl_arm_import_memory,  opencl can acess it with openglTEXTURE2D.