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.

1. If your app’s main .exe is written in C, C++ or something similar, you can change the default by DLL exporting a DWORD variable from your exe. For more info, search the web for `NvOptimusEnablement`.

2. If you can’t export variables from your .exe, you can do what I did: make an installer, write a custom installer action in C (technically they’re just DLLs), in that custom action consume NVApi and create a new profile for the main executable of your software. For more info, read this: https://stackoverflow.com/a/40915100

Update: you can also detect dual-GPU system and use NVApi from your app, but it has 2 disadvantages. Slightly increases startup time. Also the new settings will only be applied next time user launches the app, you’ll need to communicate it that with your user, with a message like “please restart the game for better 3D performance”.