jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 24165
Joined: Sat Jul 30, 2011 7:41 pm

Re: Experimental enhanced X driver (rpifb)

Fri Dec 13, 2013 5:38 pm

Is there any way of turning this on and off so I can do easy comparisons.

Had a quick play - looks pretty snappy!
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I think it’s wrong that only one company makes the game Monopoly.” – Steven Wright

ssvb
Posts: 112
Joined: Sat May 19, 2012 6:15 pm

Re: Experimental enhanced X driver (rpifb)

Fri Dec 13, 2013 5:47 pm

jamesh wrote:Is there any way of turning this on and off so I can do easy comparisons.
The instructions were provided here http://www.raspberrypi.org/phpBB3/viewt ... 17#p467617
Or just edit the config file (/usr/share/X11/xorg.conf.d/99-fbturbo.conf) to change between "fbdev" and "fbturbo", reboot and check /var/log/Xorg.0.log to confirm which driver got really loaded.

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5372
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Experimental enhanced X driver (rpifb)

Fri Dec 13, 2013 5:48 pm

jamesh wrote:Is there any way of turning this on and off so I can do easy comparisons.

Had a quick play - looks pretty snappy!
asb wrote:... get rid of /usr/share/X11/xorg.conf.d/99-fbturbo.conf

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 24165
Joined: Sat Jul 30, 2011 7:41 pm

Re: Experimental enhanced X driver (rpifb)

Fri Dec 13, 2013 5:58 pm

ssvb wrote:
jamesh wrote:Is there any way of turning this on and off so I can do easy comparisons.
The instructions were provided here http://www.raspberrypi.org/phpBB3/viewt ... 17#p467617
Or just edit the config file (/usr/share/X11/xorg.conf.d/99-fbturbo.conf) to change between "fbdev" and "fbturbo", reboot and check /var/log/Xorg.0.log to confirm which driver got really loaded.
Doh! Missed the disable instructions as I read the install instructions. Ta.

James
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I think it’s wrong that only one company makes the game Monopoly.” – Steven Wright

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 24165
Joined: Sat Jul 30, 2011 7:41 pm

Re: Experimental enhanced X driver (rpifb)

Fri Dec 13, 2013 6:02 pm

Wow! That's a very noticeable improvement, nice job. Not seen any regressions yet.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I think it’s wrong that only one company makes the game Monopoly.” – Steven Wright

User avatar
DougieLawson
Posts: 36576
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
Contact: Website Twitter

Re: Experimental enhanced X driver (rpifb)

Fri Dec 13, 2013 7:21 pm

asb wrote:I've packaged up fbturbo, and you can now install it from the Foundation's Raspbian repo with

Code: Select all

sudo apt-get update && sudo apt-get install xserver-xorg-video-fbturbo
Can it be added to the Jessie repo?
Note: Having anything humorous in your signature is completely banned on this forum. Wear a tin-foil hat and you'll get a ban.

Any DMs sent on Twitter will be answered next month.

This is a doctor free zone.

lingon
Posts: 122
Joined: Fri Aug 26, 2011 7:31 am

Re: Experimental enhanced X driver (rpifb)

Sat Dec 14, 2013 11:19 am

This looks very good based on my short testing with Midori and a couple of terminal windows. The performance is significantly better when scrolling webpages in Midori or when moving windows around the screen.

Many thanks for this work!

Should the name of this thread be changed to reflect the name of the new accelerated driver?

User avatar
dliloch
Posts: 168
Joined: Wed Jun 27, 2012 6:28 pm
Location: cleveland, ohio usa

Re: Experimental enhanced X driver (rpifb)

Sat Dec 14, 2013 12:05 pm

great job.. it has made a noticeable difference in performance. especially when I drag frames around the desktop.. gnome-system-monitor is now usable.. I know I could not use it before..
thanks so much for your hard work.. maybe liz could make it a feature so more people will try it ..
-don isenstadt

gkreidl
Posts: 6139
Joined: Thu Jan 26, 2012 1:07 pm
Location: Germany

Re: Experimental enhanced X driver (rpifb)

Sat Dec 14, 2013 12:45 pm

and it's well worth running your RPi with 32 bit color resolution now (never liked the image display with 16 bit color).
Minimal Kiosk Browser (kweb)
Slim, fast webkit browser with support for audio+video+playlists+youtube+pdf+download
Optional fullscreen kiosk mode and command interface for embedded applications
Includes omxplayerGUI, an X front end for omxplayer

tvjon
Posts: 715
Joined: Mon Jan 07, 2013 9:11 am

Re: Experimental enhanced X driver (rpifb)

Sat Dec 14, 2013 6:13 pm

