If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

KDE Desktop Won't Force You To Use LLVMpipe

10-09-2012, 04:00 PM

Phoronix: KDE Desktop Won't Force You To Use LLVMpipe

While Canonical dropped Unity 2D in favour of using Unity and the Compiz window manager atop Gallium3D's software-accelerated LLVMpipe driver when no GPU hardware driver is available, and some distributions have done similar moves with the GNOME Shell on LLVMpipe, it doesn't look like the KDE desktop will be doing this risky move as any sanctioned default...

That's nice. Like Martin said, it makes no sense to fall back to LLVMpipe because if you do need to fall back, then your system most likely is too slow to support OpenGL in the first place, and thus most likely has a slow CPU. The only other scenario I can think of is if it's a server with some esoteric graphics card, but then it would probably not use an X server to begin with, not even talking about compositing.

And yeap, the performance of Unity over LLVMpipe on my GMA 600 device is abysmal. Moving any window makes the screen refresh at something like 5 FPS. That's just not good at all, compared to things like XFCE desktop, where there are no issues like that at all.

Comment

That's nice. Like Martin said, it makes no sense to fall back to LLVMpipe because if you do need to fall back, then your system most likely is too slow to support OpenGL in the first place, and thus most likely has a slow CPU.

This. Video cards w/o OpenGL acceleration belong to the AGP era (or even before that). Which CPU that runs on an AGP capable board has the extra horse power to run OpenGL?

Comment

If your hardware is too old to provide the requirements for OpenGL based compositing, it is quite likely that your CPU is also rather old. We can assume a single-core CPU of either the Pentium era or an early Atom.

Fortunately the earliest Atoms (N270, 330) use Intel 945 or NVidia Ion graphics and are well supported by Mesa. Only the Z-series and Cedar Trail Atoms with PowerVR graphics cause headaches for their owners.

Comment

This. Video cards w/o OpenGL acceleration belong to the AGP era (or even before that). Which CPU that runs on an AGP capable board has the extra horse power to run OpenGL?

AGP? You're off by two entire interface generations.

I remember paying a couple hundred dollars for a 3DLabs Permedia graphics card that could do OpenGL with an ISA 16-bit bus.

For years before that, people joked about the next generation of graphics cards having "billions of colors" instead of "millions of colors", and I remember reading article after article about how worthless the next generation of graphics cards were going to be.. Even reputable magazines like PC World joked about how worthless the next generation of graphics cards were going to be...

Then it turned out the next generation of graphics cards ended up having 3D chips and everybody just dropped everything and went out and bought one and totally forgot about the "billions of colors" versus "millions of colors" jokes... That was the 16-bit ISA generation.

PCI came later when they wanted to show more than a couple 3D things on the screen at the same time, and AGP came much later when they started shoving detailed textures onto those 3D things.

Comment

Ahem... what about systems that have as yet unsupported graphics cards and fast CPUs... that would be the target for LLVM as a holdover untill the 3d drivers get written.

He basically said to run the binary blob drivers in that situation.

To that, I'll add, If you don't want to run binary blob drivers in that situation, then don't buy graphics hardware that is not supported by open source drivers in the first place. Yes, Southern Islands and some nVidia Optimus hardware, I'm referring to you! Nobody wants you, go away.