LLVMpipe On Mesa 8.1 Performance

[phoronix]

Phoronix: LLVMpipe On Mesa 8.1 Performance

Having now delivered Mesa 8.1 benchmarks looking at the hardware drivers for AMD R600g, Nouveau, R300g, Intel Ivy Bridge, and Intel Sandy Bridge, here are some benchmarks when on LLVMpipe.

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

[uid313]

What is the roadmap for LLVMpipe?
What is on the schedule?

Can we expect the performance to increase in coming versions?
How much?

How fast will LLVMpipe be in 1 year?
0% faster? 1% faster? 5% faster? 10% faster? 50 faster? 100% faster?

[Lynxeye]

There is AVX support coming which could speed up LLVM quite a bit, but that's mostly dependant on LLVM advancements.

Far more work is going into making LLVMpipe run all the latest stuff that MESAs OpenGL implementation supports.

[uid313]

There is AVX support coming which could speed up LLVM quite a bit, but that's mostly dependant on LLVM advancements.

When is AVX coming to LLVM?
What LLVM advancements?

Far more work is going into making LLVMpipe run all the latest stuff that MESAs OpenGL implementation supports.

Which supports more of OpenGL, LLVMpipe or softpipe?
And what is swrast in Mesa? Is it the same as softpipe?
Now that we have LLVMpipe, is or will softpipe get deprecated?

[bridgman]

IIRC the swrast code in Mesa pre-dates Gallium3D -- softpipe and llvmpipe are Gallium3D drivers.

Looks like swrast and softpipe are the first to get updated with new OpenGL features, while llvmpipe follows a bit later. In general it seems like one or the other gets updated early, not both. Not sure what the current code sharing situation is between them.

http://cgit.freedesktop.org/mesa/mes...rc/mesa/swrast

http://cgit.freedesktop.org/mesa/mes...ivers/softpipe

It's probably fair to say that swrast / softpipe are the closest things to "reference" we have today. I don't think there are any plans to deprecate either of the sw rasterizers in favour of llvmpipe, at least as long as adding new functionality to the sw rasterizers is easier and more predictable than adding to llvmpipe (which I'm pretty sure *is* the case today).

[uid313]

http://cgit.freedesktop.org/mesa/mes.../llvm-todo.txt

TODO covering gallivm/llvmpipe
==============================

Goal: GL3.0 support in llvmpipe
-------------------------------

TXQ opcode support - airlied WIP
TXF opcode support.
Integer texture fetch support
Integer renderbuffer support
Vertex ID support.
EXT_transform_feedback support - airlied WIP
clip distance support - airlied WIP
vertex clip support - airlied WIP
EXT_texture_array support - Jakob WIP

Goal: extension parity with softpipe:
-------------------------------------
GL3.0 support.
EXT_timer_query - airlied posted a patch

[droidhacker]

It is worth pointing out that on any system with a CPU strong enough to use llvmpipe in a non-headache-inducing manner, there is definitely a GPU capable of running the same stuff better. Anything so weak that it doesn't have a decent GPU, llvmpipe is totally worthless.

At least, that is what you would get if you're trying to run GL exclusively on llvmpipe.

What llvmpipe is for, is patching in a few functions not present in the 3d drivers, and comparing 3d drivers for correctness. It is not now and never will be a substitute for functioning 3d hardware.

[curaga]

It is worth pointing out that on any system with a CPU strong enough to use llvmpipe in a non-headache-inducing manner, there is definitely a GPU capable of running the same stuff better. Anything so weak that it doesn't have a decent GPU, llvmpipe is totally worthless.

/me owns hexacores with either no GPU or a 20e GPU.