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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