I tried the original but didn't have much luck with it. Trying again with the new version there is indeed a considerable improvement, thank you, & unlike Weston/Wayland, we can all benefit from your efforts NOW!

I've tried several cards, a couple of different kernels, & no problems so far.

User avatar
dliloch
Posts: 168
Joined: Wed Jun 27, 2012 6:28 pm
Location: cleveland, ohio usa

Re: Experimental enhanced X driver (rpifb)

Sun Dec 15, 2013 4:21 pm

When I use tightvncserver I only get a blank window with my vnc client.
Do I have to do something special to make this work with the fb turbo?
Thanks..

ssvb
Posts: 112
Joined: Sat May 19, 2012 6:15 pm

Re: Experimental enhanced X driver (rpifb)

Sun Dec 15, 2013 4:25 pm

dliloch wrote:When I use tightvncserver I only get a blank window with my vnc client.
Do I have to do something special to make this work with the fb turbo?
Thanks..
This may be a strange question, but do you get a non-blank window with the standard fbdev driver? If the answer is "yes" and we have a regression here, then there are a number of options to try tweaking (they should be all described in "man fbturbo"). If any of these options happens to fix/workaround the problem, please let me know.

And as the last resort if nothing else helps, I would prefer to be able to reproduce this problem on my Raspberry Pi. In this case some step by step instructions leading to this problem would be much appreciated.

Thanks.

User avatar
dliloch
Posts: 168
Joined: Wed Jun 27, 2012 6:28 pm
Location: cleveland, ohio usa

Re: Experimental enhanced X driver (rpifb)

Sun Dec 15, 2013 5:53 pm

my bad... I completely removed tightvncserver then reinstalled and all is ok .. there must have been something I was doing previously with my config of xstartup in the .vnc directory .. by completely removing and reinstalling tightvncserver that seems to have "fixed" it... sorry
-don

ssvb
Posts: 112
Joined: Sat May 19, 2012 6:15 pm

Re: Experimental enhanced X driver (rpifb)

Sun Dec 15, 2013 6:03 pm

OK, no problems. Better safe than sorry. Thanks for testing and paying attention to possible regressions.

User avatar
dliloch
Posts: 168
Joined: Wed Jun 27, 2012 6:28 pm
Location: cleveland, ohio usa

Re: Experimental enhanced X driver (rpifb)

Sun Dec 15, 2013 6:17 pm

one other thing that I noticed .. using gnome-system-monitor .. it idles @ around 25-30% cpu
if I roll it around on the screen with the mouse it uses 98% in both fbturbo and the normal xwindows... but it moves much better under turbo..
in vnc it idles @ 98% .! unusable .. (both turbo and non turbo).

-don

ssvb
Posts: 112
Joined: Sat May 19, 2012 6:15 pm

Re: Experimental enhanced X driver (rpifb)

Sun Dec 15, 2013 6:30 pm

After/if we patch the kernel and add IRQ support to wait for DMA copy completion instead of spinning, the CPU usage should drop quite significantly when moving windows.

As for the high CPU usage when idling in VNC, most likely it is actually doing something (maybe it is receiving new frames even though the picture does not change?). As a quick test, you could run 'htop' in a separate ssh session and check which processes are hogging the CPU the most. A more detailed analysis can be done using oprofile or perf.

User avatar
dliloch
Posts: 168
Joined: Wed Jun 27, 2012 6:28 pm
Location: cleveland, ohio usa

Re: Experimental enhanced X driver (rpifb)

Sun Dec 15, 2013 8:28 pm

CPU[|||||||||||||||||||||||||99.5%] Tasks: 65, 80 thr; 2 running
Mem[||||||||||||||||||||||91/374MB] Load average: 1.83 1.61 1.66
Swp[ 0/99MB] Uptime: 02:56:22

PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
2826 pi 20 0 21056 11940 2432 R 64.0 3.1 1h26:28 Xtightvnc :1 -des
3106 pi 20 0 108M 19416 14576 S 23.0 5.1 30:53.12 gnome-system-moni
6306 pi 20 0 5032 1668 1236 R 7.0 0.4 0:01.60 htop

then I did
perf_3.2 record -p 2826 -o perfile
I've attached the output because I don't have the knowledge to interpret it ..
so maybe it could be of some use to you.
Attachments
perfile.zip
perf record output
(45.95 KiB) Downloaded 200 times

ssvb
Posts: 112
Joined: Sat May 19, 2012 6:15 pm

Re: Experimental enhanced X driver (rpifb)

Sun Dec 15, 2013 9:00 pm

If the time is not spent in Xorg process, then all the heavylifting is happening on the client side in Xtightvnc application (maybe handling the decryption and decompression of the network data?). The X drivers can't help here, no matter accelerated or not.

