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

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

How to access(zero copy) android AHardWareBuffer and ANativeWindow_Buffer, with mali opencl?

please note, ANativeWindow_Buffer is not ANativeWindowBuffer. 

AHardWareBuffer 

https://developer.android.google.cn/ndk/reference/group/a-hardware-buffer

 ANativeWindow_Buffer:

https://developer.android.google.cn/ndk/reference/group/a-native-window#group___a_native_window_1gad0983ca473ce36293baf5e51a14c3357

Parents
  • 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

Reply
  • 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

Children