Nope. L’idée, c’est que tu as deux cartes graphiques. L’une a l’écran (et tout ou partie des sorties vidéos dispos) de connecté dessus et est celle intégrée au CPU, l’autre est plus performante (on l’appelle dédiée) et a éventuellement une partie des sorties vidéos connectée dessus.
En temps normal la carte intégrée fait le boulot, et la carte dédiée est éteinte (ce point n’est déjà pas évident, mais passons).
Ensuite, de temps en temps, tu peux avoir envie de lancer des applications un peu plus lourdes, et donc de laisser la carte dédiée s’en occuper. Suffit de trouver un moyen de démarrer ces applis sur cette carte (pas trivial, plusieurs manières de faire). Seulement, même une fois ceci réussi, la carte dédiée ne peut pas afficher les images générées directement à l’écran, car elle n’est pas connectée à celui-ci. Il faut donc les transférer à la carte intégrée. Ce qui est à nouveau pas simple.
Pour Bumblebee, ça fonctionne ainsi : par défaut, un seul serveur X tourne, avec la carte intégrée. Si tout va bien, la carte graphique est éteinte. Quand tu déclares une application à lancer sur la carte dédiée avec optirun, bumblebeed (le daemon) démarre un second serveur X (sauf dans un cas particulier) avec uniquement la carte dédiée. Ensuite, selon le backend utilisé, il met en place un système de transfert.
Dans le cas de VirtualGL (l’ancien backend, qu’on garde juste au cas où), un client VGL est lancé sur le serveur X « intégré », et un serveur VGL sur le serveur X « dédié ». L’application est lancée sur le serveur X « dédié », et les images sont récupérées par le serveur VGL qui les transmet au client. C’est extrêmement lourd, et il faut savoir que VirtualGL sert normalement à faire tourner des applications à distance (le truc qu’on nous vend comme étant le futur depuis des années : un supercalculateur fait tourner ton application et te renvoie les images, dans le sens inverse il récupère les entrées type clavier/souris), donc c’est pas du tout prévu pour cet usage. Du coup, les performances sont pas au niveau du tout. Et les contraintes ne sont pas les mêmes.
Du coup, est arrivés Primus. L’idée ici, c’est un peu ce que fait la nouvelle libglvnd. En gros, on fait tourner l’application sur le serveur X normal, mais quand elle fait des appels graphiques (OpenGL), on les intercepte et redirige sur la carte dédiée (le second serveur X est toujours nécessaire pour des recevoir ces appels). On récupère les résultats en sortie et les réinjecte dans l’application.
Tout ça est lourd dans les deux cas, car ça implique plein de copies en plus. Du coup, les performances sont limitées, notamment quand la résolution d’écran est grande, car la taille des images à copier l’est d’autant plus.
De l’autre côté, il y a PRIME (et le fonctionnement natif d’Optimus sous Windows, qui ne doit pas être très loin). Ici, tout se passe à un niveau beaucoup plus bas : la mémoire partagée des cartes graphiques. Pour les applications spécifiées, la carte intégrée écrit directement les appels qu’elle reçoit dans la mémoire de la carte dédiée, et cette dernière écrit directement les résultats de ces appels dans la mémoire de la carte intégrée. En gros, PRIME permet à chaque carte d’écrire dans la mémoire de l’autre. Après il y a plein de subtilités et d’autres choses à considérer, mais ça donne l’idée générale. L’important, c’est que c’est beaucoup plus propre d’un point de vue technique, et qu’en termes de performances on ne peut pas faire mieux.
PRIME dispose aussi d’un mode dit « reverse », dans lequel une carte peut utiliser les sorties vidéos de l’autre. Du coup, tu peux aussi tout faire tourner sur la carte dédiée et écrire dans la mémoire de l’autre pour l’affichage uniquement. C’est ce mode qui est utilisé par Nibel et le paquet nvidia-prime.
[^] # Re: Merci
Posté par Archange . En réponse à la dépêche Sortie du noyau Linux 4.6. Évalué à 10.
Nope. L’idée, c’est que tu as deux cartes graphiques. L’une a l’écran (et tout ou partie des sorties vidéos dispos) de connecté dessus et est celle intégrée au CPU, l’autre est plus performante (on l’appelle dédiée) et a éventuellement une partie des sorties vidéos connectée dessus.
En temps normal la carte intégrée fait le boulot, et la carte dédiée est éteinte (ce point n’est déjà pas évident, mais passons).
Ensuite, de temps en temps, tu peux avoir envie de lancer des applications un peu plus lourdes, et donc de laisser la carte dédiée s’en occuper. Suffit de trouver un moyen de démarrer ces applis sur cette carte (pas trivial, plusieurs manières de faire). Seulement, même une fois ceci réussi, la carte dédiée ne peut pas afficher les images générées directement à l’écran, car elle n’est pas connectée à celui-ci. Il faut donc les transférer à la carte intégrée. Ce qui est à nouveau pas simple.
Pour Bumblebee, ça fonctionne ainsi : par défaut, un seul serveur X tourne, avec la carte intégrée. Si tout va bien, la carte graphique est éteinte. Quand tu déclares une application à lancer sur la carte dédiée avec optirun, bumblebeed (le daemon) démarre un second serveur X (sauf dans un cas particulier) avec uniquement la carte dédiée. Ensuite, selon le backend utilisé, il met en place un système de transfert.
Dans le cas de VirtualGL (l’ancien backend, qu’on garde juste au cas où), un client VGL est lancé sur le serveur X « intégré », et un serveur VGL sur le serveur X « dédié ». L’application est lancée sur le serveur X « dédié », et les images sont récupérées par le serveur VGL qui les transmet au client. C’est extrêmement lourd, et il faut savoir que VirtualGL sert normalement à faire tourner des applications à distance (le truc qu’on nous vend comme étant le futur depuis des années : un supercalculateur fait tourner ton application et te renvoie les images, dans le sens inverse il récupère les entrées type clavier/souris), donc c’est pas du tout prévu pour cet usage. Du coup, les performances sont pas au niveau du tout. Et les contraintes ne sont pas les mêmes.
Du coup, est arrivés Primus. L’idée ici, c’est un peu ce que fait la nouvelle libglvnd. En gros, on fait tourner l’application sur le serveur X normal, mais quand elle fait des appels graphiques (OpenGL), on les intercepte et redirige sur la carte dédiée (le second serveur X est toujours nécessaire pour des recevoir ces appels). On récupère les résultats en sortie et les réinjecte dans l’application.
Tout ça est lourd dans les deux cas, car ça implique plein de copies en plus. Du coup, les performances sont limitées, notamment quand la résolution d’écran est grande, car la taille des images à copier l’est d’autant plus.
De l’autre côté, il y a PRIME (et le fonctionnement natif d’Optimus sous Windows, qui ne doit pas être très loin). Ici, tout se passe à un niveau beaucoup plus bas : la mémoire partagée des cartes graphiques. Pour les applications spécifiées, la carte intégrée écrit directement les appels qu’elle reçoit dans la mémoire de la carte dédiée, et cette dernière écrit directement les résultats de ces appels dans la mémoire de la carte intégrée. En gros, PRIME permet à chaque carte d’écrire dans la mémoire de l’autre. Après il y a plein de subtilités et d’autres choses à considérer, mais ça donne l’idée générale. L’important, c’est que c’est beaucoup plus propre d’un point de vue technique, et qu’en termes de performances on ne peut pas faire mieux.
PRIME dispose aussi d’un mode dit « reverse », dans lequel une carte peut utiliser les sorties vidéos de l’autre. Du coup, tu peux aussi tout faire tourner sur la carte dédiée et écrire dans la mémoire de l’autre pour l’affichage uniquement. C’est ce mode qui est utilisé par Nibel et le paquet nvidia-prime.