As for the data collected by "perf record", it can be converted to a text report using "perf report". There is also a very useful "perf top" command. And debugging symbols are needed for resolving function names (usually *-dbg packages in debian).

User avatar
blachanc
Posts: 458
Joined: Sat Jan 26, 2013 5:03 am
Location: Quebec,canada(french)

Re: Experimental enhanced X driver (rpifb)

Tue Dec 17, 2013 2:27 am

blachanc wrote:
ssvb wrote:
Of course everything depends on whether the Raspberry Pi users are interested in a faster X11 desktop or not. So far it looks like nobody cares, and the community is just waiting for a wayland silver bullet to save the day. Which is of course also fine, and means less work for me to do ;)
Anyway: To answer your question directly: yes, I do care a lot about speed.
And a big Thank you for your work!!!

Ben

(and another thread to subscribe to)
Had a chance to try this tonight, and it does feel more responsive.
I tried the kid educational games (gcompris, which is a bit slow on PI), and it felt faster too (maybe a placebo effect, but I do not think so).

Thanks again,

Ben

Code: Select all

pi@raspberrypi ~ $ vcgencmd get_config int
arm_freq=1000
core_freq=500
sdram_freq=600
over_voltage=6
Autism/Asperger syndrome: what is your score on this quiz?
http://www.raspberrypi.org/forums/viewtopic.php?f=62&t=70191

andrum99
Posts: 929
Joined: Fri Jul 20, 2012 2:41 pm

Re: Experimental enhanced X driver (rpifb)

Thu Dec 19, 2013 10:31 pm

ssvb wrote:Dragging windows should be happening without an ugly redraw trail. That's the performance issue which is specifically addressed.
Tried it - Ugly redraw trail is indeed gone. A definite improvement- nice work!

andrum99
Posts: 929
Joined: Fri Jul 20, 2012 2:41 pm

Re: Experimental enhanced X driver (rpifb)

Tue Dec 24, 2013 1:35 am

I've just tested this with the new web browser called "web" that the foundation has just released - seems to co-exist quite happily - yay!

ssvb
Posts: 112
Joined: Sat May 19, 2012 6:15 pm

Re: Experimental enhanced X driver (rpifb)

Tue Dec 24, 2013 4:27 pm

andrum99 wrote:I've just tested this with the new web browser called "web" that the foundation has just released - seems to co-exist quite happily - yay!
Well, the screenshots from the Web browser beta announcement message don't show any traces of wayland/weston yet, so I guess it indeed should work fine with fbturbo. Please note that compared to the fbdev driver, fbturbo removes one redundant intermediate buffer copy (the shadow layer), and has nearly the same speed as the direct access to the framebuffer for many practical use cases (XShmPutImage should have roughly the same performance as memcpy from some offscreen buffer to the framebuffer). So you should also have faster browsing when compared to the regular fbdev driver.

Assuming that Web is currently X11 based, I still wonder about the current HTML5 video hardware acceleration details. Does it use dispmanx to do roughly the same hackish hardware video decoding integration with X11 window system as libvdpau-sunxi (basically setting up a display controller layer with color key from the application process and trying to make sure that it is correctly positioned)?

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5372
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Experimental enhanced X driver (rpifb)

Tue Dec 24, 2013 4:47 pm

ssvb wrote: Assuming that Web is currently X11 based, I still wonder about the current HTML5 video hardware acceleration details. Does it use dispmanx to do roughly the same hackish hardware video decoding integration with X11 window system as libvdpau-sunxi (basically setting up a display controller layer with color key from the application process and trying to make sure that it is correctly positioned)?
I believe the initial "Web" video decode plan is for the hw acceleration layer to produce to sequence of RGB frames of the requested size that will be composited in the normal way by X. This isn't the most efficient way, but should be fine for typical YouTube videos, and should be compatible with other software (like fbturbo or VNC).

The Wayland version could be more efficient, with dispmanx compositing the video on its own layer, with the ARM never seeing the video pixels.

plugwash
Forum Moderator
Forum Moderator
Posts: 3476
Joined: Wed Dec 28, 2011 11:45 pm

Re: Experimental enhanced X driver (rpifb)

Wed Dec 25, 2013 1:52 pm

I split the posts about issues with midori/gtk2 webkit and the new collabora web repo to http://www.raspberrypi.org/phpBB3/viewt ... 26#p474026

portets
Posts: 186
Joined: Sat Oct 29, 2011 6:24 am

Re: Experimental enhanced X driver (rpifb)

Thu Dec 26, 2013 6:55 am

Will this also speed up XWayland?

Just wondering if this work is forward-compatible.

Return to “General discussion”