[Mesa-dev] llvmpipe MSAA (Was: Fwd: [Mesa-users] Issues with removal of classic OSMesa)

Jose Fonseca jfonseca at vmware.com
Wed Jan 6 10:06:03 UTC 2021

That's an interesting idea!

llvmpipe rasterization is complicated and very optimized, so changing llvmpipe's rasterizer to spit out MSAA coverages is very hard.  I think that a good way to approach this is to:

1) continue to do single sample rasterization, but adjust the line coeffs of the triangles edges (in llvmpipe rasterizer code known as plane coefficients) to do conservative rasterization (ie, so that any fragment that intersects a triangle is covered) when MSAA is enabled.  See https://developer.nvidia.com/content/dont-be-conservative-conservative-rasterization

2) once inside the fragment shader, compute SampleMaskIn from the unadjusted vertex positions, using the desired number of samples (and corresponding sample pattern)

None of this would be throwaway work: the SampleMaskIn are correct and could be used for full MSAA support in the future too, and the conservative rasterization could be a feature on its own right too eventually.


From: mesa-dev <mesa-dev-bounces at lists.freedesktop.org> on behalf of Marek Olšák <maraeo at gmail.com>
Sent: Wednesday, January 6, 2021 05:57
To: Brian Paul <brianp at vmware.com>
Cc: mesa-dev at lists.freedesktop.org <mesa-dev at lists.freedesktop.org>; mesa-users at lists.freedesktop.org <mesa-users at lists.freedesktop.org>
Subject: Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa


llvmpipe could implement line and polygon smoothing by rasterizing in MSAA and passing the coverage to SampleMaskIn in the fragment shader, but doing Z/S tests and color writes and everything else single-sampled. Then, FragColor.a *= bitcount(SampleMaskIn) / (float)num_samples. It's roughly what OpenGL requires. There is at least one other gallium driver that does that.


On Mon, Jan 4, 2021 at 3:02 PM Brian Paul <brianp at vmware.com<mailto:brianp at vmware.com>> wrote:
Hi Andreas,

I'm forwarding your message to the mesa-dev list for better visibility.

BTW, when you say "antialiasing" below, what exactly do you mean?


-------- Forwarded Message --------
Subject:        [Mesa-users] Issues with removal of classic OSMesa
Date:   Thu, 31 Dec 2020 12:56:04 +0100
From:   Andreas Fänger <a.faenger at e-sign.com<mailto:a.faenger at e-sign.com>>
To:     mesa-users at lists.freedesktop.org<mailto:mesa-users at lists.freedesktop.org>


I've just seen that classic OSMesa has been removed (again) from Mesa3D
a few weeks ago with this commit "mesa: Retire classic OSMesa".

We are still actively using classical OSMesa for high quality rendering
of still images in a headless environment with no GPU support
(server-based rendering on windows and linux)

Unfortunately, none of the alternative software renderers provide all
the features that we require, which is antialiasing and anisotropic
filtering. The current state is (correct me if I'm wrong)

* softpipe: anisotropic filtering is supported, no antialiasing

* llvmpipe: no anisotropic filtering, has MSAA

* openswr: no anisotropic filtering, has MSAA, no OSMesa interface (?)

We had hoped that classical OSMesa is only removed when there is a full
replacement after the discussions in 2016 when OSMesa was about to be
removed for the first time



and the commit that reverted the removal


Are there any plans to enhance the renderers so that at least one of
them is providing both anisotropic filtering and antialiasing?

As far as I know, anisotropic texture filtering is also one of the
OpenGL 4.6 requirements.

In 2016 I was told that there are only very few developers involved in
llvmpipe and that chances are not high that someone is going to port the
softpipe anisotropic filtering implementation as llvmpipe is much more
complex. Is there any change in that situation?

If there are no such plans, is there any chance of reverting this commit
again so that classical OSMesa is available for windows and linux in
mesa >20?


Andreas Fänger

mesa-dev mailing list
mesa-dev at lists.freedesktop.org<mailto:mesa-dev at lists.freedesktop.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20210106/8e7784c8/attachment.htm>

More information about the mesa-dev mailing list