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

Eric Anholt <[email protected]>
Newsgroups gmane.comp.video.mesa3d.devel,gmane.comp.video.mesa3d.user
Message-ID <CADaigPUgQbrYp5L-wmbvFJmeX71gei1AWqgo_FNo5omtE1S62A@mail.gmail.com>
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 <[email protected]> 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 <[email protected]>
> To:     [email protected]
>
> 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
> [email protected]
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.