libMali build for DMA-BUF

dsd · Post by **dsd** » Wed Feb 12, 2014 9:10 pm

Hi,

I'm working on bringing a KMS/DRM X11 driver to this platform.
Actually making good progress, working around various Mali issues: https://github.com/dsd/xf86-video-armsoc/
I'll be posting more detailed info on that once I have fixed the last couple of crashes and rendering bugs.

While reporting one of the Mali issues to ARM, they informed me that actually libMali can be built with DMA-BUF support, which would go hand in hand with the DRM graphics driver on the kernel side. Would it be possible for hardkernel to build libMali in this way for this project? http://community.arm.com/message/16417#16417

Post by **odroid** » Wed Feb 12, 2014 11:09 pm

Hi dsd!
Long time no see in this forum. How are you?

BTW, we will get the latest Mali DDK r4p0 in early March from Samsung & ARM.
We will try to use the DMA-BUF instead of UMP when we build it.

LiquidAcid · Post by **LiquidAcid** » Wed Feb 12, 2014 11:18 pm

Hey Daniel,

I've been following your work. I got a question though. Where exactly does the UMP handle get transferred between the DDX and libMali?

Also I was under the impression that libMali already supported dmabuf, at least in the EGL part (so in the sense that you can call eglCreateImageKHR with EGL_LINUX_DMA_BUF_EXT).

Anyway, nice work on the driver. Now it would be really nice to have the G2D block working, so that you can blit/scale buffers around (nearly) for free.

dsd · Post by **dsd** » Wed Feb 12, 2014 11:33 pm

odroid: thanks. When you get r4p0 it might be worth building it twice, once for UMP (for existing setups) and once for DMA-BUF (for my experiment).

LiquidAcid: the UMP handle is referenced by a "UMP secure ID". DDX now gets this from the kernel's GEM allocation (https://gist.github.com/dsd/8fe8b84fe53e2b0688f5). When libMali comes along later and asks for DRI2 buffers, the DDX puts the UMP secure ID in the DRI2 buffer name field (https://github.com/dsd/xf86-video-armso ... 3cfb026fdb).

The method of passing UMP ID in DRI2 buffer name for DDX-to-libMali communication is actually the same as fbturbo/xf86-video-mali.

LiquidAcid · Post by **LiquidAcid** » Thu Feb 13, 2014 12:14 am

Ah OK, so the convention to use the name entry of the DRI2BufferRec struct to store the handle (or the ref to the handle, I never understood why you need to dereferences here?!) is specific to the Mali driver.
It makes sense that they statically link to the (client) DRI2 library then.

dsd · Post by **dsd** » Thu Feb 13, 2014 12:19 am

The concept is not really Mali-specific.

"Normal" DRI2 drivers use the name field to pass a GEM name here. A GEM name is an integer that refers to a specific memory allocation that was made via GEM. In this case, s/GEM/UMP/ and we have something really similar. (just technically UMP can go away now, no need to re-invent the wheel when working with GEM)

And this all changes again in some way when working with dmabufs, I'll have to read up about that.

Interesting presentation which touches on this: https://www.youtube.com/watch?v=TDIvSIUQnEY

LiquidAcid · Post by **LiquidAcid** » Thu Feb 13, 2014 12:35 am

I don't think the DRI2 protocol specifies at all what you have to put in the name field:
"This specification assumes a rendering architechture, where an
underlying kernel rendering manager that can provide 32 bit integer
handles to video memory buffers. These handles can be passed between
processes, which, through a direct rendering driver, submit rendering
to the kernel rendering manager, targeting and/or sourcing from these
buffers. This extension provides a means to communicate about such
buffers as associated with an X drawable.

The details of how the a direct rendering driver use the buffer names
and submit the rendering requests is outside the scope of this
specification. However, Appendix B does discuss implementation of
this specification on the Graphics Execution Manager (GEM)."
(also see dri2 proto specs).

You pass handles around with it, what kind of handle isn't defined. It depends on what (DRI2) drivers your DDX should interact with. So in this regard, the choice to use UMP handles _is_ in fact Mali specific (EDIT: in the same way it's specific for the Intel driver to pass GEM handles around).

dsd · Post by **dsd** » Thu Feb 13, 2014 12:38 am

agreed, was just pointing out that the scheme of using the buffer name for this purpose is not strange in any way. Maybe you realised that already.

LiquidAcid · Post by **LiquidAcid** » Thu Feb 13, 2014 12:43 am

Sure, I was just getting at that there is no "generic" way to pass around buffers, in the sense that it universally works. In that regard DRI2 is completly broken.

This is different to the (upcoming) DRI3/DRI3000 specs, which explicitly say:
"The direct rendered buffers are passed across the protocol via
standard POSIX file descriptor passing mechanisms. On Linux, these
buffers are DMA-BUF objects."

So, when you're on Linux, and you use the DRI3 interface, everything is dmabuf. Which I find very elegant.

Post by **mdrjr** » Thu Feb 13, 2014 12:57 am

