LLVMpipe Gallium3D Driver Now Exposes OpenGL 4.0

[phoronix]

Phoronix: LLVMpipe Gallium3D Driver Now Exposes OpenGL 4.0

The LLVMpipe Gallium3D driver that provides a software/CPU-based OpenGL implementation for running on systems as a fallback path when no GPU / hardware OpenGL driver is available, a vendor-neutral path for debug purposes, and similar use-cases, now has OpenGL 4.0 support...

http://www.phoronix.com/scan.php?page=news_item&px=LLVMpipe-OpenGL-4.0

[uid313]

LLVMpipe is looking good, not much until OpenGL 4.4 support.
softpipe is looking good, not much until OpenGL 4.0 support.
virgl is looking good, only 1 feature left for OpenGL 4.5 support.

[R41N3R]

Nice progress. I'm quite interested in seeing Vallium evolve.

[schmidtbag]

Although I understand this is mostly meant to be a failsafe/fallback option, I think these software rasterizers need stuff like OGL4.x the most, since it allows GPUs without support (either because they're physically incapable or don't have enough driver development) to use those features. At least to my understanding, it can work that way. I'm actually not totally sure if you can mix up drivers like that.

[Michael]

Although I understand this is mostly meant to be a failsafe/fallback option, I think these software rasterizers need stuff like OGL4.x the most, since it allows GPUs without support (either because they're physically incapable or don't have enough driver development) to use those features. At least to my understanding, it can work that way. I'm actually not totally sure if you can mix up drivers like that.

No there is currently not such support and even still hitting those code paths and the added CPU <-> GPU latency would still be a mess for performance.

[schmidtbag]

No there is currently not such support and even still hitting those code paths and the added CPU <-> GPU latency would still be a mess for performance.

I guess there was a reason for my uncertainty. But, isn't a software solution used to assist the r600 drivers in OpenGL features it doesn't have/support? That might be where my confusion came in that you could mix drivers.

[Michael]

I guess there was a reason for my uncertainty. But, isn't a software solution used to assist the r600 drivers in OpenGL features it doesn't have/support? That might be where my confusion came in that you could mix drivers.

There is the "soft FP64" support specifically, but that isn't just magically re-using LLVMpipe or the like. Way back in the day was also some i915 work for using LLVM for handling some unsupported features, but again was all work done specifically for that within the driver and just not getting any advancements from LLVMpipe.

[kpedersen]

Although I understand this is mostly meant to be a failsafe/fallback option.

For many virtualization packages, LLVMpipe is the only option. It is also very useful for things like containers / jails to retain security and not need to provide access to the raw device.

And finally it is also very useful to make sure badly written software works on older hardware. For example badly written software overly consumes the latest features and LLVMpipe can mitigate against this. Gnome 3 for example would not be able to run without LLVMpipe.

[JustinTurdeau]

That might be where my confusion came in that you could mix drivers.

schmidtbag
Posts: 5058

This is your brain on Phoronix.

[starshipeleven]

And finally it is also very useful to make sure badly written software works on older hardware. For example badly written software overly consumes the latest features and LLVMpipe can mitigate against this. Gnome 3 for example would not be able to run without LLVMpipe.

It's not like it's just checking for the feature to be supported, it's actually doing something with it.

the jury is still out on the "GNOME 3 can run with LLVMpipe" question though. Especially on hardware that is so old (or is an embedded device) it does not support OpenGL 2.1, the CPU isn't really THAT powerful. My guess is that since LLVMPipe chokes modern hardware it will be completely unusable on old or weak hardware.