• State Accepted Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 4 replies
  • Subscribers 136 subscribers
  • Views 9948 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

Mali 450 r6p1 & DMABUF

Lionel

Hello,

I have been trying to use DMABUF With egl on a Mali 450 (on an odroid C2).

I was able to successfully use it with the following setup for a 1920x1080 image :

const EGLint img_attrs[] = {

          EGL_WIDTH, 1920,

          EGL_HEIGHT, 1080,

          EGL_LINUX_DRM_FOURCC_EXT, DRM_FORMAT_RGBA8888,

          EGL_DMA_BUF_PLANE0_FD_EXT, pbuffer->fd_handle,

          EGL_DMA_BUF_PLANE0_OFFSET_EXT, 0,

          EGL_DMA_BUF_PLANE0_PITCH_EXT, 1920,

          EGL_NONE

      };

eglCreateImageKHR(eglGetCurrentDisplay(), EGL_NO_CONTEXT, EGL_LINUX_DMA_BUF_EXT, 0, img_attrs);

Though RGBA format is not optimal when working with 1080p or 4K images, especially in terms of memory bandwidth.

So I wanted to use either DRM_FORMAT_NV12 or DRM_FORMAT_YUV420.

As far as i have seen DRM_FORMAT_NV12 is described as a two planes format in drm_fourcc.h so i tried the following :

const EGLint img_attrs[] = {

          EGL_WIDTH, 1920,

          EGL_HEIGHT, 1080,

          EGL_LINUX_DRM_FOURCC_EXT, DRM_FORMAT_NV12,

          EGL_DMA_BUF_PLANE0_FD_EXT, pbuffer->fd_handle,

          EGL_DMA_BUF_PLANE0_OFFSET_EXT, 0,

          EGL_DMA_BUF_PLANE0_PITCH_EXT, 1920,

          EGL_DMA_BUF_PLANE1_FD_EXT, pbuffer->fd_handle,

          EGL_DMA_BUF_PLANE1_OFFSET_EXT, 1920*1080,

          EGL_DMA_BUF_PLANE1_PITCH_EXT, 1920 / 2

          EGL_NONE

      };

eglCreateImageKHR(eglGetCurrentDisplay(), EGL_NO_CONTEXT, EGL_LINUX_DMA_BUF_EXT, 0, img_attrs);

This will results in EGL_BAD_PARAMETER error code when using eglCreateImageKHR

I have tried many combinations both for the NV12 DRM format and the YUV420, but i have always ended up with an EGL_BAD_PARAM error when using anything else than RGBA.

Could anyone shed some light on the proper way to configure the attributes, both for YUV420 and NV12 please ?.

Parents
  • +1

    DMABUF generally supports YUV to support non-GPU media masters - e.g. camera, video, ISP, etc - it would be unusual for the GPU to process YUV because OpenGL ES is specified in terms of RGB. Certainly YUV isn't guaranteed to be free - it comes with a lot of additional overheads in the GPU (color conversion to/from RGB, writing out to multi-plane surfaces, for example).

    Writing out YUV is possible in some of the Mali hardware, depending on platform and use of driver extensions, but even if you managed to get it working on Mali-400 I would expect it to be slower than writing simple RGB.

    Also note that the size of the render target is irrelevant to bandwidth per clock; larger render targets will take longer to process but for a consistent workload per pixel the bandwidth per clock will be identical at 640x480 and at 4K. Assuming that larger render targets are more likely to benefit from compression for a performance optimization is therefore incorrect.

Reply
  • +1

    DMABUF generally supports YUV to support non-GPU media masters - e.g. camera, video, ISP, etc - it would be unusual for the GPU to process YUV because OpenGL ES is specified in terms of RGB. Certainly YUV isn't guaranteed to be free - it comes with a lot of additional overheads in the GPU (color conversion to/from RGB, writing out to multi-plane surfaces, for example).

    Writing out YUV is possible in some of the Mali hardware, depending on platform and use of driver extensions, but even if you managed to get it working on Mali-400 I would expect it to be slower than writing simple RGB.

    Also note that the size of the render target is irrelevant to bandwidth per clock; larger render targets will take longer to process but for a consistent workload per pixel the bandwidth per clock will be identical at 640x480 and at 4K. Assuming that larger render targets are more likely to benefit from compression for a performance optimization is therefore incorrect.

Children