accelerated X?

mikronauts
Posts: 225
Joined: Wed Aug 27, 2014 4:28 am
languages_spoken: english
ODROIDs: odroid-w, odroid c1
Location: Langley, BC, Canada
Contact:

accelerated X?

Unread post by mikronauts » Mon Jan 12, 2015 3:35 am

Hi,

I know you guys are busier than cat-herders :)

I also know it is pretty much impossible to make long term predictions...

BUT (you knew that was coming)

Do you have even a rough idea of when we might see:

1) accelerated X server

2) OpenGL under accelerated X server

Two months? Four? Six? Year?
http://Mikronauts.com ... Home of RoboPi, Pi Rtc Dio, Pi Jumper, EZasPi

User avatar
meveric
Posts: 9679
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: X2, U2, U3, XU-Lite, XU3, XU3-Lite, C1, XU4, C2, C1+, XU4Q, HC1, N1, Go
Contact:

Re: accelerated X?

Unread post by meveric » Mon Jan 12, 2015 5:57 am

more likely a year or a couple of years.
OpenGL is not even supported on ODROID devices.. something that people always mix up... "embedded systems" use OpenGL ES (OpenGL for Embedded Systems) NOT OpenGL... OpenGL is only used on Desktop PCs.
There are SOME boards that slowly going into OpenGL as well.. like the Tegra K1 from Nvidia.. But even they don't have a full OpenGL but to emulate some functions to get OpenGL to work with OpenGL ES functions.
Similar projects already exists that convert OpenGL calls to OpenGL ES calls, like glshim..
But all these projects are for from able to replace Desktop OpenGL anytime soon. So you might have to wait YEARS for that to happen.

In fact, it's more likely that the developers from Desktop Managers like Gnome3 and Unitiy and others are slowly moving to support OpenGL ES as well.. Projects like mesa have to pick up on OpenGL ES as well.

Anyway.. all of this has NOTHING to do with HardKernel.. and is nothing that HardKernel can control.. If you are lucky they might contribute to projects that actually trying to achieve this.
But it's not like you can wait for HardKernel to put this out on their image, since it has nothing to do with what HardKernel does.
Donate to support my work on the ODROID GameStation Turbo Image for U2/U3 XU3/XU4 X2 X C1 as well as many other releases.
Check out the Games and Emulators section to find some of my work or check the files in my repository to find the software i build for ODROIDs.
If you want to add my repository to your image read my HOWTO integrate my repo into your image.

crashoverride
Posts: 4223
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Contact:

Re: accelerated X?

Unread post by crashoverride » Mon Jan 12, 2015 7:00 am

mikronauts wrote:Do you have even a rough idea of when we might see:

1) accelerated X server
That is a somewhat nebulous term since it means different things to different people. For most it means "I want my windows to move around the desktop quickly". Implementing full X11 hardware acceleration would be a waste of effort as most software today uses a toolkit such at GTK or QT to render rather than X11 API calls.

From what I can tell, the Amlogic S805 used in the ODROID-C1 does include a hardware "bitblit" engine called GE2D. It should be possible for someone to implement support for this in the X11 driver; however, there is no public documentation that I could find so that means figuring it out from the available source code in the kernel (and whether it supports the apparently optional memory-to-memory blitting).
mikronauts wrote:2) OpenGL under accelerated X server
A fully compliant OpenGL 2.1 stack is unlikely to ever happen. If it did, it would most likely take the shape of a Gallum3D reverse engineered Mali driver with Mesa performing software emulation of the parts missing from the hardware.

OpenGL ES1.1 and 2.0 are currently available and are currently hardware accelerated under X11.
meveric wrote:more likely a year or a couple of years.
This is the main issue affecting this. ARM boards have very short lifespans. After about two years, something newer and better has come along. The board would be obsolete by the time the project was finished and you would have to start all over on the newer hardware.

Tl;DR = Implementing use of the GE2D in the X11 driver is probably the best use of time and resources. It requires someone with knowledge of X11 server, GE2D, and the Amlogic display driver. The majority of people with this combination of skills are already well paid employees somewhere and unlikely to be concerned with this. ;)

A fully compliant OpenGL 2.1 is never going to happen during the lifespan of the C1.

mikronauts
Posts: 225
Joined: Wed Aug 27, 2014 4:28 am
languages_spoken: english
ODROIDs: odroid-w, odroid c1
Location: Langley, BC, Canada
Contact:

Re: accelerated X?

Unread post by mikronauts » Mon Jan 12, 2015 7:08 am

Thanks guys.

So OpenGL ES is feasible, but will take a while. Fuill OpenGL is a non-starter, except as possible ES + shims.

Accelerated X, which for me as well means hardware bitblit (for fast scrolling of windows, and fast dragging of windows), again, doable, but awaiting documentation and someone with proper access/skills.

I hope both OpenGL ES and an accelerated X.org happen sooner than we think, as there are many things to like about the C1
http://Mikronauts.com ... Home of RoboPi, Pi Rtc Dio, Pi Jumper, EZasPi

crashoverride
Posts: 4223
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Contact:

Re: accelerated X?

Unread post by crashoverride » Mon Jan 12, 2015 7:17 am

mikronauts wrote:So OpenGL ES is feasible, but will take a while.
OpenGL ES is fully hardware accelerated today.

User avatar
memeka
Posts: 4143
Joined: Mon May 20, 2013 10:22 am
languages_spoken: english
ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART
Contact:

Re: accelerated X?

Unread post by memeka » Mon Jan 12, 2015 7:42 am

crashoverride wrote:
mikronauts wrote:So OpenGL ES is feasible, but will take a while.
OpenGL ES is fully hardware accelerated today.

