Mali-400 drivers don't support import texture from DMA-BUF

If I understand this right

You added this feature to mali 600 drivers but not to mali 400 right ?

Can you add this feature as nice to backport, thx

as mali 450 is pretty new product for example

Hi m][sko,

I am a little confused by your last statement.

Can you confirm what exactly you meant by "this feature"?

Assuming I understood correctly, the Utgard range of GPU's (Mali-400/450 for example) do indeed support UMP.

I hope that helps, please let us know if you have any further questions.

Kind Regards,

Michael McGeagh

But eglCreateImageKHR with EGL_LINUX_DMA_BUF_EXT

is not supported in mali400 drivers only mali600+ drivers support it

mali 400 support eglCreateImageKHR with UMP

but latest drivers internally use DMA_BUF.

This is how I understand Peter response

I don't think Pete's suggestion can be used to achieve the equivalent of EGL_LINUX_DMA_BUF_EXT.

Sure, we could invent some API that lets us create a dma-buf from a UMP handle.

But then how can we pass that "fake" dma-buf into the Mali-400 libEGL/libGLESv2 implementation if it does not support the EXT_image_dma_buf_import API at all?

I think Pete was suggesting the opposite, creating a ump handle for a dma_buf and passing that to GLES as it supports UMP images. Not sure if this is possible everywhere but its a potential workaround.

Hth,

Chris

Oh, OK. Still, similar dilemma.

Lets say I have image data in a dma-buf. I write an interface to give me a UMP handle for that dma-buf. OK so far.

Now I have an appropriate UMP handle in my application. How can I get a GL texture that refers to that UMP memory? What is the API for that?

So the answer to that question depends on whether you're using FBDEV or X11... My understanding (potentially wrong!) for FBDEV...

eglCreateImageKHR(dpy, ctx, EGL_NATIVE_PIXMAP_KHR, (EGLClientBuffer)ump_handle, attrib_list);

We basically hijack the EGL_NATIVE_PIXMAP_KHR type because FBDEV doesn't have anything defined for that, and you just pass the ump handle For X11 I'll have to reply once I understand it.

Hth,

Chris

m][sko and I are using the X11 version so we'll be very interested in the results of your investigation.

Very promising to see that there is a way to do it with the fbdev version at least. Thanks for sharing!

Hi dsd,

Discussions are ongoing internally, I've been pointed to some test code which exercises this path and I've raised that with the appropriate team to hopefully feed you back some simple instructions.

Thanks,

Chris

Hi Chris,

Did any code come out of the internal discussion?

I'm still using the UMP version here, but I'm also curious to know if such "UMP import" functionality will work on the r4p0 blob compiled to use dmabufs internally (e.g. VARIANT=mali400-r1p1-gles11-gles20-linux-monolithic-no_profiling-x11-dma_buf)

Hi dsd,

We have an engineer working on verifying the proposed solution as we speak

For dma-buf blobs, based on conversations I've had internally, it would seem the exact same mechanism we are currently verifying can be used (in absence of the proper extension), just replacing a ump handle with a dma-buf one.

Hth,

Chris

Just to update, we hit a bit of a brick wall with UMP as we couldn't find an odroid BSP on their site that would run a simple spinning cube test application, can you let us know what you're using?

We moved on to the more recent dma-buf versions to see if the same mechanism would work there... We have a test module which allocates and exports a dma-buf for us, yay, but best I can tell without DRI3 it's impossible to create an XPixmap from that buffer, unless someone out there could help us out with a method in absence of DRI3?

Thanks,

Chris

Hi Chris, sorry for the slow response. For some reason I don't get emails for my notifications on this site even though my preferences page suggests that I should.

I will get you a relevant ODROID UMP setup as soon as I can. Can you tell me what hardware version of the ODROID you are working with?

For your dma-buf efforts.. can you clarify why you need an X Pixmap here? For pixmaps there is already the texture-from-pixmap extension. In this case the requirement is to create a texture that points at the image data in a dma-buf that is *not* an X pixmap (e.g. it came from the hardware's video decoding unit).