Just to pass by.. r4p0 does use DMA-BUF instead of UMP.
UMP is still present but r4p0 takes DMA-BUF as default.

With r4p0 we can have a single blob for X11/FB acceleration..

Works like T6xx series..

AreaScout · Post by **AreaScout** » Thu Feb 13, 2014 4:18 am

mdrjr wrote: With r4p0 we can have a single blob for X11/FB acceleration..

Yeah ! These are really good news

AreaScout · Post by **AreaScout** » Tue Feb 18, 2014 4:35 am

@dsd

i tried your xf86-video-armsoc and it seems to fail on my Ubuntu 14.04, while the xf86-video-armsoc-exynos from the apt sources works, whats the differents ?

Here is the part of Xorg log where it fails, i know it's still in development but maybe it is usefull:

Code: Select all

[     8.478]    ABI class: X.Org Video Driver, version 15.0
[     8.478] (II) Loading sub module "fb"
[     8.478] (II) LoadModule: "fb"
[     8.478] (II) Loading /usr/lib/xorg/modules/libfb.so
[     8.479] (II) Module fb: vendor="X.Org Foundation"
[     8.479]    compiled for 1.15.0, module version = 1.0.0
[     8.479]    ABI class: X.Org ANSI C Emulation, version 0.4
[     8.479] (--) Depth 24 pixmap format is 32 bpp
[     8.479] (EE) _CREATE_GEM({height: 1080, width: 1920, bpp: 32 buf_type: 0x0}
) failed. errno: 22 - Invalid argument
[     8.479] (EE) ARMSOC(0): ERROR: Cannot allocate scanout buffer

[     8.479] (EE)
Fatal server error:
[     8.479] (EE) AddScreen/ScreenInit failed for driver 0
[     8.479] (EE)
[     8.479] (EE)
Please consult the The X.Org Foundation support
         at http://wiki.x.org
 for help.
[     8.479] (EE) Please also check the log file at "/var/log/Xorg.0.log" for ad
ditional information.
[     8.479] (EE)

RG

dsd · Post by **dsd** » Tue Feb 18, 2014 4:41 am

my modifications to xf86-video-armsoc require kernel and xserver modifications. I recommend waiting until I have it working this end, then I will post details.

AreaScout · Post by **AreaScout** » Tue Feb 18, 2014 5:43 am

i thought so, thx for clearing this up can't wait to see the result

RG

dsd · Post by **dsd** » Tue Apr 08, 2014 1:32 am

if you're still interested in trying this work (for r3p2) see http://forum.odroid.com/viewtopic.php?f=8&t=4391
hopefully to become obsoleted by a better r4p0 solution very soon...

dsd · Post by **dsd** » Fri Apr 25, 2014 5:16 am

LiquidAcid wrote:Also I was under the impression that libMali already supported dmabuf, at least in the EGL part (so in the sense that you can call eglCreateImageKHR with EGL_LINUX_DMA_BUF_EXT).

we looked at this closely today, it seems like none of the published Mali-400 drivers can do a dma-buf import with the EGL_EXT_image_dma_buf_import extension, not even r4p0 which uses dmabuf internally for memory management

miskol · Post by **miskol** » Mon Aug 04, 2014 7:36 am

any progress with drivers and dma-buf
tizen site also had wayland drivers
that will be also interesting

memeka · Post by **memeka** » Mon Aug 04, 2014 7:58 am

mali r4p0 drivers have been out for a while, and they use dma-buf internally.

miskol · Post by **miskol** » Tue Aug 05, 2014 7:08 pm

but I want to import Image(dma-buf) to EGL
I want to use eglCreateImageKHR with EGL_LINUX_DMA_BUF_EXT

dsd · Post by **dsd** » Tue Aug 05, 2014 7:10 pm

you can't with Mali-4xx - i suggest creating a thread on the ARM connected community forums requesting it. let them know what their users are looking for...

miskol · Post by **miskol** » Sat Aug 09, 2014 3:42 am

I hope that I will get answer

http://community.arm.com/thread/6378

OverSun · Post by **OverSun** » Sat Aug 09, 2014 5:20 am

Pfft, they will just kick you back to the vendor and tell you that this depends on how vendor build the library they provide them to build.
I tried to do the same talks on Imagination forum about the linux support, and the guys there absolutely 100% sure that Linux is fully supported and everybody around is happy and shit butterflies because of their products. And if something is not working - this is vendor problem who doesn't provide consumer with the correct libraries they ship to vendor.

miskol · Post by **miskol** » Sat Aug 16, 2014 12:24 am

I am not sure but
is it possible to query opengl/egl if it support some feature?
as I think some kind query api was support in big OPENGL
btw
Who build this drivers?
samsung or odroid?

Post by **mdrjr** » Sat Aug 16, 2014 1:24 am

We hardkernel build the drivers.. what function you want to know ?

miskol · Post by **miskol** » Sat Aug 16, 2014 6:45 am