mikronauts
Posts: 225
Joined: Wed Aug 27, 2014 4:28 am
languages_spoken: english
ODROIDs: odroid-w, odroid c1
Location: Langley, BC, Canada
Contact:

Re: accelerated X?

Unread post by mikronauts » Mon Jan 12, 2015 8:46 am

Thanks again guys - and nice OpenGL ES demo.
http://Mikronauts.com ... Home of RoboPi, Pi Rtc Dio, Pi Jumper, EZasPi

crashoverride
Posts: 4223
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Contact:

Re: accelerated X?

Unread post by crashoverride » Mon Jan 12, 2015 5:08 pm

Ran across this
https://github.com/ssvb/xf86-video-fbturbo

It looks like it would be a good starting point for an accelerated X driver. Additionally, it could serve as a template for GE2D acceleration as it uses the G2D hardware in the Allwinner chips that perform the same blit functions.

User avatar
meveric
Posts: 9679
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: X2, U2, U3, XU-Lite, XU3, XU3-Lite, C1, XU4, C2, C1+, XU4Q, HC1, N1, Go
Contact:

Re: accelerated X?

Unread post by meveric » Mon Jan 12, 2015 5:58 pm

sunxi drivers were already tried like 2 years ago.. you can guess what was the result, since they are not used ;)
Donate to support my work on the ODROID GameStation Turbo Image for U2/U3 XU3/XU4 X2 X C1 as well as many other releases.
Check out the Games and Emulators section to find some of my work or check the files in my repository to find the software i build for ODROIDs.
If you want to add my repository to your image read my HOWTO integrate my repo into your image.

crashoverride
Posts: 4223
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Contact:

Re: accelerated X?

Unread post by crashoverride » Mon Jan 12, 2015 6:35 pm

meveric wrote:sunxi drivers were already tried like 2 years ago
A lot has changed since then. I just tried it out and its very responsive at moving windows. However, there are currently 2 issues:
1) Black areas when screen depth is set for 32bit. This, along with other tests I have done point to an issue in the Amlogic framebuffer driver.
2) There is no <ump/ump.h> (ARM Mali unified memory provider) file provided by HardKernel to enable 3D acceleration.

You can try it for yourself using the instructions here:
https://github.com/ssvb/xf86-video-fbtu ... stallation
(Change the screen depth in boot.ini to 16bit to see correct rendering)

[Edit]
If we could get some documentation for the GE2D hardware, we could start adding hardware blit support.

crashoverride
Posts: 4223
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Contact:

Re: accelerated X?

Unread post by crashoverride » Mon Jan 12, 2015 7:18 pm

I borrowed the <ump/ump.h> header files from here
https://github.com/linux-sunxi/libump/tree/master/src

Copied the libUMP.so from /usr/lib/arm-linux-gnueabihf/mali-egl/ to /usr/lib so its found by ldconfig

Recompiled the fbturbo driver and GLES works. (Running in 16bit mode)

Code: Select all

root@odroid:~# es2gears
EGL_VERSION = 1.4 Linux-r4p0-00rel0
vertex shader info:
fragment shader info:
info:
1350 frames in 5.0 seconds = 270.000 FPS
1306 frames in 5.0 seconds = 261.148 FPS
^C

Code: Select all

[  2185.644] (II) FBTURBO(0): using /dev/fb0
[  2185.644] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
[  2185.645] (II) FBTURBO(0): Creating default Display subsection in Screen section
        "Default Screen Section" for depth/fbbpp 16/16
[  2185.645] (==) FBTURBO(0): Depth 16, (==) framebuffer bpp 16
[  2185.645] (==) FBTURBO(0): RGB weight 565
[  2185.645] (==) FBTURBO(0): Default visual is TrueColor
[  2185.645] (==) FBTURBO(0): Using gamma correction (1.0, 1.0, 1.0)
[  2185.645] (II) FBTURBO(0): hardware: OSD FB (video memory: 24576kB)
[  2185.645] (**) FBTURBO(0): Option "fbdev" "/dev/fb0"
[  2185.645] (**) FBTURBO(0): Option "SwapbuffersWait" "true"
[  2185.646] (II) FBTURBO(0): processor: ARM Cortex-A5
[  2185.646] (II) FBTURBO(0): checking modes against framebuffer device...
[  2185.646] (II) FBTURBO(0): checking modes against monitor...
[  2185.646] (--) FBTURBO(0): Virtual size is 1920x1080 (pitch 1920)
[  2185.646] (**) FBTURBO(0):  Built-in mode "current"
[  2185.646] (==) FBTURBO(0): DPI set to (96, 96)
[  2185.646] (II) Loading sub module "fb"
[  2185.646] (II) LoadModule: "fb"
[  2185.647] (II) Loading /usr/lib/xorg/modules/libfb.so
[  2185.647] (II) Module fb: vendor="X.Org Foundation"
[  2185.647]    compiled for 1.15.1, module version = 1.0.0
[  2185.647]    ABI class: X.Org ANSI C Emulation, version 0.4
[  2185.677] (II) FBTURBO(0): using backing store heuristics
[  2185.684] (II) FBTURBO(0): can't load 'g2d_23' kernel module
[  2185.684] (II) FBTURBO(0): failed to enable the use of sunxi display controller
[  2185.685] (II) FBTURBO(0): No sunxi-g2d hardware detected (check /dev/disp and /dev/g2d)
[  2185.685] (II) FBTURBO(0): G2D hardware acceleration can't be enabled
[  2185.685] (II) FBTURBO(0): enabled VFP/NEON optimizations
[  2185.685] (==) FBTURBO(0): Backing store enabled
[  2185.685] (==) FBTURBO(0): DPMS enabled
[  2185.685] (II) FBTURBO(0): failed to enable hardware cursor
[  2185.706] (II) FBTURBO(0): can't load 'sunxi_cedar_mod' kernel module
[  2185.706] (II) Loading sub module "dri2"
[  2185.706] (II) LoadModule: "dri2"
[  2185.706] (II) Module "dri2" already built-in
[  2185.707] (II) FBTURBO(0): display controller hardware overlays can't be used for DRI2
[  2185.707] (II) FBTURBO(0): Wait on SwapBuffers? enabled
[  2185.707] (II) FBTURBO(0): [DRI2] Setup complete
[  2185.707] (II) FBTURBO(0): [DRI2]   DRI driver: lima
[  2185.707] (II) FBTURBO(0): using DRI2 integration for Mali GPU (UMP buffers)
[  2185.707] (II) FBTURBO(0): Mali binary drivers can only accelerate EGL/GLES
[  2185.707] (II) FBTURBO(0): so AIGLX/GLX is expected to fail or fallback to software

