[Impeller] new blur: implemented ping ponging

[gaaclarke]

This will reuse the downsample texture for the blur pass.

issue: flutter/flutter#140189

Testing: This has golden image coverage for the refactoring. There is a slight performance difference which will show up in benchmarks. Ideally there would also be a memory test for the blur. I don't think there is one yet.

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide and the C++, Objective-C, Java style guides.
• I listed at least one issue that this PR fixes in the description above.
• I added new tests to check the change I am making or feature I am adding, or the PR is test-exempt. See testing the engine for instructions on writing and running engine tests.
• I updated/added relevant documentation (doc comments with ///).
• I signed the CLA.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[gaaclarke]

Here is the performance measurement here. GPU time doesn't seem much effected. We'll have to measure the memory usage:

    "average_vsync_transitions_missed": 5.671875,
    "90th_percentile_vsync_transitions_missed": 6.0,
    "99th_percentile_vsync_transitions_missed": 6.0,
    "average_vsync_frame_lag": 0.0,
    "90th_percentile_vsync_frame_lag": 0.0,
    "99th_percentile_vsync_frame_lag": 0.0,
    "average_layer_cache_count": 0.0,
    "90th_percentile_layer_cache_count": 0.0,
    "99th_percentile_layer_cache_count": 0.0,
    "average_frame_request_pending_latency": 16635.254575707153,
    "90th_percentile_frame_request_pending_latency": 16724.0,
    "99th_percentile_frame_request_pending_latency": 16767.0,
    "worst_layer_cache_count": 0.0,
    "average_layer_cache_memory": 0.0,
    "90th_percentile_layer_cache_memory": 0.0,
    "99th_percentile_layer_cache_memory": 0.0,
    "worst_layer_cache_memory": 0.0,
    "average_picture_cache_count": 0.0,
    "90th_percentile_picture_cache_count": 0.0,
    "99th_percentile_picture_cache_count": 0.0,
    "worst_picture_cache_count": 0.0,
    "average_picture_cache_memory": 0.0,
    "90th_percentile_picture_cache_memory": 0.0,
    "99th_percentile_picture_cache_memory": 0.0,
    "worst_picture_cache_memory": 0.0,
    "total_ui_gc_time": 3.064,
    "30hz_frame_percentage": 0.0,
    "60hz_frame_percentage": 100.0,
    "80hz_frame_percentage": 0.0,
    "90hz_frame_percentage": 0.0,
    "120hz_frame_percentage": 0.0,
    "illegal_refresh_rate_frame_count": 0,
    "average_gpu_frame_time": 82.51953125,
    "90th_percentile_gpu_frame_time": 125.0,
    "99th_percentile_gpu_frame_time": 125.0,
    "worst_gpu_frame_time": 125.0,
    "average_cpu_usage": 121.87708345833335,
    "90th_percentile_cpu_usage": 127.2,
    "99th_percentile_cpu_usage": 130.499998,
    "average_gpu_usage": 100.0,
    "90th_percentile_gpu_usage": 100.0,
    "99th_percentile_gpu_usage": 100.0,
    "average_memory_usage": 101.67024739583333,
    "90th_percentile_memory_usage": 117.0625,
    "99th_percentile_memory_usage": 121.25

[gaaclarke]

Here the memory usage is much lower than before (644MB vs 914MB):

[bdero]

LGTM. I haven't run this patch locally but how this implementation makes sense to me.

[bdero]

I see, this is to make just reusing the same RenderTarget easy in the blur. I think this is fine.

[gaaclarke]

Yea, I had to do RenderTarget instead of Texture because of MSAA.

[bdero]

Ok, so I believe all of this works out such that all three passes should always wind up attaching color textures of size subpass_size.

Since this optimization is contingent on the sizes being the same in order to render correctly, could you add a DCHECK that verifies the color attachment of the three passes is subpass_size?

[gaaclarke]

Done.

[auto-submit]

auto label is removed for flutter/engine/49252, due to - The status or check suite Linux linux_unopt has failed. Please fix the issues identified (or deflake) before re-applying this label.