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

Problem getting DMABUF EGL image to work as a texture

Hi,

I'm trying to get a video feed to use as a texture on my EGL + GL ES program running on a Mali 400 on Linux.

The problem I'm having is that the content of the texture does not update. It picks up whatever frame the camera was displaying when the EGL image is created, but those contents don't change as the video updates. The same code works correctly on my desktop. I'm using driver version 8.0, I believe (both user and kernel).

When is the data DMAd to GPU memory? I've seen there's the option to enable an optimization when building the driver (MALI_DMA_BUF_MAP_ON_ATTACH) that is turned on by default. I'm not sure if this is related to my issue.

Thank you

Parents
  • When is the data DMAd to GPU memory?

    It's not. There is no such thing as distinct graphics memory on most embedded devices - it's all just "system RAM" and most uses are just memory mappings of the same buffer.

    but those contents don't change as the video updates.

    I'd expect the video decoder to render into multiple output buffers in sequence, not just one. In addition it's normal for there to be a hand-shake which means that the graphics driver must release the buffers it's finished with before the video hardware will reuse it for a later frame (you don't want applications to get a part-decoded frame).

    Cheers, 
    Pete

Reply
  • When is the data DMAd to GPU memory?

    It's not. There is no such thing as distinct graphics memory on most embedded devices - it's all just "system RAM" and most uses are just memory mappings of the same buffer.

    but those contents don't change as the video updates.

    I'd expect the video decoder to render into multiple output buffers in sequence, not just one. In addition it's normal for there to be a hand-shake which means that the graphics driver must release the buffers it's finished with before the video hardware will reuse it for a later frame (you don't want applications to get a part-decoded frame).

    Cheers, 
    Pete

Children
No data