Unlike ARM cores, GPU code is expensive to migrate between them. Two GPUs have different ISA, each GPU driver compiles platform-independent bytecode like DXBC or SPIR-V into proprietary instruction set. VRAM can contain many GB of data, when migrating, everything needs to be copied. The asymmetric ARM cores at least have same RAM, and very similar instruction set.

These issues make live migration impractical. AFAIK, modern OSes don’t do that, the GPU is fixed at the moment an app creates D3D or GL context.

Picking the best GPU for the job can be tricky. By the time the app creates a 3D rendering context, the OS has no idea what it’s going to render.

Write a code that renders something simple, then downloads the frame buffer from GPU back to system RAM — Intel will probably be faster, for nVidia that copy back is expensive because PCIx, for Intel very cheap, no PCIx IO, just memcpy.

Even exposing an OS API where apps can request high or lower power GPUs is still unreliable. An app which does very simple rendering can sometimes demand way more resources, connect a 5k monitor and simple rendering can become too expensive for intel due to count of pixels. A game which reports it needs a lot of GPU power will be very light workload in 10 years from release, perfectly suitable for low-power integrated GPUs.