LLVMpipe: OpenGL With Gallium3D on Your CPU

Phoronix: LLVMpipe: OpenGL With Gallium3D on Your CPU

The software rasterizer used in Mesa that allows for software acceleration of OpenGL on the CPU without any assistance from the graphics processor has largely been useless. Even with a modern-day, multi-core processor, the performance of Mesa's software rasterizer has been abysmal. The performance of Mesa classic DRI drivers have traditionally been poor anyways compared to the high-performance, proprietary NVIDIA/ATI graphics drivers, but when dealing with just the software rasterizer there really aren't any games or applications that run well. Fortunately, software acceleration on Gallium3D is very much a different story thanks to LLVM.

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

What I think is most interesting with these benchmark results is that the r300g driver seems to be A LOT faster than just a month ago. Check the graph for Open Arena in this article. Its about twice as fast with the same graphics card while the classic driver shows the same numbers. And as you can see in this new article the numbers are not at all cpu limited, so the weaker cpu in the older test should not be a factor.

Looks really promising. :)

Now this is cool!

Perhaps even cooler would be to use llvm-pipe to extend a graphics cards capabilities (eg. extensions the videocard doesn't come with) or to work together with the card's GPU to balance the workload.

Would that work? Could you, say, include some of llvm-pipe inside r300 where it is needed most?

That may work, but is slower than pure software rendering, because both GPU and CPU have their own memory. Copying buffers between those two is too expensive to be worthwile.

You could have a multiscreen-setup where one screen is software-rendered, then join both via Xinerama. But it'll likely be slower than a fully GPU-accelerated solution.


there's been some discussion about mixed hard- and software rendering in here.

Quote:

---

Originally Posted by rohcQaH

That may work, but is slower than pure software rendering, because both GPU and CPU have their own memory. Copying buffers between those two is too expensive to be worthwile.

You could have a multiscreen-setup where one screen is software-rendered, then join both via Xinerama. But it'll likely be slower than a fully GPU-accelerated solution.


there's been some discussion about mixed hard- and software rendering in here.

---

How about motherboard video that shares system RAM? It would be a major hack but maybe the software renderer could jump into the motherboard video ram and operate on it directly.

Quote:

---

Originally Posted by frantaylor

How about motherboard video that shares system RAM? It would be a major hack but maybe the software renderer could jump into the motherboard video ram and operate on it directly.

---

Shared Video is uncached memory so reading from it is SLOW (unless the movntdqa instruction is used but it a SSE4 instruction which is not available on all CPUs).

Simple question: Good enough to run KDE 4.4 desktop effects with it on a Phenom 9950 X4 (not OC'd)?

That is all I would like to have for now... And while I of course now do have mesa, how come Kwin does not want to run desktop effects? Wierd...

Quote:

---

Originally Posted by V!NCENT

Simple question: Good enough to run KDE 4.4 desktop effects with it on a Phenom 9950 X4 (not OC'd)?

That is all I would like to have for now... And while I of course now do have mesa, how come Kwin does not want to run desktop effects? Wierd...

---

Ah I see: OpenGL + fallback and disable functionality checks... But hell with the standard mesa rasterizer it is 0.01 fps or something:eek: :(

Mmmh, I'd like to see what llvmpipe will do with future Fusion and Sandy Bridge architectures. Those will offer much more execution units for such jobs.

Quote:

---

Originally Posted by V!NCENT

Simple question: Good enough to run KDE 4.4 desktop effects with it on a Phenom 9950 X4 (not OC'd)?

---

probably, but the simpler XRender based composition mode may be more suitable for software rendering.

Are you planning to run a headless machine with a vnc server or something? Otherwise anything that has a DVI port is capable of faster compositing.. they stopped selling those framebuffer-on-a-stick-devices 20 years ago.

Don't forget: with GPU acceleration, you can have cool 3D-effects AND run an application, too! ;)