libMali build for DMA-BUF
-
- Posts: 61
- Joined: Wed Nov 06, 2013 12:53 am
- languages_spoken: english
- Has thanked: 0
- Been thanked: 0
- Contact:
libMali build for DMA-BUF
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
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
- odroid
- Site Admin
- Posts: 39406
- Joined: Fri Feb 22, 2013 11:14 pm
- languages_spoken: English, Korean
- ODROIDs: ODROID
- Has thanked: 2623 times
- Been thanked: 1432 times
- Contact:
Re: libMali build for DMA-BUF
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.
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.
-
- Posts: 1094
- Joined: Fri Oct 11, 2013 11:07 pm
- languages_spoken: english
- ODROIDs: X2
- Has thanked: 0
- Been thanked: 2 times
- Contact:
Re: libMali build for DMA-BUF
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.
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.
-
- Posts: 61
- Joined: Wed Nov 06, 2013 12:53 am
- languages_spoken: english
- Has thanked: 0
- Been thanked: 0
- Contact:
Re: libMali build for DMA-BUF
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: 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.
-
- Posts: 1094
- Joined: Fri Oct 11, 2013 11:07 pm
- languages_spoken: english
- ODROIDs: X2
- Has thanked: 0
- Been thanked: 2 times
- Contact:
Re: libMali build for DMA-BUF
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.
It makes sense that they statically link to the (client) DRI2 library then.
-
- Posts: 61
- Joined: Wed Nov 06, 2013 12:53 am
- languages_spoken: english
- Has thanked: 0
- Been thanked: 0
- Contact:
Re: libMali build for DMA-BUF
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
"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
-
- Posts: 1094
- Joined: Fri Oct 11, 2013 11:07 pm
- languages_spoken: english
- ODROIDs: X2
- Has thanked: 0
- Been thanked: 2 times
- Contact:
Re: libMali build for DMA-BUF
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).
"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).
Last edited by LiquidAcid on Thu Feb 13, 2014 12:39 am, edited 1 time in total.
-
- Posts: 61
- Joined: Wed Nov 06, 2013 12:53 am
- languages_spoken: english
- Has thanked: 0
- Been thanked: 0
- Contact:
Re: libMali build for DMA-BUF
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.
-
- Posts: 1094
- Joined: Fri Oct 11, 2013 11:07 pm
- languages_spoken: english
- ODROIDs: X2
- Has thanked: 0
- Been thanked: 2 times
- Contact:
Re: libMali build for DMA-BUF
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.
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.
-
- Site Admin
- Posts: 11817
- Joined: Fri Feb 22, 2013 11:34 pm
- languages_spoken: english, portuguese
- ODROIDs: -
- Location: Brazil
- Has thanked: 1 time
- Been thanked: 51 times
- Contact:
Re: libMali build for DMA-BUF
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..
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..
-
- Posts: 1842
- Joined: Sun Jul 07, 2013 3:05 am
- languages_spoken: german, english
- ODROIDs: X2, U3, XU3, C2, HiFi Shield, XU4, XU4Q,
N1, Go, VU5A, Show2, CloudShell2,
H2, N2, VU7A, VuShell, Go2, C4 - Has thanked: 132 times
- Been thanked: 396 times
- Contact:
Re: libMali build for DMA-BUF
Yeah ! These are really good newsmdrjr wrote: With r4p0 we can have a single blob for X11/FB acceleration..

-
- Posts: 1842
- Joined: Sun Jul 07, 2013 3:05 am
- languages_spoken: german, english
- ODROIDs: X2, U3, XU3, C2, HiFi Shield, XU4, XU4Q,
N1, Go, VU5A, Show2, CloudShell2,
H2, N2, VU7A, VuShell, Go2, C4 - Has thanked: 132 times
- Been thanked: 396 times
- Contact:
Re: libMali build for DMA-BUF
@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:
RG
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)
-
- Posts: 61
- Joined: Wed Nov 06, 2013 12:53 am
- languages_spoken: english
- Has thanked: 0
- Been thanked: 0
- Contact:
Re: libMali build for DMA-BUF
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.
-
- Posts: 1842
- Joined: Sun Jul 07, 2013 3:05 am
- languages_spoken: german, english
- ODROIDs: X2, U3, XU3, C2, HiFi Shield, XU4, XU4Q,
N1, Go, VU5A, Show2, CloudShell2,
H2, N2, VU7A, VuShell, Go2, C4 - Has thanked: 132 times
- Been thanked: 396 times
- Contact:
Re: libMali build for DMA-BUF
i thought so, thx for clearing this up can't wait to see the result 
RG

