Gallium3D's LLVMpipe Is Speeding Up

[phoronix]

Phoronix: Gallium3D's LLVMpipe Is Speeding Up

For the past year or so we have been fascinated by the LLVMpipe driver on Mesa's Gallium3D driver architecture for accelerating OpenGL on your CPU (or any other Gallium3D state tracker) as a means of a more efficient and viable software rasterizer for Linux. Mesa's long-standing software rasterizer (swrast) driver is slow and next to useless while LLVMpipe is many times faster thanks to leveraging the Low-Level Virtual Machine and other optimizations atop Gallium3D. However, in order to run a basic OpenGL game purely on the CPU you still need a powerful CPU, but we are pleased to find there are some noticeable performance improvements to be found in Mesa 7.10.

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

[Shining Arcanine]

Why do you not make anything more than a superficial attempt to interpret your own graphs? For instance, you say:

Lastly, with VDrift, which is the most demanding test in this article for running off LLVMpipe, the performance is up by an incredible 67%.

Unless we are seeing different graphs, that graph is all over the place, with a performance regression at 1600x900, but you make no mention of that.

Would you try to make a better effort? Benchmarking sites that focus on Windows do a much better job on analysis. Here is one example:

http://www.anandtech.com/show/3963/z...benchmarking/2

Notice how the text analyzing the chart is actually reflective of its contents:

Initially, the two SAN boxes deliver similar performance, with the Promise box at 2200 IOPS and the ZFS box at 2500 IOPS. The ZFS box with a L2ARC is able to magnify its performance by a factor of ten once the L2ARC is completely populated!

If you read through Anandtech's articles, you will see insightful comments about why things perform the way that they do. Their site is having some technical difficulties, so their SSD articles, which are the best examples of this, are offline, but just about all of their reviews on new things go into architectural details and why things perform the way that they do.

Why don't we see that here? Should the fact that this site focuses on Linux mean that a lower standard of benchmarking is acceptable? I find I can never rely on headlines or other statements here because they are not reflective of the actual benchmark results. I have to see the charts and even then, they are difficult to interpret given the paragraph format describing the test setup.

[elanthis]

How about benchmarks on lower end CPUs? The people without usable GPUs/drivers probably don't have i7's.

[Shining Arcanine]

To elaborate some more on the quality of the benchmarks here in comparison to the quality of the benchmarks at Windows-focused sites, some times I really do not have a clue as to what is happening in the background, so the benchmarks are worthless to me, as I can neither rely on their descriptions nor on the actual numbers. If I go to a site like Anandtech, The Tech Report or HardOCP, that never happens. They go out of their way to provide clear descriptions of what is happening behind the scenes, but I never see that here.

The standards for benchmarking that Windows-focused benchmarking sites maintain are far higher than those maintained here. If a Windows-focused benchmarking site like Anandtech made a serious attempt to branch out into Linux benchmarking, I find it difficult to believe anyone would come here. Please try to be more insightful in future benchmarks and try to have descriptions match what the actual charts say. It is always disconcerting to read one thing in the review and then wonder whether or not the accompanying chart is the same chart that the author interpreted when he wrote about it.

[damipereira]

It would be nice if every time some line doesn't appear, or dissapear at an specific resolution, you would explain exactly how it didn't work.
About the article, llvm-pipe might be useful to replace current soft renderer for drawing interfaces(2d), in qt/gtk/etc.
AFAIK raster backend of qt is mostly cpu powered and lots of times it works better than opengl. Also if this drivers works good, it would be really nice, because once for all we could trust that desktop will feel snappy, no matter what drivers/x11/mesa/distro/kernel combination you're using as long as you have semi-updated llvmpipe.

[HyperDrive]

How about benchmarks on lower end CPUs? The people without usable GPUs/drivers probably don't have i7's.

^ this. I'd love to see LLVMpipe tested on an Atom 330 (even though LLVM didn't do optimal instruction scheduling for the Atom pipeline, last time I checked).

[FireBurn]

I think the main thing these articles always miss is LLVMpipe wasn't created for running games or even to power your 3D desktop effects, it's to help debug the state trackers

Whilst it has many potential applications it's primary function is to help developers not play Quake3 on a powerful CPU (which is terribly power inefficient)

[Shining Arcanine]

^ this. I'd love to see LLVMpipe tested on an Atom 330 (even though LLVM didn't do optimal instruction scheduling for the Atom pipeline, last time I checked).

This can barely run things on an i7. You should not be running it on an Atom.

[HyperDrive]

This can barely run things on an i7. You should not be running it on an Atom.

Well, swrast runs (ok, crawls) on an Atom, I've been doing it for some time on my nVIDIA ION system (no blobs, thanks). Why not run LLVMpipe if it turns out to be faster? I'd say it's mostly expectation management.

[aaaantoine]

At this point I'm wondering what would be better at rendering graphics: my no-T&L Radeon Xpress 1100, or my 1.6GHz Turion 64 X2. And if it's the latter, how would I go about setting this up?