[Impeller] Enable fixed-rate compression support in Vulkan.

[chinmaygarde]

Fixes flutter/flutter#129501

[flutter-dashboard]

It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact "@test-exemption-reviewer" in the #hackers channel in Chat (don't just cc them here, they won't see it! Use Discord!).

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

[chinmaygarde]

Followup of #53079 with fixups (see the second patch) after guidance from Greg & Jesse.

I don't have a device on hand that has these extensions to check if this actually works and I don't think the swapchain stuff is expected to work on the Pixels (I'll still wire it up). So still WIP. Will finish verification next week when I get back to my desk.

[jonahwilliams]

I can confirm that my pixel 8 is selecting vk::ImageCompressionFixedRateFlagBitsEXT::e4Bpc! That said, I don't know if its doing anything :)

[chinmaygarde]

I mean, if you can't see it (and its actually applied), then good :) Testing.

[chinmaygarde]

Got a hold of a Pixel 8a. The diffs aren't noticeable (but are present).

[jonahwilliams]

interesting, those are all raster images. Is there a diff on a page with a lot of text?

[chinmaygarde]

Curiously, on a wall of text, I could find no differences. Thinking I messed up, I tried 4 different builds with logging. Again, no difference. Thinking that that AFRC conditions were not met, I tried logging like so but didn't see any logs either. So whatever its doing, there seems to be no difference in rendered output. I almost can't believe it.

if (!image_info_chain.isLinked<vk::ImageCompressionControlEXT>() &&
    desc.compression_type == CompressionType::kLossy) {
  FML_LOG(ERROR)
      << "Requested lossy compression but could not satisfy conditions.";
}

[chinmaygarde]

I'm going to back out the swapchain stuff because that is not meant to work. And what we have here we are doing on iOS too. So we have some experience with this. I'm going to get memory usage numbers first though.

[jonahwilliams]

is the AFRC only applying to offscreen rendering and not the onscreen ?

[chinmaygarde]

Yes, but the images themselves should have AFRC enabled.

[chinmaygarde]

Rapidly swiping the Wonders in the Wondrous app shows the memory usage drops from ~730 MB to ~520 MB reliable. I tried different sections for similar results. I think this matches up with what we were observing on iOS too right?

[jonahwilliams]

Yes that seems about right for ballpark. We saw about 50% for iOS, this is less than that but I don't know what else is in that heap.

[chinmaygarde]

Ok, I've cleanup up the swapchain stuff and verified similar behavior to iOS with lossy compression. Though this took longer than expected, I'm satisfied we are doing the best we can and there is parity between the platforms. We can try to wire up the onscreen surfaces compression or mess with other rates at a later time. But I'd like to close this loop on this one. PTAL.

[jonahwilliams]

I'm not sure why this is crashing on the tests...

[jonahwilliams]

nit: combine these into one?

if (compression_type != CompressionType::kLossy || !supports_texture_fixed_rate_compression_) {
  return std::nullopt;
}

[chinmaygarde]

Done.

[chinmaygarde]

The failures look real. I probably forgot to unlink an item in the structure chain. Taking a look.

[chinmaygarde]

I believe I have fixed everything and addressed all comments. PTAL.

[chinmaygarde]

Ping @jonahwilliams. I've addressed all comments verified memory savings. A review please?

[jonahwilliams]

LGTM!