[Mesa-dev] Anisotropic filtering in llvmpipe

[Roland Scheidegger]

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