Right now the blur has a two stage downsample process, first we generate mipmaps for the input texture, then we perform a downsample to a computed size (The mips are important to ensure we don't drop rows/cols of data). However, from #142154 we can see that most of the blur overhead is due to texure fill ops - and not the blur itself.

We could potentially make this much cheaper (while reducing memory usage and increasing fidelity) by using a LOD clamp instead of a downsample (see https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VkSamplerCreateInfo.html minLod, or related iOS term).

For example, suppose we have a 1000x1000 input texture. mip level 0 is 1000x1000, mip level 1 is 500x500, mip level 2 is 250x250. We compute that our desired size for a particular blur is 400x400. Today we create a new texture from the input that is 400x400, which uses the mip level 1 as an input.

Instead, we would use the 1000x1000 input texure but clamp the LOD to 1. This would effectively give us a 500x500 input, while avoiding generating the new texture.

The reason we can't try this out today is that we currently base the size of the blur passes on the downsample pass: #150713 . So without the downsmaple we would end up creating 1000x1000 blur passes. I believe if this is fixed, it should be a straight forward experiment to try.

This needs to be optional though - Metal and Vulkan support lod clamping but OpenGLES does not.

FYI @gaaclarke