I get this strength issues from ODROID
drivers for Mali-400 don't support
eglCreateImageKHR with EGL_LINUX_DMA_BUF_EXT
?
but drivers internaly use DMA_BUF
any reason or workaround for this for this?
And why UMP is supported and DMA_BUF isn't?
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,
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).
Another engineer is working on this so I will let them give details of the platform, although i expect it is a U2. From what I have been told (and what we are trying to test) in an x11-dmabuf mali system the eglCreateImageKhr call is expecting an XPixmap to be passed which internally contains the dma-buf handle (potentially coming from other hardware units as you describe), and the driver will grab the handle from that pixmap. However, we can't work out how to create a pixmap from a dma-buf handle without DRI3 to test it. Does this make sense?
I see. Did some more research about that.
Indeed the whole point of DRI3 is that you can now create an X pixmap from a dmabuf file descriptor, and in that sense, perhaps eglCreateImageKHR(EGL_NATIVE_PIXMAP_KHR) could be used to create a GL texture that corresponds to that dmabuf. It would be really cool if Mali-400 supported DRI3 and maybe one day I'll create a thread about that...
But back to the present day and the present request. This request is about EGL_LINUX_DMA_BUF_EXT, which has already become common in the wild and is even implemented (AFAIK) on Mali-6xx.
You can read the full description of this API here: https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
As you can see, with this API you can just pass the raw file descriptor in the attribute list. No need to deal with pixmaps. That documentation does not even mention the word "pixmap".
By the way, we recently extended our team here with a DRI expert, so feel free to continue prodding if there are ways we can help you make progress.
I will work on making you a relevant ODROID-U2 image so that we can continue exploring the UMP side of this.
Understood on the dmabuf import extension, obviously this is the preferable mechanism on systems that expose it! The mali400 driver has this on trunk and will be in a future release. The xpixmap mechanism is a potential alternative for systems which do not currently have the dmabuf import mechanism, which is why we were looking at it to hopefully provide dma-buf support in the mean time. Sorry for any confusion I might have caused there. I believe UMP is now the focus at our end
Oh, that is excellent news. Thanks for sharing that.
And indeed, I can believe that there is no obvious way to feed a dmabuf into the current released version. Creating a X pixmap that corresponds to a dmabuf is something that really requires DRI3, as that really was the sole purpose for which DRI3 was developed.
Still interested in the UMP approach so I'll get an odroid-u2 test image to you hopefully next week.
Hi,
Here's an image you can use for exploring what is possible with UMP. It will work with ODROID-U2 and ODROID-U3.
It's a full disk image including bootloader, so just flash it to a SD card (8GB or bigger) once decompressed.
When it boots, login as
Username: odroid
Password: odroid
and run "xinit ./desktop.sh" to open X with a single xterm open.
From that terminal you can launch more xterms, etc. I tested that Mali is working with es2gears which is also included.
It also runs a ssh server by default and the serial console will drop you at a root shell. The root password is odroid.
The Mali binary is at /usr/lib/libMali.so built as:
VARIANT=mali400-r1p1-gles11-gles20-linux-monolithic-no_profiling-x11-ump-umplock
You can install more packages with apt-get as root, this is based on Ubuntu.
Hopefully this environment will let you explore your ideas with UMP. Please let me know if there are any questions/issues with the image or how else we can be of help.
Thanks!
Hi DSD,
I've been working on this at our end. With DMA_BUF, I can confirm that without the EGL_LINUX_DMA_BUF_EXT you need DRI3 to be able to create an xPixmap from which an eglImage can be generated, but this isn't currently available on the platform. EGL_LINUX_DMA_BUF_EXT is, however, going to be present in the next driver release.
I'm still actively looking into the possibility of using UMP for a similar purpose and will get back to you when I know anything more. In the meantime, please let me know if there's anything else.
Rich
Having looked into UMP it is not currently possible to create an eglImage from a ump handle and, given that DMA has superseded UMP, I would strongly suggest waiting for EGL_LINUX_DMA_BUF_EXT which will be available in the coming months with the next release of the driver.
Hope this helps,
Thanks a lot for checking, your answer is totally understandable. Glad to hear that EGL_LINUX_DMA_BUF_EXT is coming!
In this new version, will EGL_LINUX_DMA_BUF_EXT be available when Mali is compiled to use UMP internally, e.g. as VARIANT=mali400-r1p1-gles11-gles20-linux-monolithic-no_profiling-x11-ump-umplock ?
Or will the dmabuf import functionality only be available for Mali setups where dmabuf is used internally? I would love to switch to that.
To use the EGL_LINUX_DMA_BUF_EXT the DDK must be built for dma-buf, not ump and so you would need to switch over to use it.
I'll be happy to move over to your thread and assist you there if you're happy that this one is finished .
Hope this Helps,
Yep, I agree this one is finished. Thanks!
I would like to know how to convert a dmabuf to a pixmap via dri3 method. I've been searching online but failed to find an example of this. I need the pixmap to be used in present_pixmap in order to flip my buffer to the screen.
Any help here will be appreciated.