Linked by David Adams on Tue 29th Jun 2010 18:01 UTC, submitted by Michael
Graphics, User Interfaces The open-source Mesa/X.Org developers have been working on LLVMpipe, a Gallium3D driver that accelerates OpenGL and other state trackers on the CPU rather than any GPU driver to provide a better software rasterizer via LLVM optimizations. Unfortunately, it's still slow and can barely keep up with games.
Order by: Score:
change setup.
by fithisux on Tue 29th Jun 2010 20:59 UTC
fithisux
Member since:
2006-01-22

The setup I believe is wrong. A six-core phenom would be cheaper and more appropriate. Hyperthreading is not suitable for this kind of load. Actually two hyperthreads on the same cpu should run uncorrelated loads, not identical loads. Please try with the phenom and then the discussion makes sense. The pitfall of the measurements is well known.

Edited 2010-06-29 21:00 UTC

Reply Score: 3

TTA-based Codesign Environment (TCE)
by tyrione on Tue 29th Jun 2010 21:43 UTC
tyrione
Member since:
2005-11-21

This new blog entry for LLVM seems promising:

TCE project: Co-design of application-specific processors with LLVM-based compilation support

http://blog.llvm.org/2010/06/tce-project-co-design-of-application.h...

Reply Score: 2

"Still slow"?
by Zifre on Tue 29th Jun 2010 23:25 UTC
Zifre
Member since:
2009-10-04

The title of the article is messed up. LLVMpipe is "still slow"?

It's a software renderer! Is it supposed to beat the NVIDIA GPU used in the test?

It's already quite optimized. It's several times faster than Mesa's old software renderer. I'd say that it's very impressive for how new it is.

This is why I hate Phoronix...

Reply Score: 5

RE: "Still slow"?
by Neolander on Wed 30th Jun 2010 08:54 UTC in reply to ""Still slow"?"
Neolander Member since:
2010-03-08

Well, I'd like a comparison with Haiku's drawing engine in terms of 2D performance myself ^^

By the way, can someone tell me how changing the compiler, would the new one be blessed by Apple's touch or not, is supposed to lead to a tremendous improvement in software performance ? I mean, GCC has been here for a long time, so the remaining performance improvement to be done in the compiler area are probably either of the nitpicking kind (1% size improvement in a very specific use case) or leading to compilation being 10 times slower...

Reply Score: 3

RE[2]: "Still slow"?
by boofar on Wed 30th Jun 2010 13:37 UTC in reply to "RE: "Still slow"?"
boofar Member since:
2008-04-23

The driver itself is was probably compiled with GCC; however LLVM is being used internally to JIT-compile rendering instructions (probably in the form of OpenGL Shading Language) into some internal form (or native code, I don't know). Using GCC for that would probably be rather awkward.

Anyway, software rendering is slow compared to dedicated hardware? Mindblowing!!! [/irony]

Reply Score: 1

RE[2]: "Still slow"?
by Zifre on Wed 30th Jun 2010 13:49 UTC in reply to "RE: "Still slow"?"
Zifre Member since:
2009-10-04

LLVM is only used for code generation - the driver is most likely still compiled with GCC.

GCC is generally slightly faster than LLVM, but it takes at least 10 times as many man-hours to use GCC's backend as it does to use LLVM (and I'm really not exaggerating there).

Also, while GCC might produce slightly faster code, LLVM can do its optimizations and code generation several times faster, which is important for startup speed, when you have to generate an entire OpenGL software renderer plus shaders.

Reply Score: 2

RE: "Still slow"?
by WereCatf on Wed 30th Jun 2010 12:33 UTC in reply to ""Still slow"?"
WereCatf Member since:
2006-02-15

The title of the article is messed up. LLVMpipe is "still slow"?

It's a software renderer! Is it supposed to beat the NVIDIA GPU used in the test?

It's already quite optimized. It's several times faster than Mesa's old software renderer. I'd say that it's very impressive for how new it is.


