Question about X on the arm's.

Tue Nov 22 00:48:38 UTC 2016

On Mon, 21 Nov 2016 17:41:45 -0500 Gene Heskett <gheskett at shentel.net> said:

> Greetings X experts;
> 
> I bought a monitor that should have been able to do 1920x1080p60Hz.
> One would expect thats a given when the card gets $140 lighter carrying 
> it out past the RF stuff in Wallies front door frame, so I just bought 2 
> of the faster SBC's like the r-pi 3b but the one that will display what 
> the r-pi 3b puts out, claimed to be a bit faster.
> 
> It wasn't until I googled for its specs last night and discovered its max 
> is 1366x768 that I actually got a picture out of it hooked to anything 
> except the r-pi.
> 
> My question has to do with the rendering and screen refresh rate, which 
> is obviously about 1/4 of the speed an old single core, x86 P4.

actually... the pi3 is not that bad. at least when you get to throw all 4 cores
around for things like compiling, it's about 50% faster than a 1.5ghz baytrail
e3815. at least in my testing that's what the numbers say.

also be aware that the x11 code path is actually not that well optimized. where
under x11 i'm going to never exceed 30fps doing compositing of my desktop with
the gpu, when in wayland mode (exact same WM/desktop config etc.) can manage
60fps... oh and all at 1920x1080p. well dragging my terminals around etc. it's
smooth. that may be partly due to being able to do partial updates sensibly
supported (haven't checked in egl+x11), or simply due to it being zero copy
swaps vs copies in x11.

> I am assuming the X built for it is single threaded, and it could be made 
> more pleasant to use if it scattered its jobs about the 4 cores in the 
> typical arm cpu.

unless you are finding that the xserver process is pegged at 100% cpu... this
isn't going to help you at all.

reality is that work is split between multiple processes. at least when
compositing you will have at LEAST:

1. xorg server
2. wm/compositor
3. client app

all churning away and doing things. that would mean that you can at least soak
up 3 cpu cores there just by design without magic "lets multithread this
formerly single threaded design" work.

client apps may use cpu or gpu to render. the compositor likewise may use cpu
or gpu. xserver almost definitely is using cpu to do rendering if it is doing
any rendering at all.

you likely will find that just getting more cores involved doesn't necessarily
help. you may be memory bandwidth limited so a single core hammering away on
simple memcpy's wont be sped up by 21 or 3 or 4 cores doing the same thing. if
anything it slows down as there is more bus contention and possibly cacheline
prefetching is hurt by more scattered access patterns.

so before looking for some magic "solve my problems by threading" option...
profile what is going on as you may actually find this isn't your problem at
all... :)

> Is there a build switch that could accomplish this? This is a quad core 
> 64 bit arm cpu, running at its default clock of 1.5GHz which it seems 
> like should have the ponies to handle the load.  More heat sink maybe.
> 
> Is there anything I can do, considering its only other job is serviceing  
> the keyboard and rodent?
> 
> Thanks everybody.
> 
> Cheers, Gene Heskett
> -- 
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> Genes Web page <http://geneslinuxbox.net:6309/gene>
> _______________________________________________
> xorg at lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com