UT2003 64 bits porté sous Linux

Posté par  . Modéré par Fabien Penso.
Étiquettes :
0
21
nov.
2002
Jeu
Lu sur vr-zone.com :

AMD has demonstrated the power of their Athlon 64 using the GeForce FX graphics card by running the Unreal Tournament 2003 64-bit Edition on the 64-bit Linux OS.

L'auteur de la dépêche fait remarquer que cela signifie qu'il existe un port sous Linux de la version 64bits de UT2003, ainsi que l'existence de drivers GeForce FX pour Linux ( surement propriétaires, mais c'est déjà ça ), et que tout ceci doit surement être assez performant pour justifier d'une démonstration ( un peu pas comme la X-Box qui plantait pendant les démos à la FNAC ou Carrefour ).

Cela dit, question jeux 64bits, c'est pas encore la panacée : d'ailleurs, ne pourrait-on pas dire que Linux serait le premier OS à avoir vu des vrais jeux 64bits? Et sinon, avouez que c'est quand même sympa de passer en premier par rapport à d'autres OS, non ? ;o)

Aller plus loin

  • # Re: UT2003 64 bits porté sous Linux

    Posté par  (site web personnel) . Évalué à 0.

    cool. et sinon ca marche tjrs pas grace au super brevet de mes **** , donc je repars avec mon ati.
    [ X ] -1

    • [^] # Re: UT2003 64 bits porté sous Linux

      Posté par  (site web personnel) . Évalué à 0.

      Mise à part "bien", "pas bien", "c'est mal" (c) TM

      On peut faire le point précis et honnête, au jour d'aujourd'hui et sans considération philosophique, sur ce que permet chaque driver que plateforme x86 ?

      - version de Xfree86 supporté (oui sous debian on est encore en 4.1)
      - support OpenGL, antialiasing et autres fonctions spéciales d'une carte graphique moderne;
      - DRI, extensions XV
      - bi-écran, sortie TV accélérée ou non, activée qu'au boot ou quand on veut...
      - disponibilité en packages debian, redhat, gentoo... ;-)
      - "bidouilles" à faire avec mplayer...

      oui si quelqu'un à une URL pour tout ça...

      Perso, j'ai une vieille ATI rage pro. Sur http://gatos.sourceforge.net/ati.2.php(...) , j'ai trouvé des modules Xfree 4 pour activer les extensions XV qui me permettent d'avoir avec mplayer des videos de qualité et qui bouffent pas trop de CPU. En revanche étant en Xfree 4.1 (debian oblige, pas de troll svp), je suis obligé d'utiliser une version datant de près d'un an et qui visiblement n'évoluera plus, mais sur lequel j'observe des fuites de mémoire (génant, je ne reboote ou ne me délogue presque jamais). La sortie video n'est activable que si l'on branche à une télé au boot (pas pratique, surtout que dans ce cas, on n'est limité au 800x600).

      • [^] # Re: UT2003 64 bits porté sous Linux

        Posté par  . Évalué à 3.

        debian oblige, pas de troll svp

        Tant pis, je marche dedans : J'ai une debian, une ATI et un xfree 4.2.1 installé à partir de paquets debian pris sur les ftp debian, et les drivers GATOS qui vont bien.... Donc, je cherche encore le sens du mot 'oblige'....

        • [^] # Re: UT2003 64 bits porté sous Linux

          Posté par  (site web personnel) . Évalué à 0.

          ok, ok... faut vraiment faire attention à ce qu'on dit ici... (!)

          bon, j'avais pas vu qu'il y avait un package de xfree 4.2.1 apparu en testing... merci pour l'info. Je vais voir si ça s'installe sans remettre à jour 3 millions de packages ;-)

          Mais ça ne répond pas à ma question. Dans ton cas, c'est quoi ton ATI ? une Radeon ? "les drivers GATOS qui vont bien", ça donne quoi ? la sortie télé fonctionne ? avec les extensions XV ? Tuxracer qui rox ?

          Merci de partager ton expérience.

          • [^] # Re: UT2003 64 bits porté sous Linux

            Posté par  . Évalué à 1.

            Mon expérience est très limitée, puisque dans mon cas, il s"aigissait surtout de fair marcher XawTv (j'ai une all-in-wonder Radeon, donc avec un tuner TV...).

            En tout cas, d'après glxinfo, le DRI a l'air de fonctionner, mais comme je joue pas sous linux (Aïe, je vais me faire flammer, la je le sens...), je peux pas te dire si Tuxracer Rox ou pas.

            Sinon, pour ce qui est de la télé, grace au drivers GATOS, mon tuner fonctionne (et donx XawTV aussi :o) ), mais j'ai jamais essayé de faire fonctionner la sortie télé (si je veux faire fonctionner Xawtv, c'est parce que j'ai pas de tv....).

      • [^] # Re: UT2003 64 bits porté sous Linux

        Posté par  . Évalué à 1.

        La sortie video n'est activable que si l'on branche à une télé au boot

        Avec mon ATI All-in-Wonder 128 Pro, le problème est le même...
        Lennart Poettering développe un utilitaire pour pallier à cela visiblement, mais je n'ai pas essayé : http://www.stud.uni-hamburg.de/users/lennart/projects/atitvout/(...)

        (pas pratique, surtout que dans ce cas, on n'est limité au 800x600)

        Là je suis pas sûr, la résolution d'une télé est inférieure (720x576 je crois en PAL/SECAM).
        Enfin j'ai peux-être pas bien compris ce que tu voulais dire.

        • [^] # Re: UT2003 64 bits porté sous Linux

          Posté par  (site web personnel) . Évalué à 1.

          oui, la résolution d'une télé est théoriquement 720x576...
          En pratique, les sorties TV des cartes vidéo vont jusqu'au 800x600... je ne sais pas si ça joue sur la tolérance des télés pour afficher un peu plus de lignes que la normale... ou alors si on perd un peu des bouts sur les cotés...

          • [^] # Re: UT2003 64 bits porté sous Linux

            Posté par  . Évalué à 1.

            En fait quand je branche la télé sur le PC, il y a le double affichage sur l'écran du PC et la télé. Et la résolution sur l'écran s'adapte à celle de la télé, c'est-à-dire que j'ai une résolution de 720x576 sur l'écran du PC (ça fait bizarre, ya des bandes noires en haut et en bas, et l'image est déformée, car ce n'est pas proportionnel à du 800x600).

  • # Re: UT2003 64 bits porté sous Linux

    Posté par  (site web personnel) . Évalué à 5.

    Curieux ça. Les drivers NVidia ne sont pas encore sorti pour x86-64 (le 64 bits de chez AMD) mais seulement pour IA 64 (le 64 bits de chez Intel).

    Donc soit NVidia a ça sous le coude (ça ne m'étonnerait pas non plus), soit ils utilisent des drivers 32 bits vu que le x86-64 reste compatible x86 classique et ils ont juste enfumé les journalistes pour la démo (TRES probable).

    C'est vrai que NVidia n'a pas non plus de raisons de mettre d'éventuels drivers x86-64 sur son site que que le CPU n'est pas encore sur le marché.

  • # un jeu 64 bits...

    Posté par  (site web personnel) . Évalué à 0.

    Super !

    Il utilise plus de 4 Go de RAM ? Non ?

    Bref, on se fout que cela soit 64 bits. L'important dans l'opteron/Athlon 64, c'est surtout un doublement du nombre de tous les registres.

    "La première sécurité est la liberté"

    • [^] # Re: un jeu 64 bits...

      Posté par  . Évalué à 3.

      L'important dans l'opteron/Athlon 64, c'est surtout un doublement du nombre de tous les registres.

      Ouais, on la lance quand la pétition/collecte de fonds pour libérer le source du compilo C/C++ de DEC sur Alpha ? Parce que gcc, la soupe aux registres ...

      [-1, appel au troll]

      • [^] # Re: un jeu 64 bits...

        Posté par  . Évalué à 9.

        Sauf que depuis le 3.2 tu as le droit a un nouvel allocateur de registre (qui faisait l'objet d'un brevet, mais dont gcc a ete exempte il y a peu) qui permet justement de resoudre les petits problemes qu'il y avait sur les archis ayant de nombreux registres.

        De tete c'est l'option -fnew-ra.

        • [^] # Re: un jeu 64 bits...

          Posté par  . Évalué à 1.

          Non, le nouvel allocateur de registres n'est inclu que dans gcc3.3 comme test. Il se trouve juste que SuSE dispose d'une version avec le backport nécessaire pour gcc3.2.

          IBM et l'université de RICE (enfin l'université qui hébergeait Briggs) ont concédé une exemption de royalties sur les technologies utilisées. En pratique, la variante implémentée diffère de ce qui était initialement prévu. Note aussi que l'actuel allocateur n'est pas si mauvais sur des merdes comme les x86. Perso, j'avais été surpris par le très faible gain actuel du nouvel allocateur de registres sur x86. Mais cela est amené à changer, la version dans gcc3.3 n'est qu'une expérimentation.

      • [^] # Re: un jeu 64 bits...

        Posté par  (site web personnel) . Évalué à 1.

        SGI avait passé son compilo pour MIPS en open-source il y a un an ou deux, dans le but de faire un portage IA-64. Le truc a l'air d'avoir disparu (manque d'intérêt ?) de http://oss.sgi.com/projects/(...) :-( C'est dommage car ce compilateur n'a à mon avis absolument rien a envier à celui de DEC

    • [^] # Re: un jeu 64 bits...

      Posté par  . Évalué à 1.

      2 fois plus de registres ??? waw que de progrès...

    • [^] # Re: un jeu 64 bits...

      Posté par  . Évalué à 2.

      NicO tu abuses, l'opteron/Athlon 64 est une horreur, je veux meme pas imaginer la gueule de leur decodeur. Ils ont fait comme pour le 32 bits : ajouts d'un nouveau mode avec prefixe...

      Le doublement de leur registre c'est sympa, mais c'est pas assez et ils ne sont pas generique (il ne serve qu'aux entiers). Peu d'applications vont vraiment en beneficier au final...

      • [^] # Re: un jeu 64 bits...

        Posté par  . Évalué à -1.

        Tant qu'on est dans le cambouis, Intel et AMD font toujours le concours idiot du plus long pipeline ? Qui est-ce qui pisseurine le plus loin pour l'instant ? (en bousillant la latence)

        • [^] # Re: un jeu 64 bits...

          Posté par  . Évalué à 2.

          Tu a des stats sur les pertes moyennes liées aux longs pipelines (pertes compensées par divers mécanismes) ? Ou c'est juste histoire de lancer un troll sans envergure...

          Je te signale qu'il y a peu de processeurs modernes qui se contentent encore de 4 ou 5 niveaux de pipelines. Cf. le futur processeur "desktop" qu'IBM va filer à Apple (16 étages de pipeline, voir http://arstechnica.com/cpu/02q2/ppc970/ppc970-1.html(...)).

      • [^] # Re: un jeu 64 bits...

        Posté par  . Évalué à 3.

        (il ne serve qu'aux entiers). Peu d'applications vont vraiment en beneficier au final

        Mouarf :) La majorité des applis manipulent à 99% des entiers et des pointeurs (qui sont aussi stockés dans les dits registres).

        Et pour la virgule flottante, il me semble que 3DNow et SSE2 résolvent déjà le problème, non ?

        • [^] # Re: un jeu 64 bits...

          Posté par  . Évalué à 1.

          Il me semble que c'est la partie arithmétique qui s'occupe des flottants (donc dès le 486DX, mais plus ou moins bien intégré). Les MMX/3dnow/SSE* concernent juste la parallélisation des calculs flottants, non?
          C'est une question. Je vais pas me battre là-dessus. Je suis juste un matheux, moi.

          • [^] # Re: un jeu 64 bits...

            Posté par  (site web personnel) . Évalué à 2.

            (je viens de le voir à l'instant dans la doc de gcc) Il suffit de compiler avec -msse ou -msse2 pour faire executer un maximum de calculs flottants sur ces unités.

            Par contre, c'est simple précision seulement pour SSE. SSE2 n'est encore que sur le P4 et pas sur l'XP. Faut attendre l'Oteron pour avoir le SSE2 sur un CPU AMD.

            Dans la doc, y'a même marqué qu'on peut essayer -mfpmath=sse,387 pour utiliser à la fois SSE et les unités flotantes classiques x86 pour réaliser les calculs mais c'est marqué comme expérimental.

            Faudrait bencher tout ça...

          • [^] # Re: un jeu 64 bits...

            Posté par  . Évalué à 1.

            Oui tu as raison c'est le coprocesseur qui est sensé gérer les flottants, maintenant comme le jeu d'instruction est vieux (il date du x87), il utilise une pile de registre comme sur les calculettes HP.

            Le problème des calculs sous forme de pile, c'est que ça rends le code impossible (enfin très difficile) à parallèliser, vu que toutes les instructions utilisent un même registre le sommet de la pile (d'ou les multiples dépendance entre instructions).

            Résultats les perfs du code x87 sont exécrable, et même des processeurs RISC à 200Mhz arrivent à battre des Pentium relativement récents (j'ai pas le courage de retrouver les chiffres).

            Au départ le SSE est conçu pour manipuler des vecteurs de flottants, mais comme il ne souffre pas de cette erreur de conception, la tendance future est de l'utiliser même pour les scalaires et de garder le support x87 uniquement par compatibilité avec les vielles applis.

            • [^] # Re: un jeu 64 bits...

              Posté par  . Évalué à 2.

              C'est vrai et faux ce que tu dis.

              Certes c'est une pile mais le renommage des registres permet de faire des miracles. C'est lie principalement a l'instruction fxchg qui permet de changer de sommet de pile (elle est "gratuite" sur p2).

              Un Athlon est capable de faire 2 operations flottantes par cycle sur c e jeu d'instruction.

              Pour info, SSE c'etait que des flottants simple precision, il a fallu attendre SSE2 pour les double...

              • [^] # Re: un jeu 64 bits...

                Posté par  . Évalué à 2.

                le renommage des registres permet de faire des miracles. C'est lie principalement a l'instruction fxchg qui permet de changer de sommet de pile (elle est "gratuite" sur p2).
                Oui je connais FXCHG, mais c'est surtout valable pour un compilateur, j'ai déja essayé de faire ça avec une routine de multiplication de matrices dans du code assembleur à la main, et ça donne sacré mal à la tête

          • [^] # Re: un jeu 64 bits...

            Posté par  . Évalué à 1.

            Non, l'ALU (Arithmetical and Logical Unit) ne s'occupe que des entiers (et pointeurs, considérés comme des entiers). Les flottants sont traités par la FPU (Floating-point Processing Unit), et aussi récemment par les unités SIMD flottantes (SSE et SSE2).

            La FPU a la particularité sur le x86 d'être architecturée de façon particulièrement pourrie : les registres sont organisés en pile et seul le haut de la pile est accessible directement. Les compilateurs doivent donc se faire chier à ordonnancer au mieux les opérations afin de minimiser le nombre de PUSH et POP sur cette pile, ce qui donne des résultats peu glorieux en termes de performances.

      • [^] # Re: un jeu 64 bits...

        Posté par  . Évalué à 2.

        Comment ça pas assez génériques? Tous les 16 registres peuvent être adressés indiféremment en 8, 16, 32 ou 64-bit de valeur. e.g. t'es plus limité à %al, %bl et al. pour du 8-bit.

        Par ailleurs, l'ABI spécifie que toutes les opérations en virgule flottante passent par l'unité SSE2 pour une précision single et double. Pour une précision de 80-bit, la vieille et pourrie stack FPU x87 est toujours dispo.

        Le bénéfice est réel notament car l'ABI est mieux fouttue, et le nombre accru de registres disponibles.

    • [^] # Re: un jeu 64 bits...

      Posté par  . Évalué à 5.

      Avoir un porcesseur 64 bits ça ne concerne pas que les histoires d'espace d'addressage (bien que posséder un espace d'addressage virtuel très grand peut permettre des gains de performances, même si la mémoire physique reste inférieure à 4Go, via l'utilisation de techniques de "map"page de fichiers par exemple (man mmap)).

      Combiné à des techniques comme le SIMD, les registres permettent d'accélérer à peu près tous les traitements (même si je ne sais pas si le jeu d'instruction de l'Athlon64 permet de faire cela).

      Ça peut aussi servir pour faire des calculs en virgule fixe (plus rapide que de la virgule flottante) avec une haute précision. Je ne sais pas si UT2003 utilise ce genre d'astuces, mais ça me semble possible.

      Ça permet aussi d'accélérer les copies de zone mémoire (vu qu'avec une seule instruction on passe de 32-bits transférés à 64-bits); bien sûr en temps normal la vitesse du bus est le facteur limitant, mais si les données manipulées sont dans le cache L1, la différence doit devenir visible.

      • [^] # Re: un jeu 64 bits...

        Posté par  . Évalué à 2.

        SIMD et transferts de mémoire 64 bits existaient déjà avant sur les Athlon et Intel 32 bits, grâce aux extensions MMX (SIMD entier sur registres de 64 bits) et SSE1/2 (SIMD flottant sur registres de 128 bits).

        Par contre comme le dit Nico l'Athlon 64 (ou Hammer) ajoute 8 registres entiers supplémentaires aux 8 existants (qui sont par ailleurs étendus à 64 bits), ce qui n'est pas du luxe ;-))

      • [^] # Re: un jeu 64 bits...

        Posté par  (site web personnel) . Évalué à 2.

        Le 64 bits d'amd n'a rien à avoir avec le SIMD mais rien du tout. Les registres SSE2 sont déjà de 128 bits et rien ne change de ce coté là.

        Le x86-64 ajoute qq petites instructions et un mode d'adressage pour rendre un peu plus carré le jeux d'instructions.

        Sinon, l'accélération de copie de zone mémoire ce fait déjà avec l'utilisation de QMOVE qui bouge des paquets de 64 bits (instruction MMX)

        La deuxième avancé de l'opteron et la plus important avec les registres mais qui concerne aussi le mode pure 32 bits est l'inclusion du north bridge dans le cpu.

        Ainsi la latence d'accés au mémoire diminue. L'opteron gagnerait 20 % en perf pure juste grace à cela. L'accés à la mémoire est ainsi aussi inclue dans le pipeline de la bète.

        Je plaisante sur les 64 bits, mais la barrière des 4 Go va devenir vite un handicapte pour le PC, dans le domaine de la CAO beaucoup de station on plus de 4 Go de RAM.

        Dans 2 ans, beaucoup seront à 4 Go. Aujourd'hui, les barrettes de 1 Go de RAM sont disponnible à ~600eur, ce qui n'est pas si délirant (il y a un an, la barrette de 512 Mo de mémoire EDO 113 Mhz de SUN pour ultra 5/10 coutait 2400 eur...).

        "La première sécurité est la liberté"

        • [^] # Prix SUN

          Posté par  (site web personnel) . Évalué à 1.

          Petit jeu:
          Le dernier monstre de SUN l'ultra Blade 1000 à base de processeurs UltraSparc III peut adresser 8 Go de RAM. Quel était le prix de l'extention de 4Go pour cette machine, il y a un an ? (mais je doute que le prix est beaucoup changé depuis...)

          "La première sécurité est la liberté"

          • [^] # Re: Prix SUN

            Posté par  (site web personnel) . Évalué à 1.

            Au boulot, on a une station SGI Onyx 2 (enfin station, c'est plutôt la taille armoire) qui a presque 2 ans mais qui a 4 Go de Ram. Pour l'instant ça va encore pour remonter un véhicule complet mais le moment ou on aura besoin de plus est très proche...

            Mais bon, la SGI c'est du 64 bits depuis longtemps donc ça roule :-)

          • [^] # Re: Prix SUN

            Posté par  (site web personnel) . Évalué à 2.

            Arf... t'as raison, SUN pousse quand même un peu loin le bouchon...

            quand on aime^H^H^H^H a besoin, on ne compte pas... dans la boite où je suis, pour les stations CAO SUN, on se contente depuis 2 ans d'1 Go de RAM et les stations coûtent environ 15 KE...

            Les applis CAO (Pro-engeneer pour ne pas le citer) sont tellement bien écrites qu'on est presque vraiment à l'étroit avec 1 Go de RAM... Bon, en fait, n'y connaissant pas grand chose, je ne sais pas s'il serait possible au niveau de l'appli d'économiser la mémoire...

            Enfin tout cela pour dire que jusqu'alors, pour nous, le coût d'une station CAO SUN, c'est 15 KE... et qu'on serait déja plus que content de faire une écomie de 50% en migrant vers de la plateforme PC... et donc avec un budget de 7,5 KE pour un PC, on peut largement se payer 4 Go de RAM (même en RDRAM !)... cela montre bien que 4 Go peuvent vite devenir une limite (dans la mesure où, si la RAM coûte pas cher, alors on n'optimise pas l'appli pour l'économiser)...

            Le plus chiant actuellement, c'est d'arriver à continuer à justifier l'achat de stations SUN à 15 KE pour faire tourner ProE, alors qu'il tourne aussi sur PC sous win... (le seul argument qui reste commence à être win, c'est mal, et ça fait pas très crédible devant un gestionnaire...)

            Allez messieurs de PTC, on active le portage de ProE pour linux !

          • [^] # Re: Prix SUN

            Posté par  . Évalué à 2.

            Détrompte toi, il n'est pas rare de trouver des machines à plus de 4Go de RAM chez les clients. Sur un pSeries 690 (d'IBM), c'est même 4Go minimum, et jusqu'a... 256Go de RAM. L'intéret de telles machines n'est pas de faire tourner une grosse appli, c'est surtout de faire du partitioning : tu fais tourner plusieurs "instances" de ton OS (AIX ou Linux ou les deux mélangés), comme si tu avais plusieurs machines physiques. Avec l'avantage de la souplesse : en cas de besoin ponctuel, tu peux "éteindre" une partition et en agrandir une nouvelle (plus de CPU, plus de RAM...).

            Par contre c'est sûr que c'est pas donné : $33,177.60 le module de 4Go, d'après le site d'IBM.

          • [^] # Re: Prix SUN

            Posté par  . Évalué à 1.

            J'ai une SunBlade 2000 au taffe, mais y a seulement 2 gigas de ram.

          • [^] # Re: Prix SUN

            Posté par  (site web personnel) . Évalué à 2.

            Vous n'êtes pas drole vous ne jouer pas à mon petit jeu.

            Le prix de l'extention 4Go était de 50_000$...

            "La première sécurité est la liberté"

Suivre le flux des commentaires

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