Might be worth mentioning that this never worked at all on Android, due to the fact that skia generated different shaders based on GPU model

Yeah, I remembered but got lazy and didn't want to look up the bugs to cross reference here. But flutter/flutter#102655 seems to be it. Still open! Will add.

Done. Also added a ref to things we tried to reduce shader variants.

As a minor nit, we are still compiling shaders at runtime, and may generate new PSOs on demand. But we don't have to go through a source -> source translation or reflection step, and on iOS we can use metal achive files which load much faster.

The GPU is still jitting the shader though

Sounds like a good thing to mention. Is there a general notion we can give of the relative cost between PSO generation and the source->source translation? Like is it 10x cheaper?

100x maybe?

on iOS in particular, it seems to be closer to "free"

(The PSO generation)

And important to point out this isn't an alternative, in the old route we go source -> source -> metal compiler (source) -> PSO. now we just go metal compiler (archive) -> PSO.

I went back and forth quite a bit on this and adding backend specific nuance made things a whole lot more complicated. On Metal, we can use either AIR files or the new Metal Binary Archives which really move everything to be at build time. But have to resort to flinging strings around with OpenGL ES. So what happens before GPU microcode is generated is quite quite messy to explain. This seemed like a fine enough bit of context to tell the story. Should I add another FAQ entry perhaps?

@zanderso From go/impeller-prototype, I found this screenshot of a trace I took where the cost of the shader library construction is separate from the PSO creation (the small pink trace at the end). I think in this version of Skia, this included source-to-source translation as well as the shader library construction we do here in Impeller. Even that last bit at the end, Impeller does before first frame (well variants are another matter I suppose).

Oh, nevermind. In this case, there is an SKSL cache hit. Its even slower when there is no cached SKSL. This used to happen when the phone was rebooted and Metals caches weren't warmed up from previous runs. I was making that case that perfect SKSL caches were necessary but not sufficient for jank free operation because metalc literally had to do LLVM things and that was more than sufficient to blow our frame budgets.

Such a mess and I've blocked away so much of this context in my head.

We, of course, never found this janky behavior on our benchmarks because we didn't reboot phones between runs to clear the internal metal caches.

spell out AOT. Suggest "Ahead of Time (AOT) mode ..."

Shouldn't we also mention what is being AOT'ed? Like "Impeller is rendering with ahead-of-time (AOT) compilation"?

Seths suggestion done. Michael, that should become clearer in the next entry. Should I add another FAQ entry perhaps?

Suggest s/Describe Impeller in a Tweet/Describe Impeller in less than 10 words/

But thats literally what Seth asked 😄 !

hah yes I did, but I like @mit-mit 's suggestion here :)

Shouldn't we also mention what is being AOT'ed? Like "Impeller is rendering with ahead-of-time (AOT) compilation"?

Maybe s/due to shader compilation/due to needing rendering shaders to be compiled on-demand before they could be executed/ or similar?

good clarification

The longer form answer here reads a bit odd in bullet form. Usually bullets are separate points, but here it's just a set of paragraphs. Could it be reformatted to a single large bullet with text and line breaks?

Yeah, @sethladd mentioned the same thing thing in #54456 (comment). I'm going to reformat the entire doc in a later patch.