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 <bri...@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.faen...@e-sign.com> > To: mesa-us...@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@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev