Journal Virtualisation et jeux vidéos

Posté par .
Tags : aucun
0
29
juin
2007
Tout d'abord, je tiens à présenter mes excuses. Je suis faible, j'utilise de temps en temps des logiciels propriétaires. Si vous le souhaitez, vous pouvez donc me lancer des cailloux avant de répondre.

Après ce préambule, je vais exposer mon souci. Je suis sous Linux depuis plusieurs années pour à peu près toutes mes utilisations informatiques à domicile. Mais il reste quand même un secteur qui résiste opiniâtrement, le jeu. En effet, je joue à des jeux sous Windows.

Jusqu'à présent, j'avais un disque avec ma vieille installation Windows 2000 et je rebootais dessus quand l'envie de jouer me prenait. Problème, ça prend 3 minutes pour le lancer, 3 minutes pour retourner sous Linux. J'avais bien regardé l'émulation avec Wine, mais bon c'était d'une complexité décourageante et les pertes en performance semblaient énormes.

Je me demandais donc si des solutions du style Xen n'étaient pas capables de me permettre d'éviter de passer par la case reboot. Dans mon rêve, je pourrais lancer la machine virtuelle sans grosses pertes de perfs, l'afficher en plein écran et la mettre en hibernation dans un gros fichier. Ce rêve serait-il réalisable ? Avec quel overhead en termes de perfs ?