User avatar
meveric
Posts: 9679
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: X2, U2, U3, XU-Lite, XU3, XU3-Lite, C1, XU4, C2, C1+, XU4Q, HC1, N1, Go
Contact:

Re: accelerated X?

Unread post by meveric » Mon Jan 12, 2015 7:31 pm

crashoverride wrote:

Code: Select all

[  2185.684] (II) FBTURBO(0): can't load 'g2d_23' kernel module
[  2185.684] (II) FBTURBO(0): failed to enable the use of sunxi display controller
[  2185.685] (II) FBTURBO(0): No sunxi-g2d hardware detected (check /dev/disp and /dev/g2d)
[  2185.685] (II) FBTURBO(0): G2D hardware acceleration can't be enabled
[  2185.706] (II) FBTURBO(0): can't load 'sunxi_cedar_mod' kernel module
I just copied the important lines..
they say you don't have 2D acceleration enabled..
All you have was done before already..
Donate to support my work on the ODROID GameStation Turbo Image for U2/U3 XU3/XU4 X2 X C1 as well as many other releases.
Check out the Games and Emulators section to find some of my work or check the files in my repository to find the software i build for ODROIDs.
If you want to add my repository to your image read my HOWTO integrate my repo into your image.

crashoverride
Posts: 4223
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Contact:

Re: accelerated X?

Unread post by crashoverride » Mon Jan 12, 2015 7:38 pm

meveric wrote:All you have was done before already..
What I have that I did not have before is:
1) accelerated bitblit using the ARM NEON instruction set https://github.com/ssvb/xf86-video-fbtu ... /arm_asm.S
2) a template to "drop in" GE2D hardware blitting should the necessary documentation become available.
3) another test case to show there is a bug in the current Amlogic framebuffer driver (mesonfb) when rendering to 32bit surfaces.

[Edit]
Also https://github.com/ssvb/xf86-video-fbtu ... re_tuner.c

Code: Select all

 * The advantage of backing store is that we can avoid "expose event -> redraw"
* animated trail in the exposed area when dragging another window on top of it.
* Dragging windows becomes much smoother and faster.

NemoN
Posts: 18
Joined: Fri Jan 09, 2015 3:54 am
languages_spoken: english, german
ODROIDs: ODROID C1
Contact:

Re: accelerated X?

Unread post by NemoN » Mon Jan 12, 2015 7:46 pm

Can someone execute this benchmark for me http://html5-benchmark.com on the C1?

User avatar
meveric
Posts: 9679
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: X2, U2, U3, XU-Lite, XU3, XU3-Lite, C1, XU4, C2, C1+, XU4Q, HC1, N1, Go
Contact:

Re: accelerated X?

Unread post by meveric » Mon Jan 12, 2015 9:30 pm

crashoverride wrote: 1) accelerated bitblit using the ARM NEON instruction set https://github.com/ssvb/xf86-video-fbtu ... /arm_asm.S
Once again the code you refering to was last changed in Mar, 2013 (nearly 2 years ago) And people were using these drivers on the ODROID already nearly 2 years ago..
crashoverride wrote: 2) a template to "drop in" GE2D hardware blitting should the necessary documentation become available.
Good luck on that.. Exynos 4412 supports G2D but in the last couple of years there were nearly no progress at all in that field. (although some project actually worked on this)
crashoverride wrote: 3) another test case to show there is a bug in the current Amlogic framebuffer driver (mesonfb) when rendering to 32bit surfaces.
True you confirmed that the drivers are buggy.. which is a known issue and people trying to replace the driver already.. armsoc driver for example allows to change the resolution on the fly without having to reboot the system each time (X,X2,U2,U3,XU3,XU3-Lite are supporting this already - not sure about the XU and XU-Lite).
crashoverride wrote: [Edit]
Also https://github.com/ssvb/xf86-video-fbtu ... re_tuner.c

Code: Select all

 * The advantage of backing store is that we can avoid "expose event -> redraw"
* animated trail in the exposed area when dragging another window on top of it.
* Dragging windows becomes much smoother and faster.
once again, the driver from sunxi is rather old.. even if gets updates every now and then.. It's based on a very old 3.4 Kernel branch and specificly developed for Allwinner Boards (which are similar, but not equal to ODROID Exynos 4412 board).
the fbturbo framebuffer driver is working for years on the ODROIDs already... it's just not used since it was found to have other issues..
I think the mali drivers they use with sunxi are based on are a r3p2 while we hope to get r5 soon which hopefully will solve some issues.