There is no mention about image quality of LLVMpipe anywhere, but I assume it produces quite nearly the same output as a real 3D accelerator does. As such, pushing 25fps+ is already quite damn well IMHO. That's a truckload of stuff to do on a processor that isn't optimized for such tasks and thus I atleast find it pretty darn impressive to churn out such numbers.

If the developers can still push some more performance out of it and continue to add the missing bits LLVMpipe will become quite a useful piece of software.

If any of the devs are reading this: congrats with the great work so far and good luck ;)

Reply Score: 3

RE[2]: "Still slow"?
by Zifre on Wed 30th Jun 2010 13:37 UTC in reply to "RE: "Still slow"?"
Zifre Member since:
2009-10-04

There is no mention about image quality of LLVMpipe anywhere, but I assume it produces quite nearly the same output as a real 3D accelerator does.

Unless there you are using some unsupported feature, or there is a bug, the image should be pixel perfect. Rendering is a very precise thing - there is really no room for "optimization" at the expense of quality.

Also, I suspect that LLVMpipe is more complete than any of the real Gallium drivers - programming the CPU is a lot easier than a GPU... (and I know because I've tried it).

So yeah, 25 FPS in any 3D game is very impressive.

Reply Score: 2

RE[3]: "Still slow"?
by WereCatf on Wed 30th Jun 2010 14:07 UTC in reply to "RE[2]: "Still slow"?"
WereCatf Member since:
2006-02-15

Unless there you are using some unsupported feature, or there is a bug, the image should be pixel perfect. Rendering is a very precise thing - there is really no room for "optimization" at the expense of quality.

I have seen some software rasterizers that went the easy route of rendering things poorly, doing horrible mipmapping and all that just to squeeze some extra speed. The result just happened to usually be so ugly that those rasterizers never got too popular. Anyways, that's why I mentioned the fact that I didn't see Phoronix mention image quality of LLVMpipe: I assume they would have mentioned it if it wasn't atleast as good as that produced by the 3D hardware.

Now the real question is how useful will this be? What are the applications for a software rasterizer in an age where almost everything -- including damn small mobile devices -- packs some sort of a 3D accelerator?

A rendering farm, perhaps? Remote-3D? That I could see being midly useful as normally you have to render the image, then download the image from the card and only then encode it and transmit, but with this you can just render directly to a buffer and encode, or even render directly to hardware buffer that handles the encoding and transmitting.

Oh, and once CPUs have enough beef and LLVMpipe matures and gains some more speed improvements it'll be handy not to have to upgrade your graphics hardware if some features are missing or something: LLVMpipe will continue to push out the latest features and you never have to play the catchup-game regarding 3D features anymore.

Just to open up some discussion -- or atleast TRY to -- would anyone else have some interesting insight or possible applications for this to share? Would be lovely to see what others can come up with. (And god damn we need some proper discussion here on OSNews and not just the usual flaming!)

Reply Score: 2

RE[4]: "Still slow"?
by Zifre on Wed 30th Jun 2010 15:54 UTC in reply to "RE[3]: "Still slow"?"
Zifre Member since:
2009-10-04

Now the real question is how useful will this be? What are the applications for a software rasterizer in an age where almost everything -- including damn small mobile devices -- packs some sort of a 3D accelerator?

I believe that the main use will be running Gnome-Shell or Compiz (which require compositing) on hardware that doesn't support OpenGL or doesn't have drivers installed (i.e. NVIDIA GPUs without good Nouveau support, because the blob can't be installed by default).

Reply Score: 2

RE[3]: "Still slow"?
by Bill Shooter of Bul on Wed 30th Jun 2010 14:23 UTC in reply to "RE[2]: "Still slow"?"
Bill Shooter of Bul Member since:
2006-07-14

I didn't think all rendering was the same. Isn't the rendering accuracy the difference between the consumer and pro versions of cards like Radeon vs FirePro3D?

http://en.wikipedia.org/wiki/ATI_FireGL#Differences_with_the_Radeon...

Reply Score: 2