Gnome REALLY slow

[bmentink]

Hi Guys,

I have just installed Arch on my beagleboard-xm and although it boots to a console ok, booting to Gnome is really slow .. takes minutes to boot .. and top shows a lot of "waiting" time ..

Anyone got gnome to perform in arch? (angstom distro on the other hand, works ok, but I would really like to run Arch )

PS: And what is the state of GLX support (and/or OpenGL ES) for the beagleboard

Thanks.

[kmihelich]

Gnome 3, the default in Arch now, is massive and will likely not run well on a Beagle. There are still Gnome 2 packages, or what you really should do is run a desktop environment appropriate to your hardware.

Your XM is less powerful than your standard Atom processor, please keep that in mind.

[bmentink]

Thanks. How do I install Gnome2?

I suggest if Angstom can run Gnome2 ok on this hardware, then Arch should be
able to ..

.. also under Angstom I installed the OpenGL ES drivers and was able to display full 1280x768 animated
3D graphics in an X window and/or directly on the frame buffer using only 20% CPU.

All we really need is to support the accelerated graphics to get better performance ... hence my question on the state of the SGX support ..

[kmihelich]

gnome-desktop2 has the Gnome 2 stuff. Arch stays on the leading edge of versions and generally old supports older versions when people complain loudly enough about not having them anymore, or when both versions are used simultaneously (python 2 and 3 for example). This means that while it's there, I can't vouch for its viability or usefulness, and may be outright discontinued by Arch in the future.

The answer to your question about SGX drivers is here: viewtopic.php?f=28&t=1595#p8814

I did not respond because I would have only re-stated what I said. But maybe it needs emphasis: there are no hard-float drivers for SGX at this time. Our armv7h is built hard-float, not soft-float (angstrom, ubuntu, debian armel), and thus is ABI-incompatible with the existing soft-float drivers. There is much information on the internet about the distinct differences if you're confused.

[bmentink]

Thanks. I am confused about the hard-float thing. I thought the hard-float was support for the FPU unit on the OMAP, I still do not see what that has to do with the SGX support .... forgive my ignorance

How does using hard-float speed up graphics better than SGX support?

[kmihelich]

Simply put, using hard floating point means that there is no software transformation of floating point values in their computation. ARM systems without an FPU can only use soft-float, because there is no hardware to actually compute the values. In systems with an FPU, doing software transformations means that there are multiple extra steps taken by the CPU to transform floating point values to integers, which then get transformed back by the FPU, which needs to transform back to integer for the actual code executed. Having an FPU means that the software does not *need* to do transformations prior to calculating the values, which is realized by building using the hard-float ABI which sends floating point values as-is.

For each transformation done in software for soft-float, you get at least a handful of extra overhead cycles to calculate the transformations from floating point to an integer representation. Hard-float does not need those, which results in faster code for software that does a lot of floating point computations such as multimedia applications -- anything graphical or audio.

If you want a quick demonstration, run the whetstone benchmark on Angstrom, then run it on our distribution.

Using soft-float libraries in a hard-float system means that there will be a loss of precision as you essentially only get an integer passed back and forth, not the full float. This effect can range from a slight inconvenience to glitches that render the software unusable depending on the software used. Everything must use the same ABI in order to be fully compatible, either hard- or soft-float ABI.

The hard-float ABI doesn't replace the SGX drivers, it merely accelerates the system as a whole, especially for multimedia apps. When TI and/or PowerVR release a hard-float compiled driver for the chip, it will drop right in and work beautifully. Until then, no dice. The only system currently with hard-float drivers is the TrimSlice and other Tegra2-based devices. Believe me, I'd love to see accelerated video on my PandaBoard.

[bmentink]

Many thanks for that excellent explaination

I guess we will just have to pray that the hard-float support for SGX happens soon ...

[bmentink]

Some additional observations:

Tried an xfce install and that, although faster, is still quite slow in response compared to Angstom/gnome2.

I notice that Arch only runs the CPU at 500Mhz, why is it not running at 1Ghz, and how do I fix it.

If Arch is indeed using hard-float should it not be much faster than Angstom ??

PS: I also notice that the serial console does not work with Arch. I have to ssh in ..

[kmihelich]

Be sure you've updated your system to the latest software (pacman -Syu), the newer kernels default to 'performance' for the CPU governor, which should max it out at 800MHz (1GHz is still unstable).

Serial console works, be sure that you have the correct serial arguments in your boot.scr that are being passed to the kernel. Also check and make sure you didn't get an older copy of the omap-smp tarball which didn't have the serial stuff set up right.

"Faster" needs to be qualified. Yes, overall things will run faster on Arch. No, we are not as stripped down minimal as Angstrom. No xorg drivers plays a huge role in the perceived speed of X, we can't fix that. If Arch doesn't work for you, you don't have to use it.

[bmentink]

Hi,

The last time I tries a full upgrade with pacman -Syu I lost my omap frame buffer, have you tried an upgrade lately?
Consaole args are: console=ttyO2,115200n8.

I grabbed the latest tar-ball off the "Install" page for the -XM.

PS: I WANT to use Arch, I am running Arch on 4 computers in my home, including my TV (XBMC)

PPS: By the way, I am using a uBoot from the Angstrom Distro as the link to the uBoot on the Arch home page is broken. That uBoot is expoecting a uEnv.txt file instead of the *.scr file that is in your docs. What should I do to fix that?

PPPS: Here is the kernel output when trying to load the omap frame buffer (after Pacman -Syu)

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[ 0.132690] Unable to get DVI reset GPIO
[ 2.731231] omap_sham_mod_init: Unsupported cpu
[ 2.736053] omap_aes_mod_init: Unsupported cpu
[ 2.833068] omapfb omapfb: no driver for display
[ 2.838073] omapfb omapfb: failed to setup omapfb