RG
-
- Posts: 61
- Joined: Wed Nov 06, 2013 12:53 am
- languages_spoken: english
- Has thanked: 0
- Been thanked: 0
- Contact:
Re: libMali build for DMA-BUF
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...
hopefully to become obsoleted by a better r4p0 solution very soon...
-
- Posts: 61
- Joined: Wed Nov 06, 2013 12:53 am
- languages_spoken: english
- Has thanked: 0
- Been thanked: 0
- Contact:
Re: libMali build for DMA-BUF
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 managementLiquidAcid 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).

-
- Posts: 267
- Joined: Wed Jan 15, 2014 2:58 am
- languages_spoken: english,slovak
- ODROIDs: XU4,C1,C2,N2,C4
- Has thanked: 1 time
- Been thanked: 25 times
- Contact:
Re: libMali build for DMA-BUF
any progress with drivers and dma-buf
tizen site also had wayland drivers
that will be also interesting
tizen site also had wayland drivers
that will be also interesting
- memeka
- Posts: 4420
- Joined: Mon May 20, 2013 10:22 am
- languages_spoken: english
- ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART - Has thanked: 2 times
- Been thanked: 60 times
- Contact:
Re: libMali build for DMA-BUF
mali r4p0 drivers have been out for a while, and they use dma-buf internally.
Images: U2/U3 Trusty Dev Center | XU Trusty Dev Center | XU4 Hipster Stretchy Pants
Information: U2/U3 Dashboard | XU Dashboard
Say thank you with a beer
Information: U2/U3 Dashboard | XU Dashboard
Say thank you with a beer
-
- Posts: 267
- Joined: Wed Jan 15, 2014 2:58 am
- languages_spoken: english,slovak
- ODROIDs: XU4,C1,C2,N2,C4
- Has thanked: 1 time
- Been thanked: 25 times
- Contact:
Re: libMali build for DMA-BUF
but I want to import Image(dma-buf) to EGL
I want to use eglCreateImageKHR with EGL_LINUX_DMA_BUF_EXT
I want to use eglCreateImageKHR with EGL_LINUX_DMA_BUF_EXT
-
- Posts: 61
- Joined: Wed Nov 06, 2013 12:53 am
- languages_spoken: english
- Has thanked: 0
- Been thanked: 0
- Contact:
Re: libMali build for DMA-BUF
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...
- OverSun
- Posts: 1493
- Joined: Mon Apr 29, 2013 5:12 pm
- languages_spoken: english
- Has thanked: 0
- Been thanked: 19 times
- Contact:
Re: libMali build for DMA-BUF
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.
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.
-
- Posts: 267
- Joined: Wed Jan 15, 2014 2:58 am
- languages_spoken: english,slovak
- ODROIDs: XU4,C1,C2,N2,C4
- Has thanked: 1 time
- Been thanked: 25 times
- Contact:
Re: libMali build for DMA-BUF
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?
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?
-
- Posts: 267
- Joined: Wed Jan 15, 2014 2:58 am
- languages_spoken: english,slovak
- ODROIDs: XU4,C1,C2,N2,C4
- Has thanked: 1 time
- Been thanked: 25 times
- Contact:
Re: libMali build for DMA-BUF
We want to alocate dma buf as texture in egl/opengl
Look at couple posts back
Thx
Look at couple posts back
Thx
-
- Posts: 267
- Joined: Wed Jan 15, 2014 2:58 am
- languages_spoken: english,slovak
- ODROIDs: XU4,C1,C2,N2,C4
- Has thanked: 1 time
- Been thanked: 25 times
- Contact:
Re: libMali build for DMA-BUF
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
As samsung use this for zero copy decoding => rendering in chromebook
I rise this problem on mali support forum and I get usual answer

-
- Site Admin
- Posts: 11817
- Joined: Fri Feb 22, 2013 11:34 pm
- languages_spoken: english, portuguese
- ODROIDs: -
- Location: Brazil
- Has thanked: 1 time
- Been thanked: 51 times
- Contact:
Re: libMali build for DMA-BUF
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..
I'll ping ARM once again about it.. ping here in a month or so..
-
- Posts: 267
- Joined: Wed Jan 15, 2014 2:58 am
- languages_spoken: english,slovak
- ODROIDs: XU4,C1,C2,N2,C4
- Has thanked: 1 time
- Been thanked: 25 times
- Contact:
Re: libMali build for DMA-BUF
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
http://community.arm.com/thread/6378
It wasn't implemented in mali 400 drivers
UMP is good enough for mali 400 drivers

-
- Posts: 267
- Joined: Wed Jan 15, 2014 2:58 am
- languages_spoken: english,slovak
- ODROIDs: XU4,C1,C2,N2,C4
- Has thanked: 1 time
- Been thanked: 25 times
- Contact:
Re: libMali build for DMA-BUF
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
it looks like there is light at the end of the tunnel
And they will add this extension