It's good for experimenting and in some cases it gives better framerates than with the mali drivers..

Anyway.. I wish you good luck with it.. maybe you can figure out how to get GE2D to work that would be really good.. Or you can figure out a way to port certain features into the mali drivers.
You should definitely take a look at the sunxi kernel, without that you can't use the features of fbturbo, as you've seen in the logs.
Donate to support my work on the ODROID GameStation Turbo Image for U2/U3 XU3/XU4 X2 X C1 as well as many other releases.
Check out the Games and Emulators section to find some of my work or check the files in my repository to find the software i build for ODROIDs.
If you want to add my repository to your image read my HOWTO integrate my repo into your image.

crashoverride
Posts: 4223
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Contact:

Re: accelerated X?

Unread post by crashoverride » Tue Jan 13, 2015 6:08 am

meveric wrote:And people were using these drivers on the ODROID already nearly 2 years ago..
The ODROID C1 did not exist 2 years ago for anyone to try this driver on. The processor (Cortex A5) and display controller (mesonfb) are different from any other ODROID products. These are the the only two parts that matter for X11 acceleration. Unlike desktop PC's, the GPU (ARM Mali 450) is never used for X11 acceleration because desktop OpenGL is not available.
meveric wrote:Good luck on that..
This point was to explore accelerated X11 options available today and determine the scope of work involved in create an accelerated driver for "tomorrow". The fbturbo driver means most of the engineering work has already been done and its a matter of replacing G2D API calls with equivalent GE2D API calls. Both IP blocks perform the exact same function: blitting.

After testing the fbturbo driver, I find it provides a sufficiently improved X11 experience for my needs and I will continue to use it as-is. If documentation became available, I would look into adding GE2D support. However, X11 is a dying API. There is not much incentive on anyone's part to progress driver maturity since everyone is now looking towards Wayland/Weston.
meveric wrote:True you confirmed that the drivers are buggy.
This is arguably the most important observation that came of this endeavor. This affects everyone regardless of whether they use X11, Wayland, or just the framebuffer directly. The issue manifests with the stock 'fbdev' X11 driver and that means its easily and consistently reproducible.
meveric wrote:I think the mali drivers they use with sunxi are based on are a r3p2 while we hope to get r5 soon which hopefully will solve some issues.
Again, the mali drivers (Mali.so) are irrelevant. They do not form any part of the fbturbo driver. libUMP is used to share a block of memory with the Mali GPU thereby enabling GLES surface display. The version of it provided in the ubuntu image is the one that is used. This is evident from the output of the es2gears log I posted that shows "1.4 Linux-r4p0-00rel0". Changing libUMP or Mali.so does not require recompiling the fbturbo driver.

crashoverride
Posts: 4223
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Contact:

Re: accelerated X?

Unread post by crashoverride » Tue Jan 13, 2015 6:19 am

Addendum:
Until the mesonfb driver bug is corrected. There is no point in anyone using the fbturbo driver over the current driver. The display is unusable in 32bit mode.

crashoverride
Posts: 4223
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Contact:

Re: accelerated X?

Unread post by crashoverride » Tue Jan 13, 2015 12:35 pm

As a workaround, I found you can set the display color depth to 24 in boot.ini and everything works.

Code: Select all

# HDMI BPP Mode
#setenv m_bpp "32"
#setenv m_bpp "16"
setenv m_bpp "24"

Apokalypz
Posts: 178
Joined: Thu Dec 26, 2013 12:58 pm
languages_spoken: english
ODROIDs: • Odroid -XU
• Odroid-C1
Location: USA
Contact:

Re: accelerated X?

Unread post by Apokalypz » Tue Jan 13, 2015 10:03 pm

What about GLamor? It uses opengl/opengles to accelerate 2D operations. In the x86 arena, its not very useful as every GPU has some sort of 2D acceleration in hardware, but for ARM it seems like something to look into. From what I read, it is officially implemented in Xorg 1.16 which is what the current C1 image is at.

The only thing is, I did research on how the Mali ddx driver does its "2D acceleration" and it seems to do things in a similar way, by hooking 2D requests into 3D. So I don't know if GLamor will actually be of any use to us...just though I should bring it up.

crashoverride
Posts: 4223
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Contact:

Re: accelerated X?

Unread post by crashoverride » Wed Jan 14, 2015 9:24 am

Apokalypz wrote:What about GLamor?
I looked into that http://www.freedesktop.org/wiki/Software/Glamor/
This package can support every platform which has OpenGL and gbm and drm libraries.
After looking at the code, there are other dependencies not stated. Specifically, it will only work on a system that provides Mesa custom extensions.
http://cgit.freedesktop.org/xorg/driver ... egl.c#n161

Currently the libEGL depends on X11. So we would end up with X11 depending on EGL which depends on X11. At the very least, that means we would need a framebuffer version of EGL that we do not currently have.

In conclusion, its not impossible. It would just take more engineering, cooperation, and porting (a LOT of porting) effort than its worth in my opinion. Right now, i am using the fbturbo driver and doing testing/development "on-device" with code::blocks and the experience is perfectly acceptable as far as X11 UI responsiveness goes. Windows appear, dissappear and scroll as expected smoothly.

User avatar
memeka
Posts: 4143
Joined: Mon May 20, 2013 10:22 am
languages_spoken: english
ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART
Contact:

Re: accelerated X?

Unread post by memeka » Wed Jan 14, 2015 10:02 am

@crashoverride: can you try this http://forum.odroid.com/viewtopic.php?f=29&t=8393 ?
see if gala works in fbturbo?

crashoverride
Posts: 4223
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Contact:

Re: accelerated X?

