4 ms·

I guess I was thinking of this from a heterogeneous architecture standpoint (e.g. big.LITTLE) . You have differently-capable compute resources, and you need to

I guess I was thinking of this from a heterogeneous architecture standpoint (e.g. big.LITTLE) . You have differently-capable compute resources, and you need to pick the one thats best suited for the work-load. Rather than the app talking directly to the hardware, I suppose the OS should let the app pick its work-load type, similar to letting it choose a process scheduling priority.

Const-me 7y ago
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.
- la_barba 7y ago
  When switching from onboard -> dedicated, the resources (textures, shaders, etc) to migrate will be quite small. There is no question of migrating resources from dedicated -> onboard as that is never going to happen, unless .. again the resources are tiny. The context switch performance hit will depend on the other components on the board, but for a high end CPU/RAM/SSD combo, it wont be much. It will be equal to re-loading the all the browser tabs (for e.g. after a browser crashes).

Const-me 7y ago

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.

la_barba 7y ago
When switching from onboard -> dedicated, the resources (textures, shaders, etc) to migrate will be quite small. There is no question of migrating resources from dedicated -> onboard as that is never going to happen, unless .. again the resources are tiny. The context switch performance hit will depend on the other components on the board, but for a high end CPU/RAM/SSD combo, it wont be much. It will be equal to re-loading the all the browser tabs (for e.g. after a browser crashes).