Je suis preneur de tout retour d'expérience ou de tutoriels. Merci d'avance.
  • # Alors

    Posté par (page perso) . Évalué à 8.

    Deux choses:
    1.Wine complexe ? Pertes de performances énormes ?
    T'es sur qu'on parle bien du même Wine ?
    Je veux bien que wine soit dans certains cas bordelique à utiliser à cause de bogues, mais bon à part ca la plupart du temps wine setup.exe(ou le faire avec votre gestionnaire de fichier) et c'est tout, il fout une icone sur le bureau pour lancer l'appli et dans le menu "général".
    2.Pour faire ce que tu veux il manque un tres gros point: la gestion de la carte vidéo.
    Je sais que nvidia a des essais en internes qui marchent bien il me semble (ils ont réussi à migrer une VM qui faisait tourner quake 3 d'une machine à l'autre il me semble), mais à part ca rien n'existe pour ce que tu veux faire à ma connaissance
    Et sinon en pertes y aura sans aucun doute plus de pertes avec xen qu'avec wine (sauf si des parties de wine sont plus mal codées que les équivalents windows).
    • [^] # Re: Alors

      Posté par . Évalué à 10.

      Tout en sachant que wine peut dans certains benchmarks être plus rapide que Windows. C'est faisable parce que wine n'est pas un émulateur mais une implémentation de l'API windows...
      • [^] # Re: Alors

        Posté par . Évalué à 1.

        Ah ? WINE Is Not an Emulator ?
  • # Pas de 3D

    Posté par (page perso) . Évalué à 4.

    Pour mon expérience, aucune virtualisation à l'heure actuelle ne supporte l'accélération matérielle de l'affichage 3D. Donc si ça passe avec Wine, c'est très bien (j'ai moi-même quelques jeux qui fonctionnent sans effort sous WINE), sinon, tu n'as pas d'autre choix que le redémarrage sous W2K.

    Sinon, il y a aussi plein de jeux qui fonctionnent avec Dosbox ;-)

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: Pas de 3D

      Posté par . Évalué à 2.

      D'après la doc VMware, le Player et la Workstation en sont capables, mais il faut pour cela modifier le fichier de description de la machine virtuelle.
      Je ne me souviens plus des détails, il faut lire la doc, mais a-priori c'est possible.

      Malgré cela, je n'y suis pas arrivé, j'obtenais un message du style "fail to construct 3D backend".
      Je l'avais testé avec une Radeon 7500 Mobility et le driver libre radeon, pour lesquels je n'avais aucun autre soucis. Je ne pense pas que ça venait d'eux, et je ne sais toujours pas d'où vient le problème.

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: Pas de 3D

        Posté par (page perso) . Évalué à 5.

        la 3d marche mais c'est pas très performant. environ 50% de perte alors qu'avec Wine, quand ca marche, c'est le bonheur.
    • [^] # Re: Pas de 3D

      Posté par (page perso) . Évalué à -1.

      Faux, VMWare Fusion que je teste en BETA sur mon Macbook Pro sous MacOS X permet l'accélération graphique jusqu'à DirectX 8.1. J'ai testé, ça marche bien.

      Par contre je sais pas du tout si VMWare va aussi le sortir sous Linux, il semble qu'ils se concentrent d'avantage sur l'accélération graphique sous Mac OS X.
      Le marché "grand public" qui demande ce genre de fonctions est plus présent sur cette plate-forme.
  • # Merci

    Posté par . Évalué à 3.

    Merci de me faire déchanter. Bon bah je vais revenir sur terre alors. Et me repencher sur Wine qui était quand même problématique, par exemple avec des protections style StarForce...
    • [^] # Re: Merci

      Posté par (page perso) . Évalué à 2.

      Ah ca ca a pas changé. (Encore que y a une release qui dit qu'elle a un support préliminaire pour, est-ce que ca veut dire que c'est utilisable dans certaisn cas? En tout cas trackmania marche pas)
      • [^] # Re: Merci

        Posté par . Évalué à 5.

        Pour ce que j'en ai vu, déjà sous Windows, Starforce c'est de la merde.
        • [^] # Re: Merci

          Posté par (page perso) . Évalué à 4.

          Heu, faut dire la vérité...

          Je ne fais tourner aucun jeux wine sans crack nocd (sauf vieux jeux) :
          1 - Parce que sortir un foutu cdrom pour jouer a un jeu c'est chiant, là où un mount de l'image iso est bien plus pratique
          2 - Parce que ça use mon lecteur cdrom inutile
          3 - Parce que je veux pas de programme autre qui me bouffent mon cpu quand je joue a un jeu
          4 - Parce que certains originaux que j'ai refusent simplement de se lancer sans crack
          5 - Parce que je vais pas rajouter du proprio pour jouer et le payer en plus (cedegea)

          Bon pour les nocd, gamecopyworld.com et megagames.com sont là.

          Bon sinon y a pas mal de jeux qui marche plus ou moins bien :
          - warcraft 3
          - baldur gate 2 (je dois downgrader wine en 0.9.27 a cause de régression)
          - oblivion :
          sa configuration doit se faire via modification de clef registre wine dans HKEY_CURRENT_USER/Software/Wine/Direct3D
          DirectDrawRenderer chaîne opengl
          OffscreenRenderingMode chaîne backbuffer
          PixelShaderMode chaîne enabled
          UseGLSL chaîne yes
          VideoMemorySize chaîne 256
          Bon même avec ces réglages ça lag pas mal lors des combats :'(
          J'ai réglé le soucis en étant magie full avec le sort d'invisibilité majeure dans la classe illusion.
          (regarder au plafond permet de gagner temporairement en perf le temps de caster l'invisibilité)
          • [^] # Re: Merci

            Posté par . Évalué à 3.

            Baldur's Gate II semble bien tourner avec wine 0.9.36. Enfin, j'y ai pas encore joué beaucoup vu que je prépare mon perso sur BG1 avant :) Mais j'ai pu lancer une partie, importer un perso, etc sans problèmes (mis à part un DSOUND: MixInBuffer toutes les 5 secondes avec ALSA). Par contre, la 0.9.39 apporte son lot de régressions gênantes dans BG1 (assertion failed lors de l'import d'un perso, etc).

            Ah si, en y réfléchissant, y'a bien un bug qui m'énerve: le curseur X qui ne disparaît pas ingame. On se le traîne depuis les premières 0.9.x au moins. J'aimerais tester avec la 0.9.40 sortie cette nuit mais WineHQ est en maintenance pour le moment.

            Par contre, tu fais tourner Oblivion sous Wine ? Intéressant... Je pensais pas qu'on pouvait. J'avais testé il y a peu mais les graphismes merdaient et ça plantait dès qu'il y avait un event (les premiers assassins qui apparaissent). Tu le fais tourner avec quel Wine ?
            • [^] # Re: Merci

              Posté par . Évalué à 2.

              Le DSOUND: MixinBuffer est une erreur récurrente qui a été reproduite sur un grand nombre de versions différentes, de cartes et de drivers. Personne ne semble vraiment savoir pourquoi, ni comment, mais elle va être classé en bug majeur sur : http://bugs.winehq.org/show_bug.cgi?id=1631

              On peut espérer une résolution prochaine.
              • [^] # Re: Merci

                Posté par (page perso) . Évalué à 2.

                Ah si, en y réfléchissant, y'a bien un bug qui m'énerve: le curseur X qui ne disparaît pas ingame. On se le traîne depuis les premières 0.9.x au moins. J'aimerais tester avec la 0.9.40 sortie cette nuit mais WineHQ est en maintenance pour le moment.

                J'ai appris a vivre avec...

                Pour oblivion mon wine est 0.9.38 ou 0.9.39 (je sais pas si j'ai mis a jour wine via les backports mandriva avant ou après).
                En même temps heureusement que c'est pas parfaitement fluide, sinon j'aurais abandonné ma vie...

                Sinon les histoires de résolution de bug de son c'est une bonne chose...
                (en tout cas je suis plus tombé sur le plantage de warcraft 3 avec la sortie son en alsa comme ça le faisait avant 0.9.10-17 enfin ces eaux là)
    • [^] # Re: Merci

      Posté par (page perso) . Évalué à 1.

      Sinon, tu as Cedega, mais c'est propriétaire.

      Cedega est un plugin de Wine destiné à faire tourner les jeux windows.
      http://fr.wikipedia.org/wiki/Cedega

      La liste des jeux compatibles :
      http://games.cedega.com/gamesdb/

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: Merci

        Posté par . Évalué à 1.

        Cedega n'est pas un plugin, c'est un fork :) Ce sont bien deux programmes séparés. On peut utiliser Cedega pour lancer un jeu installé dans le "drive_c" de Wine mais je suis pas sûr que le résultat soit sans bug.
      • [^] # Re: Merci

        Posté par (page perso) . Évalué à 3.

        Attention, c'est absolument pas propriétaire, c'est en GPL mais les binaires sont payants. L'accès anonyme CVS pour compiler depuis les sources est même gratuit (enfin la dernière fois que je l'ai utilisé, quand Wine avait vraiment du mal avec les jeux), ce qui n'est pas obligatoire...
        Par contre ils ont une interface d'install de jeux (qui doit faire les hacks nécessaires à certains jeux à la place de l'utilisateur) proprio (Point2Play).
        • [^] # Re: Merci

          Posté par . Évalué à 3.

          Le support des protections anti-copies est absent du CVS.
          • [^] # Re: Merci

            Posté par . Évalué à 2.

            Je ne pense pas que les routines Direct3D et les fontes sous copyright MS soient sur le cvs, mais je n'ai pas vérifié...
  • # C'est pas bientot possible ?

    Posté par (page perso) . Évalué à 1.

    Ce message est a prendre avec des pincettes :

    Avec Xen et des processeurs avec plusieurs coeurs, ce ne sera pas bientot possible ???
    Il me semble qu'on pourra (ou qu'on peut déjà) lancer un systeme d'exploitation à partir d'un autre ... avec peu de perte.

    J'ai pas beaucoup lu de doc dessus, c'est a confirmer / infirmer.
    • [^] # Re: C'est pas bientot possible ?

      Posté par . Évalué à 3.

      Le problème c'est pas le processeur, c'est la carte graphique et les pilotes. Partager la carte graphique entre 2 OS c'est déjà plus amusant à faire, et si tu fais une carte graphique virtuelle, tu dois coder des pilotes.
      • [^] # Re: C'est pas bientot possible ?

        Posté par (page perso) . Évalué à 1.

        J'avais cru comprendre que justement, le deuxieme os ne tournait pas sur une vm, mais sur la machine physique, ce qui ne pose plus de (gros) problème pour les cartes 3d, par exemple.

        Mais vu ton commentaire, je me suis trompé...
        • [^] # Re: C'est pas bientot possible ?

          Posté par (page perso) . Évalué à 3.

          C'est ce que je pensais au début, mais d'après ce que j'ai lu, quand j'ai fait des recherches il y a quelque temps, je me suis aperçu qu'on fessait juste du qemu, mais presque sans qemu : c'est le cpu réel qui tourne mais avec des périphériques virtuels...
          A moins que j'ai mal compris....
          • [^] # Re: C'est pas bientot possible ?

            Posté par . Évalué à 2.

            Non je crois pas, dans le cas de Xen par exemple tu partages même le matos (bus pci etc...) mais partager la carte vidéo semble beaucoup plus problématique.
  • # Ca arrive

    Posté par (page perso) . Évalué à 5.

    Chuis pas un pro de la chose, mais y'a un projet assez intéressant qui s'appelle vmgl.
    En gros l'idée (si j'ai bien compris) c'est d'intercepter, dans la vm, les appels vers des commandes openGL et de les remonter vers l'OS hôte qui les gerera ensuite comme si c'était une application de l'OS hôte qui les avait faites.
    Une présentation qui parle de ça est disponible là :
    http://www.xensource.com/files/xensummit_4/vmgl_Cavilla.pdf
    La page du projet en question
    http://www.cs.toronto.edu/~andreslc/xen-gl/

    Vu les benchmarks à la fin de la présentation (page 21), ça a l'air assez performant.
    Bon, pour l'instant, ça n'a l'air de supporter que Linux comme OS hôte et Linux comme OS invité, mais l'idée est applicable à n'importe quel OS invité, faut juste écrire des drivers :-)

    Il y a aussi cette discussion sur la mailing list Xen qui donne quelque éclairages à ce sujet :
    http://lists.xensource.com/archives/html/xen-users/2006-08/m(...)
  • # C'est facile pourtant

    Posté par . Évalué à 3.

    chroot /windows /bin/bash
    ./windows/Program files/Jeu/jeu.exe

    Oups je me suis laissé emporté...
    • [^] # Re: C'est facile pourtant

      Posté par . Évalué à 1.

      Ou plutôt, je me suis laissé emporter.
    • [^] # Re: C'est facile pourtant

      Posté par . Évalué à 2.

      Je crois qu'il y a, ou il y avait, une option du noyau qui permet de faire ça, à savoir permettre l'exécution de binaires autres que elf, à l'aide d'un programme externe (wine, VM Java, etc. ).

      (Cela dit, je ne vois pas trop ce que ça vient faire dans le noyau... ça devrait plutôt être du sucre syntaxique pour le shell ! Ou alors, ça doit faire des trucs plus sioux que je ne le pense... )

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.