[Mesa-dev] Anisotropic filtering in llvmpipe

Fri Jun 10 21:41:04 UTC 2016

Am 10.06.2016 um 20:39 schrieb 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.

Honestly, that it's too slow to be really useful is just guesswork -
this is also partly based on the notion that llvmpipe is useful as a
fallback if for whatever reason there's no hw acceleration, and it's
more important to have somewhat usable performance rather than 100%
accurate results.
It is possible it's not too bad in practice. Basically, calculating the
anisotropy ratio to determine how many additional samples are needed
along one axis shouldn't be too bad. So, if the ratio is low (in the
best case no additional samples are needed) I would assume it shouldn't
be that bad. Only if the ratio is high the hit is likely going to be
very heavy (with 16x aniso you need 16 times the samples in the worst
case, that's a LOT of fetches). So, if on average the ratio is low
(which is hopefully the case in practice), it might not be THAT bad.

Roland

> 
> On Fri, Jun 10, 2016 at 12:21 PM, Roland Scheidegger <sroland at vmware.com
> <mailto: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
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_archives_mesa-2Dcommit_2011-2DMay_030692.html&d=CwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=TYyLb1UbJn5urcrjhSsw7uBmJjdqwVgATGJeGYnZeAs&s=wb5lzqLLgeuTDMPIpyV5ritMDyNtgLuIuZC2QrJsKyc&e=>
>     > -
>     > softpipe: https://lists.freedesktop.org/archives/mesa-commit/2011-June/030966.html
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_archives_mesa-2Dcommit_2011-2DJune_030966.html&d=CwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=TYyLb1UbJn5urcrjhSsw7uBmJjdqwVgATGJeGYnZeAs&s=qdWwDhBOEXrsNHg3sjtH5usydoJv26IVmt-9vMNnFRk&e=>
>     >
>     > GitHub mirrors for readability:
>     >
>     > -
>     > swrast: https://github.com/freedreno/mesa/commit/8a98aabe0bcea42cfdc982001ae4876e3d9b1214
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_freedreno_mesa_commit_8a98aabe0bcea42cfdc982001ae4876e3d9b1214&d=CwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=TYyLb1UbJn5urcrjhSsw7uBmJjdqwVgATGJeGYnZeAs&s=xBkgZEvbUAGFWG9dW1rFroMsC9a_7-DtiJgXYDC2lo4&e=>
>     > - https://github.com/freedreno/mesa/commit/f4537f99cc83cb8133f66dc97c613e95dc0fe162
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_freedreno_mesa_commit_f4537f99cc83cb8133f66dc97c613e95dc0fe162&d=CwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=TYyLb1UbJn5urcrjhSsw7uBmJjdqwVgATGJeGYnZeAs&s=7zk2NUX4CZZEuWNGhJk8IjIVDh5al3hlEfJ-G5kWgyM&e=>
>     >
>     > 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
> 
> 