Maintenant que j'y repense, ce problème pourrait très bien être le même sur les Android, qui fait qu'ils utilisent le framebuffer (avec une API étendue), plutôt qu'X. L'architecture sur les téléphones au moment de la création d'android, c'est grosso modo, un moteur 2D extrèmement simple (il ne gère que la fonction blit ! (ie copie de mémoire d'un buffer quelconque vers l'affichage, avec quand même des options d'opacité, rotation (multiple de 90° quand même), redimensionnement, coupe), et différents moteurs qui vont se greffer dessus. C'est à dire que aussi bien le GPU 3D, que le décodage vidéo, vont écrire dans leur propre mémoire, et derrière demander au framebuffer de recopier cette zone.
Au final, c'est bien la même problématique, sauf que les puces graphiques intel, sont plus puissantes qu'une pauvre gestion de blit, et donc non des "machines en ARM" n'aideraient pas forcément :D
Comme dit plus haut, il y a un répertoire dans le noyau par série de chipsets (omap/omap3,msm, samsung fait particulièrement fort aussi dans mes souvenirs), et même pire ! À part certaines personnes qui font des efforts particuliers pour (j'en fait partie avec le projet htc-linux, mais bon ça risque pas d'aller en amont de toutes façons), il n'est pas possible de faire un noyau binaire compatible avec plusieurs cartes à la foi ! Typiquement, les beagle boards ont un noyau RevA/RevB, et un noyau RevC, certains téléphones ont des noyaux différents, juste parce qu'ils ont une version du logiciel radio différent !
Bon donc voilà, en ARM c'est pas forcément mieux qu'en x86. (Enfin qualcomm a décidé de faire un driver Xorg qui gère 3D et accélération vidéo, faudrait voir comment.)
Pour en revenir au problème, je pense que des solutions (de contournement ? peut être, mais elles me paraissent assez naturelles) existent. Y avait la méthode barbare des DXR3, mais à l'heure du compositage c'est peut être plus trop d'actualité :D
Plus sérieusement, quand on utilise du Xv, c'est un peu ce que l'on fait, si ce n'est que le décodage est fait en soft et non en hard, mais le problème reste le même: le décodage est fait par une entitée annexe au driver vidéo, écrit dans une zone mémoire à lui, et la carte graphique va le recopier derrière (comme sur ARM, avec des options simples derriere comme du redimensionnement ou du changement de format :D).
Après on va me dire que c'est sale, que le Xv c'est fait pour la vidéo, mais bon, ce Xv c'est bien l'équivalent d'un blit, à part le nom, et le protocole. Donc à côté de ça, il "suffit" que la lib OpenGL écrive dans son propre buffer, au lieu de vouloir l'écrire directement sur l'affichage, et de faire un lien entre les deux. Je me demande même si ce n'est pas possible même en étant en dehors du driver nVidia, étant donné que CUDA marche.
"Au pire", il doit être possible de lancer un serveur X sur la carte nVidia (sauf si le driver refuse parce qu'il ne trouve aucune sortie... ce qui est probable en fait.), d'avoir un genre de VNC qui affiche le contenu du serveur X de la nVidia, sur le serveur X de l'intel. Après, pour avoir des fonctionnalités équivalentes à Windows, il manquera juste deux étapes: pouvoir exporter des fenêtres, et non tout un écran, et automatiser le processus de choisir sur quel serveur X afficher le bousin.
PS: Bon après, vu que je me renseigne avant d'acheter un ordinateur, je n'ai pas de portable avec ce genre de blagues, donc comptez pas sur moi pour essayer de faire ça (et non je ne me mouille pas.)
# ARM.... Android .... Copains.
Posté par Ph Husson (site web personnel) . En réponse au journal nVidia Optimus, bonne idée fondamentalement incompatible avec Linux.... Évalué à 10.
Au final, c'est bien la même problématique, sauf que les puces graphiques intel, sont plus puissantes qu'une pauvre gestion de blit, et donc non des "machines en ARM" n'aideraient pas forcément :D
Comme dit plus haut, il y a un répertoire dans le noyau par série de chipsets (omap/omap3,msm, samsung fait particulièrement fort aussi dans mes souvenirs), et même pire ! À part certaines personnes qui font des efforts particuliers pour (j'en fait partie avec le projet htc-linux, mais bon ça risque pas d'aller en amont de toutes façons), il n'est pas possible de faire un noyau binaire compatible avec plusieurs cartes à la foi ! Typiquement, les beagle boards ont un noyau RevA/RevB, et un noyau RevC, certains téléphones ont des noyaux différents, juste parce qu'ils ont une version du logiciel radio différent !
Bon donc voilà, en ARM c'est pas forcément mieux qu'en x86. (Enfin qualcomm a décidé de faire un driver Xorg qui gère 3D et accélération vidéo, faudrait voir comment.)
Pour en revenir au problème, je pense que des solutions (de contournement ? peut être, mais elles me paraissent assez naturelles) existent. Y avait la méthode barbare des DXR3, mais à l'heure du compositage c'est peut être plus trop d'actualité :D
Plus sérieusement, quand on utilise du Xv, c'est un peu ce que l'on fait, si ce n'est que le décodage est fait en soft et non en hard, mais le problème reste le même: le décodage est fait par une entitée annexe au driver vidéo, écrit dans une zone mémoire à lui, et la carte graphique va le recopier derrière (comme sur ARM, avec des options simples derriere comme du redimensionnement ou du changement de format :D).
Après on va me dire que c'est sale, que le Xv c'est fait pour la vidéo, mais bon, ce Xv c'est bien l'équivalent d'un blit, à part le nom, et le protocole. Donc à côté de ça, il "suffit" que la lib OpenGL écrive dans son propre buffer, au lieu de vouloir l'écrire directement sur l'affichage, et de faire un lien entre les deux. Je me demande même si ce n'est pas possible même en étant en dehors du driver nVidia, étant donné que CUDA marche.
"Au pire", il doit être possible de lancer un serveur X sur la carte nVidia (sauf si le driver refuse parce qu'il ne trouve aucune sortie... ce qui est probable en fait.), d'avoir un genre de VNC qui affiche le contenu du serveur X de la nVidia, sur le serveur X de l'intel. Après, pour avoir des fonctionnalités équivalentes à Windows, il manquera juste deux étapes: pouvoir exporter des fenêtres, et non tout un écran, et automatiser le processus de choisir sur quel serveur X afficher le bousin.
PS: Bon après, vu que je me renseigne avant d'acheter un ordinateur, je n'ai pas de portable avec ce genre de blagues, donc comptez pas sur moi pour essayer de faire ça (et non je ne me mouille pas.)