Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Graphics Hardware Hacking Build

Vastly Improved Raspberry Pi Performance With Wayland 259

New submitter nekohayo writes "While Wayland/Weston 1.1 brought support to the Raspberry Pi merely a month ago, work has recently been done to bring true hardware-accelerated compositing capabilities to the RPi's graphics stack using Weston. The Raspberry Pi foundation has made an announcement about the work that has been done with Collabora to make this happen. X.org/Wayland developer Daniel Stone has written a blog post about this, including a video demonstrating the improved reactivity and performance. Developer Pekka Paalanen also provided additional technical details about the implementation." Rather than using the OpenGL ES hardware, the new compositor implementation uses the SoC's 2D scaler/compositing hardware which offers "a scaling throughput of 500 megapixels per second and blending throughput of 1 gigapixel per second. It runs independently of the OpenGL ES hardware, so we can continue to render 3D graphics at the full, very fast rate, even while compositing."

This discussion has been archived. No new comments can be posted.

Vastly Improved Raspberry Pi Performance With Wayland

Comments Filter:
  • Re:wayland (Score:4, Interesting)

    by Jah-Wren Ryel ( 80510 ) on Monday May 27, 2013 @07:29PM (#43835979)

    Great, more wayland propaganda. As if exploiting certain hardware features has anything to do with Wayland vs X11. Wayland: Breaking decades of backwards compatibility for no good reason.

    Exactly. This article boils down to "wayland performance on pi went from suckass to very nice" which is mildly interesting but the implication that wayland rulez and X snoozes because of that is specious. There is no reason X couldn't see the same performance improvement if it too switched drivers.

  • by ADRA ( 37398 ) on Monday May 27, 2013 @09:04PM (#43836503)

    I'm not philosophically against clean fast code, but to your point my desktops are probably 98% CPU idle when doing a normal workload, and only really pick up when: Playing games, Playing flash, Doing a compile, Running a development server and testing. The age of low level fast optimization is all but dead. For a brief time during the smart phone revolution, pathetic CPU's were a bottle-neck, but with my N4, nothing I throw at it feels slow or choppy. It has 2GB of ram IN A PHONE. Sure limited spec and fit for purpose devices will need fast low level access to optimize, but that takes time, and quite often we're finding that hardware's faster and cheaper than wasting time optimizing for the apex solution.

    Take your question again: In 10 years when our entire assortment of devices has as much horsepower as my desktop computer does today, are we really going to need significantly tight processing? I'd say the better long term solution will be making development faster and hopefully more expressive.

  • Re:wayland (Score:4, Interesting)

    by cduffy ( 652 ) <charles+slashdot@dyfis.net> on Monday May 27, 2013 @09:17PM (#43836599)

    I'm... sorry?

    You think SysV init scripts are in any way, shape or form moderately acceptable?!

    I have a very simple refutation to that -- the collection of run scripts behind this link [smarden.org].

    Go ahead -- have a look. Keep in mind that systems using those mostly one-line scripts all provide not just startup/shutdown/status, but also the ability to auto-restart on failure and lack the propensity for race conditions that pidfile-based locking almost universally used by SysV scripts is so very, very prone to.

    Holding up SysV init scripts as a thing that doesn't have to be changed... it beggars belief.

  • Re:wayland (Score:5, Interesting)

    by peragrin ( 659227 ) on Monday May 27, 2013 @10:13PM (#43836841)

    My complaint was simpler. Hot swap monitors in 2003.

    in 2003 I could unplug a monitor from my powerbook G4, and plug in a different monitor with a different resolution without causing anything other than window resizing things(and even that was done mostly automatically)

    I tried that with linux in 2010 and not only did it crash out X11 but the automatic tool that was supposed to do it wouldn't restart. I didn't want to manually rerwrite x.conf every time I wanted to plugin in a different monitor(something I was doing several times a day).

    To this day I miss aspects of transparent network windows. remote desktop/VNC just are not the same. However they are fast/ stable compared to X over anything but a local 100mbit lan.

    I truly wish someone would rewrite X from the ground up with some new ideas on how to do the network transparency.

Today is a good day for information-gathering. Read someone else's mail file.

Working...