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

[Roland Scheidegger]

Am 10.03.2016 um 08:47 schrieb 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?
> 

I'm afraid there aren't really many llvmpipe developers. Nowadays, that
would be mostly me - and I'm not currently working on it as I've got
other things to do...
I don't think aniso would really have to be disabled at compile time due
to performance concerns, with the jit code there'd only be a performance
loss if it's actually enabled, in which case that should be ok (albeit
if there's apps anyone is interested in running on llvmpipe which don't
let you disable it could still have an env var or whatever to disable it).
Patches are welcome, though...

Roland