Fake MSAA Support Added To LLVMpipe, Yields OpenGL 3.0/3.2

[phoronix]

Phoronix: Fake MSAA Support Added To LLVMpipe, Yields OpenGL 3.0/3.2

Months ago there was work on advancing Gallium3D's LLVMpipe software-based driver with its OpenGL 3.x support, including work-in-progress patches, but nothing was merged at the time. With that said, it was a surprise to see fake MSAA support added tonight for Gallium3D and used by the LLVMpipe driver so it fakes OpenGL 3.0 compliance and forces the necessary extensions for handling OpenGL 3.2...

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

[Shnatsel]

What would be really interesting to see is a benchmark of LLVMpipe versus virtual machine OpenGL passthrough. At least in VirtualBox LLVMpipe seems to run faster (and with less glitches too!) than VirtualBox guest OpenGL driver. I wonder how VMware compares.

[GreatEmerald]

So, does that mean we'll be able to run Unigine demos on LLVMpipe soon?

[russofris]

So, does that mean we'll be able to run Unigine demos on LLVMpipe soon?

"Run" them? No. "Walk" them? Yes.

[smitty3268]

Why fake it?

I don't understand why they implemented a fake AA rather than just implementing it for real.

Obviously, yes, it would be very slow. But that should be somewhat expected for a software renderer. I can think of lots of different scenarios where someone might actually want to use AA on llvmpipe.

Wouldn't the better solution be to implement real support, and then add an environment variable to disable it and do this fake implementation if the user wants to speed things up in their app which is using AA?

I'm pretty sure MS's D3D software renderer (WARP) provides real AA.

[strcat]

I don't understand why they implemented a fake AA rather than just implementing it for real.

Obviously, yes, it would be very slow. But that should be somewhat expected for a software renderer. I can think of lots of different scenarios where someone might actually want to use AA on llvmpipe.

Wouldn't the better solution be to implement real support, and then add an environment variable to disable it and do this fake implementation if the user wants to speed things up in their app which is using AA?

I'm pretty sure MS's D3D software renderer (WARP) provides real AA.

Implementing it would require significantly more work, so you're going to need to find someone interested in spending their time on something without much of a use case.

[GreatEmerald]

Obviously, yes, it would be very slow. But that should be somewhat expected for a software renderer. I can think of lots of different scenarios where someone might actually want to use AA on llvmpipe.

Do tell, because I honestly can't think of a single one of those...

[Szzz]

Do tell, because I honestly can't think of a single one of those...

You may want to render video with AA. Quality would be more important then speed.

[strcat]

You may want to render video with AA. Quality would be more important then speed.

I don't think MSAA has any meaning on a video... other post-processing anti-aliasing mechanisms would work.

[smitty3268]

Do tell, because I honestly can't think of a single one of those...

Lets say i want to render a 2D user interface in my application using OpenGL. It's simple enough that performance doesn't matter, but sharp edges and an ugly look is going to immediately annoy my users. So i choose to enable AA to smooth everything out.

Or how about if i'm doing offscreen rendering. I don't care about speed, i just want to start my render and come back in a few hours and have it look as nice as possible.

I'm sure there are many others if i can come up with those just off the top of my head.