What's Left For LLVMpipe Before OpenGL 3.0

[phoronix]

Phoronix: What's Left For LLVMpipe Before OpenGL 3.0

One of the Gallium3D drivers yet not fully supporting the OpenGL 3.0 specification is the LLVMpipe software rasterizer. However, if you're curious of what's left before this CPU-based graphics driver can handle GL3, here's a list...

http://www.phoronix.com/vr.php?view=MTA2OTI

[allquixotic]

It's a good fallback driver for using something like Cinnamon, Unity 3d, or gnome-shell when you don't have properly working hardware 3d. This lets you retain your normal desktop experience (albeit slower) while you are fixing your drivers, heh.

Other than that, if you have a CPU fast enough to run llvmpipe, you probably also have a discrete GPU, or an Intel or AMD CPU with integrated graphics that can do hardware accel a lot faster than llvmpipe.

[droidhacker]

It's a good fallback driver for using something like Cinnamon, Unity 3d, or gnome-shell when you don't have properly working hardware 3d. This lets you retain your normal desktop experience (albeit slower) while you are fixing your drivers, heh.

Other than that, if you have a CPU fast enough to run llvmpipe, you probably also have a discrete GPU, or an Intel or AMD CPU with integrated graphics that can do hardware accel a lot faster than llvmpipe.

Most any GPU's drivers can handle some 3D work -- enough for various compositing options. The exception to this are the intel 500/600 chips and other similar problem GPUs, which unfortunately, are exclusively available with processors that are NOT sufficient even for the light duty of compositing. Believe me, I tried over this last weekend. Gnome-shell alone sucks more than 85% of the CPU while doing NOTHING.

The good news though, is that the open source kms driver for the intel 500 works fine for fallback mode. It makes this once-borderline-useless hardware actually very useful now, since the kms driver is stable (in an -it doesn't randomly crash the kernel- sense), and acceleration is really not needed for this class of hardware, except possibly for some compositing.

What is a little bit frustrating though, is that the gnome OSK is only compatible with gnome-shell, not gnome-panel, so in tablet mode, must resort to gok, which is somewhat flakey.

Though I generally dispise gnome-shell, I have to admit that it would be highly suitable for a TABLET.

In all, I feel that LLVMpipe would need a speedup of about a factor of 10 before it would actually be adequate. I don't think I could accept CPU compositing unless the CPU utilization was under 10%.