We want to alocate dma buf as texture in egl/opengl
Look at couple posts back
Thx

Post by **mdrjr** » Sat Aug 16, 2014 6:51 am

Not supported.

miskol · Post by **miskol** » Sat Aug 16, 2014 7:52 pm

And can you contact your arm support which version drivers/gpu support this feature.
As samsung use this for zero copy decoding => rendering in chromebook
I rise this problem on mali support forum and I get usual answer

Post by **mdrjr** » Sun Aug 17, 2014 3:41 am

This feature won't be supported on Mp400 drivers. They are completely different from the drivers on the Chromebook and XU3 for example that does support it.

I'll ping ARM once again about it.. ping here in a month or so..

miskol · Post by **miskol** » Sun Aug 17, 2014 7:09 pm

We got the answer
http://community.arm.com/thread/6378
It wasn't implemented in mali 400 drivers
UMP is good enough for mali 400 drivers

miskol · Post by **miskol** » Fri Aug 22, 2014 5:07 pm

wow
it looks like there is light at the end of the tunnel
And they will add this extension

http://community.arm.com/thread/6378

dsd · Post by **dsd** » Fri Aug 22, 2014 5:51 pm

is that the right URL? because reading that i don't come away with the same conclusion.

miskol · Post by **miskol** » Fri Aug 22, 2014 5:58 pm

I said there is light

small but still light.
I hope that mcgeagh is somebody that can push it and it isn't complicate feature.
they have it already in mali 600+ drivers

miskol · Post by **miskol** » Fri Aug 22, 2014 6:49 pm

dsd wrote:is that the right URL? because reading that i don't come away with the same conclusion.

And I think that his idea passing DMA-BUF as UMP isn't bad
I am not sure but UMP can be switched to DMA-BUF mode
and then you can map UMP(masked DMA-BUF) to EGL
mali have different extension for this

LiquidAcid · Post by **LiquidAcid** » Sat Aug 23, 2014 4:57 am

Then let us consider this simple example: Driver X exports a buffer through a dmabuf handle. I now want to use this buffer as output for a render operation in my EGL/GLES application. How would I import the handle so that I can work with an EGLImage object?

dsd · Post by **dsd** » Fri Oct 10, 2014 6:32 am

The ARM thread has pretty much closed now. There's no way to do that on the current released drivers, not for dma-buf nor for UMP, and that is not totally surprising to me.
But the the surprising and good news is that EGL_LINUX_DMA_BUF_EXT support will be included in the next release, which allows for exactly what LiquidAcid and miskol were asking for.
https://www.khronos.org/registry/egl/ex ... import.txt

librehat · Post by **librehat** » Mon Oct 27, 2014 4:06 am

That's an exciting news. Hopefully, it would address "eglCreateImageKHR failed" issues on Compiz.

Waiting for both new Mali driver and new Linux kernel now.

memeka · Post by **memeka** » Mon Oct 27, 2014 6:51 am

EGL Compiz? Where from?

librehat · Post by **librehat** » Mon Oct 27, 2014 8:51 pm

I uses 0.9.x source from Ubuntu. I remembered it has supported EGL since two years ago.

memeka · Post by **memeka** » Tue Oct 28, 2014 6:16 am

hmmm, i don;t remember that... but good luck

librehat · Post by **librehat** » Tue Oct 28, 2014 7:40 pm

it has indeed. and i compiled successfully. however, there is an error, as mentioned, "eglCreateImageKHR failed". i think it's associated with the missing of that EGL extension, which should be solved with next version of mali driver.

dsd · Post by **dsd** » Tue Oct 28, 2014 10:19 pm

eglCreateImageKHR to create a texture from an X pixmap ("TextureFromPixmap") is already working so i imagine the issue you are seeing is different

librehat · Post by **librehat** » Wed Oct 29, 2014 4:59 am

dsd wrote:eglCreateImageKHR to create a texture from an X pixmap ("TextureFromPixmap") is already working so i imagine the issue you are seeing is different

I don't know anything about OpenGL (or EGL). But I think it could be using eglCreateImageKHR to create texture from other sources and failed. Correct me if I'm wrong.

dsd · Post by **dsd** » Wed Oct 29, 2014 5:06 am

i think its unlikely in this case, but it could be; would be easy enough for you to check the value of the "target" parameter.

librehat · Post by **librehat** » Wed Oct 29, 2014 6:57 pm

Thank you. It's pixmap... I checked the source code file texture.cpp.

So if it's supported, why would this fail?

Code: Select all

    eglImage = GL::createImage (eglGetDisplay (screen->dpy ()),
                                EGL_NO_CONTEXT, EGL_NATIVE_PIXMAP_KHR,
                                (EGLClientBuffer)pixmap, img_attribs);

    if (eglImage == EGL_NO_IMAGE_KHR)
    {
	compLogMessage ("core", CompLogLevelWarn,
			"eglCreateImageKHR failed");

	return GLTexture::List ();
    }