[Impeller] Use 32 bit Gaussian function in the 2-pass blur

[bdero]

Resolves flutter/flutter#126487.

Increases the 2-pass blur quality and distribution limit.

It turns out sigma was breaking down beyond ~255 (moderately high, but not unreasonable for users to rely on). The Gaussian function computes sigma^2, and half precision floats only have 5 bit exponents and overflow for numbers above 65k.

Coincidentally, this also returns us to a state where we look a lot more like Skia's blurs for larger blur sigmas. Medium blurs have much less visual banding (although it's still there if you look closely). I suspect half precision isn't really enough for tracking the integral.

Unfortunately, this means our SIMD pipelining isn't going to be as good. I'll be interested in watching the blur-driven benchmarks for the perf hit.

Before Impeller:

After Impeller:

Skia:

[jonahwilliams]

LGTM.

We could also compute the integral on the CPU and expose via SSBO if performance is a problem. I suspect it will be fine though, texture read/write is the bottleneck

[zanderso]

If this turns out to be a regression for all sigmas, could we instead have two shaders, one for small sigmas, and one for large sigmas?

Or maybe only support up to some max sigma?

[jonahwilliams]

I think at that point we'd be better off computing the integral on the CPU.

[bdero]

We could also compute the integral on the CPU and expose via SSBO if performance is a problem.

The rub is that we still need the Gaussian function to weight the color, and so if we used a LUT for the integral we'd be exchanging only a few additions per cache miss (32 additions, since I think modern iPhones have 128 byte cache lines), which would likely work out to a net loss.

Precomputing the Gaussian function itself would probably work out to be a benefit if we're careful about cache management:

• The distribution width is continuous, and so we'd need to choose a max density and linear sample.
• To make the quality good enough for arbitrarily high radius values, we'd probably need to place few hundred samples in the LUT to avoid banding artifacts.
• To avoid the extreme overhead of cache misses when sampling the distribution with a small radius, we could mipmap the texture.
  • The only downside here is that, unless we trilinear filter (and ~double up the cache misses), then we're going to get visual color popping between mip levels as the blur sigma is animated.

[chinmaygarde]

From Triage: This is patched and we are waiting on framework benchmarks to determine viability for cherry-picking.

[bdero]

No relevant benchmark regressions showed up during the roll containing this change. Also, no malioc record adjustments. Texture fetches get reordered to start as soon as possible and happen in parallel, and so this is probably free because we have plenty of cycles to spare waiting for the texture sample within the scope of the loop.

[zanderso]

@bdero Since there were no perf regressions and the patch seems low-risk, could you file a CP request for this? cc @chinmaygarde

[kuemme01]

It seems like after the fix the values you set to sigmaX/Y are doubled inside now. To match the result optically with my template in Figma I need to halve the desired value. Is there a new bug now?

[zanderso]

@kuemme01 Could you file a new issue? It's a bit difficult for the team to triage comments on closed PRs.