Unread post by crashoverride » Wed Jan 14, 2015 10:17 am

memeka wrote: can you try this
Regretfully, due to compatibility issues with C1, I don't have working SDCards to spare at the moment. However, compiling the fbturbo driver yourself for Debian based platforms is easy if you following the instructions at the link for it earlier in this topic. The driver is tied to the version of X11 of the target, so its not possible to just provide a universal binary. For example, Debian Wheezy uses a different X11 ABI than Ubuntu 14.04.

User avatar
memeka
Posts: 4143
Joined: Mon May 20, 2013 10:22 am
languages_spoken: english
ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART
Contact:

Re: accelerated X?

Unread post by memeka » Wed Jan 14, 2015 3:24 pm

i could not get opengl-es to work with fbturbo... did you?

crashoverride
Posts: 4223
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Contact:

Re: accelerated X?

Unread post by crashoverride » Wed Jan 14, 2015 5:11 pm

memeka wrote:i could not get opengl-es to work with fbturbo... did you?
Yes.

You need the libump header files from here:
https://github.com/linux-sunxi/libump

Code: Select all

autoreconf -i
./configure
sudo mkdir /usr/include/ump
sudo cp ./src/*.h /usr/include/ump/.
(Do not do "make install". All you want are the header files)

Then copy the system libUMP.so to the /usr/lib folder so that its linkable. Then ldconfig to update the system cache.
You can then ./configure and make the fbturbo driver. Note that ./configure will show that libUMP was found and is usable.

You may also have to copy libMali.so and the symlinks libEGL.so and libGLESv2.so to /usr/lib.

Sorry for not being more exact in the last part of the instructions, but I dont have the C1 at hand to be more specific.

User avatar
memeka
Posts: 4143
Joined: Mon May 20, 2013 10:22 am
languages_spoken: english
ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART
Contact:

Re: accelerated X?

Unread post by memeka » Wed Jan 14, 2015 5:30 pm

yes, i forgot about libUMP :D
you can get the r4p0 headers right from mali website actually.

crashoverride
Posts: 4223
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Contact:

Re: accelerated X?

Unread post by crashoverride » Wed Jan 14, 2015 5:51 pm

The compiler only needs the call signature from the header files. Newer header files would not provide any benefit because the fbturbo driver would not use any new or changed API calls. The sunxi repository header files work fine and the linker links to the current libUMP.so on the system which is r4p0. This is the reason for not doint "make" and "make install". You do not want to compile the libUMP.so, only use the existing one in the ubuntu image.

crashoverride
Posts: 4223
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Contact:

Re: accelerated X?

Unread post by crashoverride » Wed Jan 14, 2015 11:38 pm

Here is an interesting article detailing the difference of the fbturbo driver and the xf86-video-mali driver with a brief mention of xf86-video-armsoc.
http://ssvb.github.io/2013/02/01/new-xf ... river.html

crashoverride
Posts: 4223
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Contact:

Re: accelerated X?

Unread post by crashoverride » Thu Jan 15, 2015 8:14 pm

I managed to figure out how to use the GE2D hardware. As expected, it drops in place in the fbturbo code with little effort.

The bad news is that it does not support overlapping blits. This condition comprises the majority of window movement and scrolling operations. This is further complicated by the fact that GE2D deals with physical memory addresseses, not virtual. The brute-force method of supporting overlapping blits is to copy first to a temporary memory area and then copy back to the destination. This temporary memory needs to be addressable by the hardware and that means it has to be a physically contiguous address. That is where things get complicated.

Only a device driver can allocate physical memory from the kernel. I looked into using the existing libUMP, however, its physical address is opaque and the physical continuity of the allocation by it is currently not supported. An alternative is to change the kernel configuration to give /dev/fb1 a full frame instead of the 1MB it currently has and use it as a scratch buffer for blitting. However, this would mean the loss of hardware cursor support.

For reference, the sunxi driver requires a kernel patch to support its G2D operation and so is disabled by default. It achieves overlapping blits by changing the scan order when needed.

[Edit]
Forgot to mention that the GE2D hardware does not appear to support changing scan order. I tried the obvious negative height and width, but it causes the driver to lock up.

crashoverride
Posts: 4223
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Contact:

Re: accelerated X?

Unread post by crashoverride » Fri Jan 16, 2015 12:50 pm

Further exploration of GE2D has revealed it does appear to have a method for changing scan order. There appears to be some oddities with it. The test program I made shows that scanning bottom to top causes it to be "off by one" line. The X axis does not seem to exhibit this. The time consuming part of this is not implementing the support in the X11 driver. That part is already done. Rather, it is figuring out the behavior of the GE2D hardware in the absence of any documentation like block diagrams, theories of operation, or even just an API reference.

User avatar
runnerway
Posts: 130
Joined: Mon Dec 15, 2014 6:47 am
languages_spoken: italian, english
ODROIDs: C1, C2
Contact:

Re: accelerated X?

Unread post by runnerway » Wed Jan 21, 2015 6:03 am

Your posts are very interesting and i want to thank you for sharing these informations.

- Do you think you will publish on github your modifications to xf86-video-fbturbo?
- Did you do any progress?

crashoverride
Posts: 4223
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Contact:

Re: accelerated X?

Unread post by crashoverride » Wed Jan 21, 2015 8:56 am

I did implement blitting in the fbturbo driver. However, i experienced occasional graphical glitching. I then added it to the mesonfb kernel driver instead (fbturbo uses a custom ioctl so doesn't require any modifications to support this). This allowed me to use locks to ensure that the glitching was not a multi-threading issue. Unfortunately, graphical glitching persisted there. Finally, I tried brute force copying to a buffer and back to the screen. This also exhibited occasional graphical glitching.

The glitching only occurred when dragging a window around. Scrolling the contents of a window was error free and smooth using the scan order change method. This all means that I dont have anything working 100% to release. I plan to release example code showing how to use the GE2D when free time permits.

rogerramjet
Posts: 24
Joined: Wed Dec 24, 2014 5:46 am
languages_spoken: english
ODROIDs: C1
Contact:

Re: accelerated X?

Unread post by rogerramjet » Thu Jan 22, 2015 9:09 am

@crashoverride

Thank you for your diagnostics. I also find your posts extremely interesting. I tried to read up on how all the disparate pieces of X and the Linux graphics driver stack work but haven't made much progress.

I'm hoping to learn something from you and look forward to any code drops you will do.

Cheers

rogerramjet
Posts: 24
Joined: Wed Dec 24, 2014 5:46 am
languages_spoken: english
ODROIDs: C1
Contact:

Re: accelerated X?

Unread post by rogerramjet » Thu Jan 22, 2015 12:42 pm

WOW

I just checked the state of wayland/weston vs X11 on the pi
https://www.youtube.com/watch?v=0UkUal_hHx8

I know the odroid's are not the same but it seems much more worthwhile to get wayland working.

Very impressive stuff

User avatar
memeka
Posts: 4143
Joined: Mon May 20, 2013 10:22 am
languages_spoken: english
ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART
Contact:

Re: accelerated X?

Unread post by memeka » Thu Jan 22, 2015 1:03 pm

you mean something like this?



12sd
Posts: 33
Joined: Wed Dec 17, 2014 7:04 am
languages_spoken: english, russian, ukranian
ODROIDs: just ordered C1 board
Contact:

Re: accelerated X?

Unread post by 12sd » Thu Jan 22, 2015 6:15 pm

memeka wrote:you mean something like this?
[youtube]https://www.youtube.com/watch?v=KYymcNoGmqQ[/youtube]
[youtube]https://www.youtube.com/watch?v=DRBzOpxEaiU[/youtube]
Wow, that's really impressive. How can we get this stuff working on C1?
I want that fast windows sooo much. As much as fast video in Chromium :)

LiquidAcid
Posts: 1091
Joined: Fri Oct 11, 2013 11:07 pm
languages_spoken: english
ODROIDs: X2
Contact:

Re: accelerated X?

Unread post by LiquidAcid » Thu Jan 22, 2015 10:24 pm

meveric wrote:Good luck on that.. Exynos 4412 supports G2D but in the last couple of years there were nearly no progress at all in that field. (although some project actually worked on this)
Uhm, that's just plain wrong. The G2D is working properly since around June 2014 for me. The only thing missing is userptr functionality, which is now coming with the enabling of the SoC's IOMMU.

LiquidAcid
Posts: 1091
Joined: Fri Oct 11, 2013 11:07 pm
languages_spoken: english
ODROIDs: X2
Contact:

Re: accelerated X?

Unread post by LiquidAcid » Thu Jan 22, 2015 11:05 pm

crashoverride wrote:I managed to figure out how to use the GE2D hardware. As expected, it drops in place in the fbturbo code with little effort.

The bad news is that it does not support overlapping blits. This condition comprises the majority of window movement and scrolling operations. This is further complicated by the fact that GE2D deals with physical memory addresseses, not virtual. The brute-force method of supporting overlapping blits is to copy first to a temporary memory area and then copy back to the destination. This temporary memory needs to be addressable by the hardware and that means it has to be a physically contiguous address. That is where things get complicated.

Only a device driver can allocate physical memory from the kernel. I looked into using the existing libUMP, however, its physical address is opaque and the physical continuity of the allocation by it is currently not supported. An alternative is to change the kernel configuration to give /dev/fb1 a full frame instead of the 1MB it currently has and use it as a scratch buffer for blitting. However, this would mean the loss of hardware cursor support.
The same problem exists on the Exynos4412 platform as well. You need an IOMMU that provides the accelerator blocks (here the GE2D) with a linear chunk of memory, where it can then perform its operations. My solution was to allocate GEM buffers via the DRM interface, since the default allocation style is physically contiguous. Since I'm not familiar with the graphics stacks of the C1, I can't really say if this is feasible here.

Concerning usage of UMP, I would rather refrain from it since ARM is moving away from it in favor of using dmabuf to pass buffers around.

crashoverride
Posts: 4223
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Contact:

Re: accelerated X?

Unread post by crashoverride » Thu Jan 22, 2015 11:44 pm

Once I moved the code to the mesonfb driver, i was able to allocate contiguous physical memory from the Kernel CMA provider. I did have to increase the default pool size on the boot command line to reserve enough memory. This was probably the most elegant solution to the problem as it avoided adding any extra dependencies or 3rd party APIs to the driver.

rogerramjet
Posts: 24
Joined: Wed Dec 24, 2014 5:46 am
languages_spoken: english
ODROIDs: C1
Contact:

Re: accelerated X?

Unread post by rogerramjet » Fri Jan 23, 2015 7:58 am

"Wow, that's really impressive. How can we get this stuff working on C1?
I want that fast windows sooo much. As much as fast video in Chromium :)"

I second that.

This thread is very interesting. Its enjoyable reading the posts from more educated + experienced devs :-)

User avatar
runnerway
Posts: 130
Joined: Mon Dec 15, 2014 6:47 am
languages_spoken: italian, english
ODROIDs: C1, C2
Contact:

Re: accelerated X?

Unread post by runnerway » Sat Jan 24, 2015 9:52 pm

crashoverride wrote:I did implement blitting in the fbturbo driver. However, i experienced occasional graphical glitching. I then added it to the mesonfb kernel driver instead (fbturbo uses a custom ioctl so doesn't require any modifications to support this). This allowed me to use locks to ensure that the glitching was not a multi-threading issue. Unfortunately, graphical glitching persisted there. Finally, I tried brute force copying to a buffer and back to the screen. This also exhibited occasional graphical glitching.

The glitching only occurred when dragging a window around. Scrolling the contents of a window was error free and smooth using the scan order change method. This all means that I dont have anything working 100% to release. I plan to release example code showing how to use the GE2D when free time permits.
Thank you for informations! Seems that "occasional graphical glitching" is the only remaining problem as now :)


Just to add another thing to this discussion:

I'm using xf86-video-fbturbo so i had to switch to 24bpp. But i discovered that h264 acceleration in Kodi works only with 32bpp otherwise we get only audio and a black screen.
I think this is a bit of a problem for a lot of people.
Has mesonfb kernel driver with your modifications this problem too?

EDIT: I think i wrote my question badly. The question is:
When using xf86-video-fbturbo we had to switch to 24bpp otherwise we get "black everywhere".
With mesonfb kernel driver with your modifications we have to switch to 24bpp too?

Probably the best thing is that HardKernel/Amlogic/.. will solve problem with 32bpp or maybe fix hardware acceleration while using 24bpp.. ;)

crashoverride
Posts: 4223
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Contact:

Re: accelerated X?

Unread post by crashoverride » Sat Jan 24, 2015 11:31 pm

runnerway wrote:But i discovered that h264 acceleration in Kodi works only with 32bpp otherwise we get only audio and a black screen.
This was discussed in another thread. The two symptoms of black screen and not seeing video in kodi are due to the same issue:
http://forum.odroid.com/viewtopic.php?f=117&t=8361

Kodi plays video on a layer behind the screen. The framebuffer has transparent regions to allow you to see the video player behind it. 24bit and 16bit framebuffers do not have any alpha support, so there are no transparent regions to allow the video to show through. Without documentation of the video subsytem, its difficult to say what solutions are available. However, this is not an issue with the fbturbo driver. Its a symptom of the architectural design of the Amlogic S805 video subsystem. The optimal solution is to use the video codec to output to a GLES texture. The more likely solution is to patch Kodi to use color keying or a 'video hole'.

User avatar
runnerway
Posts: 130
Joined: Mon Dec 15, 2014 6:47 am
languages_spoken: italian, english
ODROIDs: C1, C2
Contact:

Re: accelerated X?

Unread post by runnerway » Fri Feb 06, 2015 8:04 am

crashoverride wrote:
runnerway wrote:But i discovered that h264 acceleration in Kodi works only with 32bpp otherwise we get only audio and a black screen.
This was discussed in another thread. The two symptoms of black screen and not seeing video in kodi are due to the same issue:
http://forum.odroid.com/viewtopic.php?f=117&t=8361

Kodi plays video on a layer behind the screen. The framebuffer has transparent regions to allow you to see the video player behind it. 24bit and 16bit framebuffers do not have any alpha support, so there are no transparent regions to allow the video to show through. Without documentation of the video subsytem, its difficult to say what solutions are available. However, this is not an issue with the fbturbo driver. Its a symptom of the architectural design of the Amlogic S805 video subsystem. The optimal solution is to use the video codec to output to a GLES texture. The more likely solution is to patch Kodi to use color keying or a 'video hole'.
Thank you for these informations. Really interesting as always.

Do you think you can upload your mesonfb kernel driver with GE2D support on github or something similar? I know it still has some little problems but it will be very interesting. :D

crashoverride
Posts: 4223
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Contact:

Re: accelerated X?

Unread post by crashoverride » Fri Feb 06, 2015 9:54 am

runnerway wrote:Do you think you can upload your mesonfb kernel driver with GE2D support on github or something similar?
I was hoping that the Amlogic datasheet would provide more information on this component and allow me to get it working. Unfortunately, no new information was preset. I do plan to post this work to github as soon as time permits so that others can hopefully help to get it working.

I know its annoying to wait, but work that pays my bills takes priority.

User avatar
runnerway
Posts: 130
Joined: Mon Dec 15, 2014 6:47 am
languages_spoken: italian, english
ODROIDs: C1, C2
Contact:

Re: accelerated X?

Unread post by runnerway » Mon Feb 09, 2015 5:57 am

crashoverride wrote:
runnerway wrote:Do you think you can upload your mesonfb kernel driver with GE2D support on github or something similar?
I was hoping that the Amlogic datasheet would provide more information on this component and allow me to get it working. Unfortunately, no new information was preset. I do plan to post this work to github as soon as time permits so that others can hopefully help to get it working.

I know its annoying to wait, but work that pays my bills takes priority.
I didn't mean to sound as i was pushing you to upload your work. Take your time :D
I've asked only to show you that there are people interested in your work.

crashoverride
Posts: 4223
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Contact:

Re: accelerated X?

Unread post by crashoverride » Wed Feb 11, 2015 8:15 pm

While not the accelerated X11, I did upload a sample showing the use of the GE2D.
http://forum.odroid.com/viewtopic.php?f=112&t=9412

crashoverride
Posts: 4223
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Contact:

Re: accelerated X?

Unread post by crashoverride » Fri Feb 13, 2015 1:48 am

I re-based the X11 driver changes around the xf86-video-mali driver rather than the fbturbo driver. This allows a very clean demonstration and codebase to show the changes. As requested, I have published the changes here:
https://github.com/OtherCrashOverride/c1_mali_ddx_poc

** THIS IS NOT A USEABLE DRIVER **

Dragging a window around uses the GE2D acceleration. The graphical glitches are very pronounced when doing this. Scrolling windows up and down, side to side also uses acceleration. However, the glitching is much less pronounced.

The 'slow drawing trails' when moving a window are not an artifact of the changes. They also exist in the unmodified driver. The fbturbo driver is much faster but does not work correctly in 32bit mode.

[Edit]
The modifications start at https://github.com/OtherCrashOverride/c ... _exa.c#L45
and end at https://github.com/OtherCrashOverride/c ... exa.c#L227

Global variables as well as opening the device were all inlined into the code for clarity. In a production driver they should be moved to context specific structures and proper initialization routines.

User avatar
runnerway
Posts: 130
Joined: Mon Dec 15, 2014 6:47 am
languages_spoken: italian, english
ODROIDs: C1, C2
Contact:

Re: accelerated X?

Unread post by runnerway » Mon Aug 24, 2015 10:48 pm

crashoverride wrote:I re-based the X11 driver changes around the xf86-video-mali driver rather than the fbturbo driver. This allows a very clean demonstration and codebase to show the changes. As requested, I have published the changes here:
https://github.com/OtherCrashOverride/c1_mali_ddx_poc

** THIS IS NOT A USEABLE DRIVER **

Dragging a window around uses the GE2D acceleration. The graphical glitches are very pronounced when doing this. Scrolling windows up and down, side to side also uses acceleration. However, the glitching is much less pronounced.

The 'slow drawing trails' when moving a window are not an artifact of the changes. They also exist in the unmodified driver. The fbturbo driver is much faster but does not work correctly in 32bit mode.

[Edit]
The modifications start at https://github.com/OtherCrashOverride/c ... _exa.c#L45
and end at https://github.com/OtherCrashOverride/c ... exa.c#L227

Global variables as well as opening the device were all inlined into the code for clarity. In a production driver they should be moved to context specific structures and proper initialization routines.
I tried the driver with your modifications.
I took a photo of the glitches: (There are 2 terminals opened)

Image

These are the same as yours?

I don't think so because you posted about "trails" but in my case windows disappear when moved.. ;)
Seems like an off by one error but i'm not sure.

crashoverride
Posts: 4223
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Contact:

Re: accelerated X?

Unread post by crashoverride » Tue Aug 25, 2015 11:07 am

runnerway wrote:I don't think so because you posted about "trails" but in my case windows disappear when moved..
On a non modified driver, when you move a terminal window around really fast, you will see a images of it left behind that eventually catch up. Its look similar to the "mouse trails" features in windows, so that is what I called it: trails.
runnerway wrote:Seems like an off by one error but i'm not sure.
There is an "off by one" bug that is compensated for here https://github.com/OtherCrashOverride/c ... exa.c#L113
The graphic glitching is affected by the speed at which the window is moved. There is probably some kind of double buffering going on and the GE2D ends up blitting from the old surface.

There are currently three things in play that make this not worth pursuing at the moment:
1) DRM display driver. This means we will be using different X11 driver based on ARMSoc instead of the current one based on FBDev.
2) Wayland/Weston in Fedora based releases.
3) Mir in Ubuntu based releases.

For #2 and #3 a GE2D based compositor would need to be developed instead. Although the GLES2 compositors should also work, using the GE2D would free up the GPU for other activities.

Ubuntu Mir is scheduled for an April 2016 release. Fedora with Wayland should be releasing around November 2015. (These dates are tentative, there is no guarantee anything important at all will happen.)

bmentink
Posts: 386
Joined: Sat Dec 13, 2014 1:47 pm
languages_spoken: english
ODROIDs: XU3, XU4
Contact:

Re: accelerated X?

Unread post by bmentink » Tue Sep 01, 2015 10:27 am

Wayland is the way to go. On Archlinux wayland/weston works great ...

As clutter already has support for wayland maybe the focus should be there for ODROID devices ... (i.e clutter based Window managers like mutter, pantheon's gala etc )

Collabora who as been working on wayland for ARM devices has it working on XU3, and as their project is open source, they "should" be feeding there extensions upstream.
Collabora developed multiple extensions to Wayland. The first ensures that no copies of the video data are made in the compositing process, preserving precious memory bandwidth, latency, and overall system responsiveness. This extension uses the latest Khronos Group EGL extensions, as supported by ARM's MALI GPU
I will be actively pursuing a pantheon desktop for my -XU3 running on a wayland backend. (I already have most of pantheon working on X, using Arch ..)

EDIT: Correction: It is not Collabora not passing things upstream, but their partner ARM. Collabora have asked that I provide a document saying why we need an "open source MALI GPU driver with EGL support", cause that is what is missing, and they will pass the document on to their partner ARM .. if someone can help me write the document, that would be good, I will make sure it gets to ARM via Collabora, since they have some clout ..

I guess you guys have all seen this year old video of Wayland running on Samsung Chromebook 2 (same processor as -XU3): https://www.youtube.com/watch?v=GtXQJ0c5q0k

villalvilla
Posts: 1
Joined: Tue Dec 01, 2015 2:56 am
languages_spoken: english
Contact:

Re: accelerated X?

Unread post by villalvilla » Tue Dec 01, 2015 3:01 am

Hi Guys,

I'm very interested in Mali400 X.org hardware accelerated issue. As I have read in this thread, you are trying to make it work, but it's a real hard effort... Could I colaborate any way? were you succesful in any way?

Thanks for your time,
Villalvilla

Post Reply

Return to “Ubuntu”

Who is online

Users browsing this forum: No registered users and 1 guest