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.

Gallium3D's LLVMpipe Is Speeding Up

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.

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.

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.

Another suggestion about benchmark

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.

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.