<div dir="ltr">Thanks so much for the quick and thorough reply.<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">Also, texture filtering is very slow compared to gpu hw already (in</span><br style="font-size:12.8px"><span style="font-size:12.8px">comparison to shader arithmetic), so most likely the performance hit</span><br style="font-size:12.8px"><span style="font-size:12.8px">will be quite large, making this only really useful in few cases.</span></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 10, 2016 at 12:21 PM, Roland Scheidegger <span dir="ltr"><<a href="mailto:sroland@vmware.com" target="_blank">sroland@vmware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Am 10.06.2016 um 18:01 schrieb Alan Thomas:<br>
> Hi mesa-dev,<br>
><br>
> Working through a current server-side OpenGL rendering project, our team<br>
> is running into hurdles with regard to anisotropic filtering. Aniso is a<br>
> hard dependency for our rendering needs, but softpipe/swrast (which<br>
> support aniso) are too slow performance-wise. Llvmpipe doesn't currently<br>
> support anisotropic filtering, as far as I can tell.<br>
><br>
> So, we are using GPU hardware in production, which is costly and not as<br>
> portable or repeatable as a software-based renderer might be.<br>
><br>
> My question: what are the hurdles to implementing anisotropic filtering<br>
> in llvmpipe? Has there been any recent discussion about it?<br>
</span>The main hurdle is that there's not really many developers working on<br>
llvmpipe, and those that work on it have no immediate need for it (since<br>
it is generally not required by APIs, even dx10 only requires<br>
anisotropic to be at least as good as linear filtering).<br>
Also, texture filtering is very slow compared to gpu hw already (in<br>
comparison to shader arithmetic), so most likely the performance hit<br>
will be quite large, making this only really useful in few cases.<br>
<span class=""><br>
><br>
> I found these implementations for swrast and softpipe by Andreas Faenger<br>
> in 2011:<br>
><br>
> -<br>
> swrast: <a href="https://lists.freedesktop.org/archives/mesa-commit/2011-May/030692.html" rel="noreferrer" target="_blank">https://lists.freedesktop.org/archives/mesa-commit/2011-May/030692.html</a><br>
> -<br>
> softpipe: <a href="https://lists.freedesktop.org/archives/mesa-commit/2011-June/030966.html" rel="noreferrer" target="_blank">https://lists.freedesktop.org/archives/mesa-commit/2011-June/030966.html</a><br>
><br>
> GitHub mirrors for readability:<br>
><br>
> -<br>
> swrast: <a href="https://github.com/freedreno/mesa/commit/8a98aabe0bcea42cfdc982001ae4876e3d9b1214" rel="noreferrer" target="_blank">https://github.com/freedreno/mesa/commit/8a98aabe0bcea42cfdc982001ae4876e3d9b1214</a><br>
> - <a href="https://github.com/freedreno/mesa/commit/f4537f99cc83cb8133f66dc97c613e95dc0fe162" rel="noreferrer" target="_blank">https://github.com/freedreno/mesa/commit/f4537f99cc83cb8133f66dc97c613e95dc0fe162</a><br>
><br>
> Could Andreas's implementation be ported to llvmpipe in a relatively<br>
> straightforward manner, or are there performance considerations in<br>
> llvmpipe that make that algorithm less than ideal? Maybe some shortcuts<br>
> similar to hardware implementations?<br>
</span>The algorithm should be suitable just fine. It is probably quite some<br>
effort to make it work in llvmpipe though (the branchy nature (depending<br>
on how many samples you actually need) probably makes it quite some<br>
work). There's also two paths for filtering (AoS for simple formats<br>
which is faster, vs. SoA for everything), though you could certainly<br>
force the SoA path easily if you wouldn't want to bother with two<br>
implementations.<br>
Shortcuts could be done as well. Albeit to my knowledge, current hw no<br>
longer does that. (That said, there are some questionable shortcuts wrt<br>
to bilinear filtering and lod calculations in llvmpipe (it is possible<br>
to switch them off but only in debug builds, should make it switchable<br>
in release builds as well probably at some point) so there's certainly<br>
precedence there.)<br>
<span class=""><br>
><br>
> I've considered potentially garnering internal support to sponsor the<br>
> development financially and would also be curious if that would be<br>
> welcomed by the project (if I can get support)... and if so, if there<br>
> would be any individual who would be best suited to handle the<br>
> implementation.<br>
<br>
</span>Patches would certainly be welcome - if necessary it would be easy<br>
enough to disable it based on env var or whatever if for some cases<br>
performance vs. quality tradeoff isn't worth it.<br>
I suppose sponsoring is fine if you find someone who has the time and<br>
knowledge to do it...<br>
<span class="HOEnZb"><font color="#888888"><br>
Roland<br>
<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><b>Alan Thomas</b><div>Senior Manager, Engineering</div><div>GitHub <a href="https://github.com/alanctkc" target="_blank">@alanctkc</a> | <span style="font-size:12.8000001907349px">816-805-4272</span></div><div><br></div><div><font color="#93c47d" size="4">minted.</font></div><div><a href="http://www.minted.com/" target="_blank">http://www.minted.com/</a><br></div><div><font size="1">747 Front Street, Suite 200, San Francisco, CA 94111</font><br></div></div></div></div></div></div></div></div></div>
</div>