LLVMpipe Doesn't Yet Like The GNOME Shell

[phoronix]

Phoronix: LLVMpipe Doesn't Yet Like The GNOME Shell

Last week we published our first benchmarks of LLVMpipe, which is a new driver for Gallium3D that's to serve as a software rasterizer on the CPU. LLVMpipe is ideal for cases where a GPU is not available or supported and it leverages LLVM (the Low-Level Virtual Machine) for optimization and providing much better software acceleration than Mesa's traditional software rasterizer or Gallium3D's previous Softpipe driver. LLVMpipe really likes modern, fast processors with SSE3/SSE4 support especially for best performance, but will work with nearly any 64-bit Intel/AMD processor. Unfortunately, LLVMpipe doesn't yet play well with GNOME Shell...

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

[xir_]

That actually was a really good point. it would be amazing to be able to offer a consistent desktop experience for all users.

[cb88]

That actually was a really good point. it would be amazing to be able to offer a consistent desktop experience for all users.

No you should offer a *good* experience to all users... loading down your CPU with bling will not do that. This is little more than proof of concept unless we get oct-channel ram and 16 way processing :-)

If a computer doesn't have a 3d accelerator you shouldn't be doing 3d...and running compiz or gnomeshell would defeat the purpose of LLVMpipe as well (which is to make software rendering better as they would slow any 3d operations down in user software significantly.)

LLVMpipe will let people without a 3d card and a fast CPU play a few opengl games... but little more

[cb88]

Also note that the compiz white screen is just textures not being rendered (lack of texture from pixmap I think) if you rotate the desktop you can clearly see the "cube caps" are rendered correctly

[hax0r]

Hmm I just tried this gnome-shell thingy but seems like nouveau is tad broken:

[SmSpillaz]

LLVMpipe, Softpipe and Swrast don't have a GLX_EXT_texture_from_pixmap implentation in the driver yet (even though libGL says they do). This means that texture binding on either compiz or mutter will always instantly fail

[tulcod]

Phoronix, you just made my day. I knew the quality of your articles has never been high, though you have always been able to provide unique stories and are often the first to publish new happenings on the FOSS GPU driver front.

However, what you just posted is a blast. It's a bug report, and a particularly long one, too. You didn't provide a backtrace, not a hint where the problem may lie. You simply stated "hey, we tried running development software x on development software y, and it didn't work". And it only took you 608 words. Thank you for filling my feed reader, this is the best day of my life.

[hax0r]

However, what you just posted is a blast. It's a bug report, and a particularly long one, too. You didn't provide a backtrace, not a hint where the problem may lie. You simply stated "hey, we tried running development software x on development software y, and it didn't work". And it only took you 608 words. Thank you for filling my feed reader, this is the best day of my life.

Who said that he has to fill out bugs and give backtracks etc. It's reality. Go and fill out bugs yourself, like it's going to be fixed right away since no one knows about or cares.

[drago01]

Well this looks like the glx_tfp implementation is broken (which also explains the white screen when running compiz).

[nanonyme]

Well this looks like the glx_tfp implementation is broken (which also explains the white screen when running compiz).

Though if we believe SmSpillaz - and why should we - it's more non-existing than broken.