On Mon, 21 Nov 2016 17:41:45 -0500 Gene Heskett <ghesk...@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@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) ras...@rasterman.com _______________________________________________ xorg@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
