3 ms·

Does anyone know the technical reason that the OS can't handle that itself?

MBCook 7y ago
It tries based on the libraries you’re using. Sounds like they’ve improved what they’re using so the built in heuristics don’t force the dedicated GPU on.
Const-me 7y ago
Not using OSX, but I have some ideas. An app tells an OS it gonna use OpenGL to 3D render stuff. Generally, the OS doesn’t know whether it’s a competitive 3D shooter where each FPS really matters, or a web browser which only uses OpenGL to render a few textured quads. If the OS will default to slower integrated GPU, users will be unhappy, they want 3D performance. So the OSes typically power up the faster GPU in such cases. On dual-GPU Windows laptop, nVidia partially solves this in their drivers, they have very long list of process names saying which ones are games or other 3D intense apps. It usually works but very far from being 100% reliable. It requires GPU drivers to be updated regularly. For cases when it fails even with latest drivers, they have multiple methods for user to select the GPU. They implemented context menu on .exe files “Run with graphic processor” with 2 further options, for nVidia and Intel GPUs. They implemented GUI for users to customize that apps list. They also implemented a proprietary API for programmers to customize that list in code, I’m using this method in the installer of a CAD/CAM app I’ve developed. These things cause quite a lot of complexity, both software bloat, and UI clutter. Traditionally, Apple wants the GUI to be clean. AFAIK they don’t push driver updates, and they avoid UI clutter even if it means some power users won’t get some advanced settings they might like.
- garaetjjte 7y ago
  >they have very long list of process names saying which ones are games or other 3D intense apps. Is it possible to submit application names for this? This issue frequently comes up with our free simulator/game.
  - Const-me 7y ago
    I have no idea whether nVidia willing to change that list for small software publishers. Technically, I know 2 workarounds. 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 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”.
- la_barba 7y ago
  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).

It tries based on the libraries you’re using. Sounds like they’ve improved what they’re using so the built in heuristics don’t force the dedicated GPU on.

Const-me 7y ago

Not using OSX, but I have some ideas. An app tells an OS it gonna use OpenGL to 3D render stuff. Generally, the OS doesn’t know whether it’s a competitive 3D shooter where each FPS really matters, or a web browser which only uses OpenGL to render a few textured quads. If the OS will default to slower integrated GPU, users will be unhappy, they want 3D performance. So the OSes typically power up the faster GPU in such cases. On dual-GPU Windows laptop, nVidia partially solves this in their drivers, they have very long list of process names saying which ones are games or other 3D intense apps. It usually works but very far from being 100% reliable. It requires GPU drivers to be updated regularly. For cases when it fails even with latest drivers, they have multiple methods for user to select the GPU. They implemented context menu on .exe files “Run with graphic processor” with 2 further options, for nVidia and Intel GPUs. They implemented GUI for users to customize that apps list. They also implemented a proprietary API for programmers to customize that list in code, I’m using this method in the installer of a CAD/CAM app I’ve developed. These things cause quite a lot of complexity, both software bloat, and UI clutter. Traditionally, Apple wants the GUI to be clean. AFAIK they don’t push driver updates, and they avoid UI clutter even if it means some power users won’t get some advanced settings they might like.

garaetjjte 7y ago
>they have very long list of process names saying which ones are games or other 3D intense apps. Is it possible to submit application names for this? This issue frequently comes up with our free simulator/game.
- Const-me 7y ago
  I have no idea whether nVidia willing to change that list for small software publishers. Technically, I know 2 workarounds. 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 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”.
la_barba 7y ago
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).