[Mesa-users] [Mesa-dev] Fwd: Issues with removal of classic OSMesa

[Eric Anholt]

Classic swrast didn't have MSAA either, so it sounds like softpipe
meets your requirements as stated.

I suspect actually by MSAA you meant GL_POLYGON_SMOOTH_HINT, the weird
old sometimes-it-gets-you-coverage-in-alpha-output knob.  Since you're
software rasterizing, I'd recommend that you instead render at a
higher res and downscale-- I suspect this with llvmpipe would be
faster overall, and you'd get better quality even with aniso disabled.
I feel like removing swrast support for GL_POLYGON_SMOOTH_HINT is
fairly legitimate -- intel doesn't support it either, and it is just
supposed to be a hint for the pre-msaa world.

We ought to sort out aniso for llvmpipe anyway, though I don't know
much about implementing it, and the fact that conformance doesn't
detect lack of any aniso is a big disappointment.  I heard ajax was
poking at resurrecting msaa for softpipe, which would clear out a lot
of our conformance fails there, and might avoid the need for user code
changes if 4x MSAA is enough.

On Mon, Jan 4, 2021 at 12:01 PM Brian Paul <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?
>
> -Brian
>
>
> -------- 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>
> To:     mesa-users at lists.freedesktop.org
>
> Hi,
>
> 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
>
> https://lists.freedesktop.org/archives/mesa-dev/2016-March/109665.html
>
> https://lists.freedesktop.org/archives/mesa-users/2016-March/001132.html
>
> and the commit that reverted the removal
>
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=9601815b4be886f4d92bf74916de98f3bdb7275c
>
> 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?
>
> Regards,
>
> Andreas Fänger
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev