[Mesa-dev] Anisotropic filtering in llvmpipe

[Alan Thomas]

Thanks so much for the quick and thorough reply.

Also, texture filtering is very slow compared to gpu hw already (in
> comparison to shader arithmetic), so most likely the performance hit
> will be quite large, making this only really useful in few cases.


This is something I hadn't really considered yet... that just adding
anisotropic could dramatically slow things down even if it's in llvmpipe.
Some initial testing showed that llvmpipe was plenty fast for our needs
with only linear filtering and without anisotropic, and that softpipe was
too slow with anisotropic, but I never confirmed to see if softpipe was
substantially faster with only linear filtering and that it was just the
sheer overhead of anisotropic filtering that slowed it down.. in which case
we might see something proportional with anisotropic in llvmpipe.

I'll do some more perf testing with the different variations– possibly
finding a quality that's close to anisotropic but more performant than
softpipe would be enough, even if it's not as high quality as the softpipe
implementation. Then again, maybe not worth implementing if it doesn't get
much higher quality than linear.

On Fri, Jun 10, 2016 at 12:21 PM, Roland Scheidegger <sroland at vmware.com>
wrote:

> Am 10.06.2016 um 18:01 schrieb Alan Thomas:
> > Hi mesa-dev,
> >
> > Working through a current server-side OpenGL rendering project, our team
> > is running into hurdles with regard to anisotropic filtering. Aniso is a
> > hard dependency for our rendering needs, but softpipe/swrast (which
> > support aniso) are too slow performance-wise. Llvmpipe doesn't currently
> > support anisotropic filtering, as far as I can tell.
> >
> > So, we are using GPU hardware in production, which is costly and not as
> > portable or repeatable as a software-based renderer might be.
> >
> > My question: what are the hurdles to implementing anisotropic filtering
> > in llvmpipe? Has there been any recent discussion about it?
> The main hurdle is that there's not really many developers working on
> llvmpipe, and those that work on it have no immediate need for it (since
> it is generally not required by APIs, even dx10 only requires
> anisotropic to be at least as good as linear filtering).
> Also, texture filtering is very slow compared to gpu hw already (in
> comparison to shader arithmetic), so most likely the performance hit
> will be quite large, making this only really useful in few cases.
>
> >
> > I found these implementations for swrast and softpipe by Andreas Faenger
> > in 2011:
> >
> > -
> > swrast:
> https://lists.freedesktop.org/archives/mesa-commit/2011-May/030692.html
> > -
> > softpipe:
> https://lists.freedesktop.org/archives/mesa-commit/2011-June/030966.html
> >
> > GitHub mirrors for readability:
> >
> > -
> > swrast:
> https://github.com/freedreno/mesa/commit/8a98aabe0bcea42cfdc982001ae4876e3d9b1214
> > -
> https://github.com/freedreno/mesa/commit/f4537f99cc83cb8133f66dc97c613e95dc0fe162
> >
> > Could Andreas's implementation be ported to llvmpipe in a relatively
> > straightforward manner, or are there performance considerations in
> > llvmpipe that make that algorithm less than ideal? Maybe some shortcuts
> > similar to hardware implementations?
> The algorithm should be suitable just fine. It is probably quite some
> effort to make it work in llvmpipe though (the branchy nature (depending
> on how many samples you actually need) probably makes it quite some
> work). There's also two paths for filtering (AoS for simple formats
> which is faster, vs. SoA for everything), though you could certainly
> force the SoA path easily if you wouldn't want to bother with two
> implementations.
> Shortcuts could be done as well. Albeit to my knowledge, current hw no
> longer does that. (That said, there are some questionable shortcuts wrt
> to bilinear filtering and lod calculations in llvmpipe (it is possible
> to switch them off but only in debug builds, should make it switchable
> in release builds as well probably at some point) so there's certainly
> precedence there.)
>
> >
> > I've considered potentially garnering internal support to sponsor the
> > development financially and would also be curious if that would be
> > welcomed by the project (if I can get support)... and if so, if there
> > would be any individual who would be best suited to handle the
> > implementation.
>
> Patches would certainly be welcome - if necessary it would be easy
> enough to disable it based on env var or whatever if for some cases
> performance vs. quality tradeoff isn't worth it.
> I suppose sponsoring is fine if you find someone who has the time and
> knowledge to do it...
>
> Roland
>
>


-- 
*Alan Thomas*
Senior Manager, Engineering
GitHub @alanctkc <https://github.com/alanctkc> | 816-805-4272

minted.
http://www.minted.com/
747 Front Street, Suite 200, San Francisco, CA 94111
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160610/13169f49/attachment.html>