http://community.arm.com/thread/6378
-
- Posts: 61
- Joined: Wed Nov 06, 2013 12:53 am
- languages_spoken: english
- Has thanked: 0
- Been thanked: 0
- Contact:
Re: libMali build for DMA-BUF
is that the right URL? because reading that i don't come away with the same conclusion.
-
- Posts: 267
- Joined: Wed Jan 15, 2014 2:58 am
- languages_spoken: english,slovak
- ODROIDs: XU4,C1,C2,N2,C4
- Has thanked: 1 time
- Been thanked: 25 times
- Contact:
Re: libMali build for DMA-BUF
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

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
-
- Posts: 267
- Joined: Wed Jan 15, 2014 2:58 am
- languages_spoken: english,slovak
- ODROIDs: XU4,C1,C2,N2,C4
- Has thanked: 1 time
- Been thanked: 25 times
- Contact:
Re: libMali build for DMA-BUF
And I think that his idea passing DMA-BUF as UMP isn't baddsd wrote:is that the right URL? because reading that i don't come away with the same conclusion.
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
-
- Posts: 1094
- Joined: Fri Oct 11, 2013 11:07 pm
- languages_spoken: english
- ODROIDs: X2
- Has thanked: 0
- Been thanked: 2 times
- Contact:
Re: libMali build for DMA-BUF
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?
-
- Posts: 61
- Joined: Wed Nov 06, 2013 12:53 am
- languages_spoken: english
- Has thanked: 0
- Been thanked: 0
- Contact:
Re: libMali build for DMA-BUF
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
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
-
- Posts: 29
- Joined: Wed Apr 09, 2014 11:02 pm
- languages_spoken: Chinese; English
- ODROIDs: ODROID-U3
- Location: Ireland
- Has thanked: 0
- Been thanked: 0
- Contact:
Re: libMali build for DMA-BUF
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.
Waiting for both new Mali driver and new Linux kernel now.

- memeka
- Posts: 4420
- Joined: Mon May 20, 2013 10:22 am
- languages_spoken: english
- ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART - Has thanked: 2 times
- Been thanked: 60 times
- Contact:
Re: libMali build for DMA-BUF
EGL Compiz? Where from?
Images: U2/U3 Trusty Dev Center | XU Trusty Dev Center | XU4 Hipster Stretchy Pants
Information: U2/U3 Dashboard | XU Dashboard
Say thank you with a beer
Information: U2/U3 Dashboard | XU Dashboard
Say thank you with a beer
-
- Posts: 29
- Joined: Wed Apr 09, 2014 11:02 pm
- languages_spoken: Chinese; English
- ODROIDs: ODROID-U3
- Location: Ireland
- Has thanked: 0
- Been thanked: 0
- Contact:
Re: libMali build for DMA-BUF
I uses 0.9.x source from Ubuntu. I remembered it has supported EGL since two years ago.
- memeka
- Posts: 4420
- Joined: Mon May 20, 2013 10:22 am
- languages_spoken: english
- ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART - Has thanked: 2 times
- Been thanked: 60 times
- Contact:
Re: libMali build for DMA-BUF
hmmm, i don;t remember that... but good luck
Images: U2/U3 Trusty Dev Center | XU Trusty Dev Center | XU4 Hipster Stretchy Pants
Information: U2/U3 Dashboard | XU Dashboard
Say thank you with a beer
Information: U2/U3 Dashboard | XU Dashboard
Say thank you with a beer
-
- Posts: 29
- Joined: Wed Apr 09, 2014 11:02 pm
- languages_spoken: Chinese; English
- ODROIDs: ODROID-U3
- Location: Ireland
- Has thanked: 0
- Been thanked: 0
- Contact:
Re: libMali build for DMA-BUF
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.
-
- Posts: 61
- Joined: Wed Nov 06, 2013 12:53 am
- languages_spoken: english
- Has thanked: 0
- Been thanked: 0
- Contact:
Re: libMali build for DMA-BUF
eglCreateImageKHR to create a texture from an X pixmap ("TextureFromPixmap") is already working so i imagine the issue you are seeing is different
-
- Posts: 29
- Joined: Wed Apr 09, 2014 11:02 pm
- languages_spoken: Chinese; English
- ODROIDs: ODROID-U3
- Location: Ireland
- Has thanked: 0
- Been thanked: 0
- Contact:
Re: libMali build for DMA-BUF
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

-
- Posts: 61
- Joined: Wed Nov 06, 2013 12:53 am
- languages_spoken: english
- Has thanked: 0
- Been thanked: 0
- Contact:
Re: libMali build for DMA-BUF
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.
-
- Posts: 29
- Joined: Wed Apr 09, 2014 11:02 pm
- languages_spoken: Chinese; English
- ODROIDs: ODROID-U3
- Location: Ireland
- Has thanked: 0
- Been thanked: 0
- Contact:
Re: libMali build for DMA-BUF
Thank you. It's pixmap... I checked the source code file texture.cpp.
So if it's supported, why would this fail?
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 ();
}
Who is online
Users browsing this forum: No registered users and 2 guests