[Mesa-dev] [PATCH] scons: build osmesa swrast and gallium

[Andreas Fänger]

> -----Ursprüngliche Nachricht-----
> Von: Roland Scheidegger Gesendet: Mittwoch, 9. März 2016 17:31
> Betreff: Re: [Mesa-dev] [PATCH] scons: build osmesa swrast and gallium
> 
> Am 09.03.2016 um 08:41 schrieb Andreas Fänger:
> >> -----Ursprüngliche Nachricht----- Von: Roland Scheidegger Gesendet:
> >> Dienstag, 8. März 2016 18:26 Betreff: Re: [Mesa-dev] [PATCH] scons:
> >> build osmesa swrast and gallium
> >>
> >> Not that I really care what you can or can't build (and I won't
> >> comment on build changes), what are those features lacking in
> >> llvmpipe, beside from anisotropic filtering (which I always
> >> considered essentially useless for a software renderer, albeit
> >> interesting if you're curious about the math involved)? Last time I
> >> checked llvmpipe/softpipe had a much more robust feature set
> >> (especially when it comes to non-legacy GL features), for starters
> >> I'll just mention working derivatives which is usually the first
> >> thing people still using classic swrast are hitting bugs on...
> >>
> >
> > We are using osmesa for rendering single images on a server. No
> > shaders at the moment, only texturing (fixed function pipeline). For
> > us the qualitiy of the images is the most important criteria (and
> > rendering speed, of course); therefore anisotropic filtering is
> > absolutely necessary in order to achieve good looking images. The same
> > with anti-aliasing: Currently we are using  GL_POLYGON_SMOOTH but this
> > is also missing in gallium. We need an antialiasing method that is not
> > simply blurring the whole image or texturese but affects only the
> > edges of the polygons.
> 
> Ah ok. Gallium supports polygon smooth but the sw rasterization drivers do
> not, it isn't supported by quite a lot of hw drivers neither (I wasn't even
> aware swrast did), albeit of course hw drivers typically support msaa
> (chances of llvmpipe getting support for msaa one day is probably a lot higher
> than for polygon_smooth, albeit maybe the latter could use mostly the same
> code as the former...).
> Anisotropic would be interesting to implement, but it was just something
> easy to skip (since no apis really require it) - there's just not many developers
> working on llvmpipe...
> Just don't get your hopes up for better support of modern GL features for
> classic swrast.
> 

We are interessted in using llvmpipe, however, this is why we currently cannot do the switch and have to stick to classic mesa.
It would be really great if msaa (or GL_POLYGON_SMOOTH) would be implemented in llvmpipe together with anisotropic filtering in the near future. There already is an implementation for anisotropic filtering for softpipe (and swrast), so maybe it's possible that one of the llvmpipe developers could port it? If people are concerned with speed, maybe make it optional and provide a compiler flag to turn it on or off?

Andreas