Journal [Radeon] Enemy Territory: QUAKE Wars jouable out-of-the-box sur Fedora 17

Posté par  . Licence CC By‑SA.
20
5
juil.
2012

Mes 2 derniers journaux sur linuxfr parlaient du jeu d'idSoftware "Enemy Territory: QUAKE Wars" (etqw). Dans le premier journal ( https://linuxfr.org/users/whitecat/journaux/quake-wars-et-mesa ) j'indiquai ma satisfaction sur le fait que le pilote libre Mesa pour les Radeon (r600c) commençait à "montrer" ses capacités. À l'époque cependant il n'était toujours pas possible de jouer. D'autant que c'était avec le pilote r600c dont le sort était déjà connu. Le pilote r600g qui tire partie de l'architecture Gallium était le seul à avoir un avenir. Dans le 2ème journal ( https://linuxfr.org/users/whitecat/journaux/que-gagnent-red-hat-et-vmware-%C3%A0-%C3%A9crire-un-pilote-3d-amd-libre-question ) j'avais bon espoir de pouvoir jouer avec ma Radeon HD4850 (une puce R700 aujourd'hui considérée comme dépassée par beaucoup) de manière native sur Fedora 16. Hélas ce ne fut pas le cas.

Mais Fedora 17 est arrivée depuis quelques semaines et désormais c'est possible ! J'installe Fedora 17 (64 bits évidemment), je fais les mises à jour, j'ajoute le dépôt RPM Fusion afin d'installer la bibliothèque s3tc (technologie brevetée donc non incluse par défaut dans Fedora) et j'installe le jeu en suivant les instructions ( http://doc.fedora-fr.org/wiki/Enemy_Territory_Quake_Wars ). Je joue.

Quel bonheur de enfin pouvoir se passer du pilote propriétaire qui n'est pas stable, pour rester poli.

Bon tout n'est pas encore rose non plus. Je joue en 1680*1050 (résolution 16:10 native de mon écran) avec les détails graphiques réglés sur le minimum mis à part les textures qui sont au max car je n'ai pas vu de pertes de performances flagrantes en les augmentant. Mais je vais poursuivre mes tests pour voir si je peux augmenter d'autres parties graphiques. Le nombre d'images par secondes varient entre 30 et 60 FPS. Je ne monte jamais au-dessus de 60 FPS malgré le fait que le vsync ne soit pas sélectionné dans le jeu et que je lance le jeu avec la variable d’environnement vblank_mode=0. Mais le plus embêtant c'est qu'il subsiste des légers lags globalement, on sent bien que le pilote a du mal à tout gérer de façon très rapide encore. Il y a également un léger bug d'affichage qui fait que la dernière lettre des textes affichés à l'écran ne s'affiche pas. Rien d'alarmant mais je soumettrai le bug un de ces quatre. Quoi qu'il en soit à partir de maintenant je joue à ETQW avec le pilote libre r600g. Le pilote s'est montré stable jusqu'à présent (seulement quelques heures d'utilisation cependant). Il ne reste plus qu'à patienter afin d'avoir des améliorations de performance du pilote et de voir le jeu tourner rapidement avec les graphismes élevés. En lisant Phoronix je sais déjà qu'il y a de belles choses qui devraient arriver dans Mesa 8.1.

Et allez histoire d'agrémenter ce journal, voici quelques infos de ma config :

$ uname -r ; cat /proc/cpuinfo | grep "model name" ; lspci -nnk |grep -A 2 "VGA" ; glxinfo |grep -A 3 "OpenGL vendor" ; glewinfo |grep s3tc
3.4.4-3.fc17.x86_64
model name : Genuine Intel(R) CPU 2160 @ 1.80GHz
model name : Genuine Intel(R) CPU 2160 @ 1.80GHz
01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV770 [Radeon HD 4850] [1002:9442]
Subsystem: PC Partner Limited Device [174b:e104]
Kernel driver in use: radeon
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD RV770
OpenGL version string: 2.1 Mesa 8.0.3
OpenGL shading language version string: 1.20
GL_EXT_texture_compression_s3tc: OK
GL_S3_s3tc: OK

Et aussi quelque chose de beau au lancement d'ETQW, le check des extensions OpenGL par le moteur du jeu :

----- R_InitOpenGL -----
…using GL_ARB_multitexture
…using GL_ARB_texture_cube_map
…using GL_ARB_texture_non_power_of_two
…using GL_ARB_texture_compression
…using GL_EXT_texture_compression_s3tc
…using GL_EXT_texture_filter_anisotropic
maxTextureAnisotropy: 16.000000
…using GL_1.4_texture_lod_bias
X..GL_EXT_shared_texture_palette not found
…using GL_EXT_texture3D
…using GL_ARB_texture_rectangle
…using GL_EXT_texture_rectangle
…using GL_EXT_stencil_wrap
…using GL_EXT_stencil_two_side
…using GL_ARB_vertex_buffer_object
…using GL_ARB_vertex_program
…using GL_ARB_fragment_program
X..GL_EXT_depth_bounds_test not found
…using GL_ARB_point_sprite
…using GL_ARB_occlusion_query
…using GL_EXT_framebuffer_object
…using GL_EXT_packed_depth_stencil
…using GL_EXT_blend_minmax
…using GL_ARB_multisample
…using GL_ARB_shader_objects
…using GL_ARB_vertex_shader
…using GL_ARB_fragment_shader
…using GL_ARB_fragment_program_shadow
…using GL_ARB_shadow
…using GL_ARB_depth_texture
…using GL_EXT_gpu_program_parameters
…using GL_EXT_timer_query
X..GL_GREMEDY_string_marker not found
…using GL_EXT_texture_compression_latc

Dans mes souvenirs d'il y a 1 ou 2 ans le pilote propriétaire (fglrx) ne gérait pas autant d'extensions !

  • # "avec les détails graphiques réglés sur le minimum"

    Posté par  . Évalué à 4.

    Je n'appelle pas ça out-of-the-box …

    Mais c'est prometteur en effet.
    C'est à suivre, vu qu'AMD veut abandonner le support des ancien GPU(niveau pilote proprio).

    (la 4850 est globalement suffisante pour les jeux sous GNu/Linux(hors jeux basés sur Unigine).

    • [^] # Re: "avec les détails graphiques réglés sur le minimum"

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

      On pourrait avoir un screenshot? car comparer les FPS sans comparer la qualité n'est pas très probant. De ce que j'ai testé, parfois beaucoup d'effets visuels sont absents avec le pilote libre.

    • [^] # Re: "avec les détails graphiques réglés sur le minimum"

      Posté par  . Évalué à 2.

      Euh,sous Windows la 4850 fait tourner Crysis 2 en 1920x1080 quasiment au max (FSAA 2x), donc y a de la marge.
      J'avais eu une telle carte mais le pilote proprio freezait la machine sous Linux, le pilote 2D faisait son boulot mais j'avais besoin de la 3D :/.

      @WhiteCat: Pourrais-tu essayer Blender et executer sa suite regression test (30mo) avec les pilotes Mesa, stp?
      Aussi, peux-tu me dire quelle est ta résolution d'écran?
      Si c'est concluant, je me débarasse de mon nVIDIA.

      Merci

      • [^] # Re: "avec les détails graphiques réglés sur le minimum"

        Posté par  . Évalué à 3. Dernière modification le 06 juillet 2012 à 09:56.

        Crysis2 est moins gourmand que Crysis 1 (Crysis2 n'est qu'un portage console moisi).

        Ma 4870, puis ma 5870 fonctionne sous Archlinux(Catalyst), c'est juste que le pilote ne supporte pas les derniers paquets(xorg-server notamment).

        La on parle de pilote libre.

      • [^] # Re: "avec les détails graphiques réglés sur le minimum"

        Posté par  . Évalué à 2.

        Je veux bien mais si tu m'expliquais comment faire tourner ces tests. Je ne connais absolument rien à Blender.

        • [^] # Re: "avec les détails graphiques réglés sur le minimum"

          Posté par  . Évalué à -3.

          Il te suffit d'ouvrir le .blend correspondant à une application dans Blender, par exemple

          animation/dolphin.blend
          physics/softbodycurve_lattice.blend
          _Tu lances l'animation avec ALT+A ou tu suis le texte explicatif que tu verras à l'ouverture

          NB: ce ne sont pas des exemples intensifs, mais bon, si tu as 30 ou 40fps avec ta resolution de 1680x1050, ça devrait dépanner.

          Tu peux également tester ce jeu Blender: http://deadcyborg.com/ qui utilise pas mal les shaders OpenGL.

          Et puis tout simplement, le rendu et la réactivité de l'interface utilisateur, les ATI/AMD ont souvent posé problèmes - artefacts, absence d'éléments - avec le toolkit graphique de Blender mais maintenant que j'y pense, je crois que ce n'étais qu'avec les pilotes FRGLX.

          Merci pour ta disponibilité!

    • [^] # Re: "avec les détails graphiques réglés sur le minimum"

      Posté par  . Évalué à 2. Dernière modification le 06 juillet 2012 à 19:19.

      On n'a clairement pas la même définition de out-of-the-box… Chez moi c'est que ça doit marcher tout de suite sans se prendre la tête.

    • [^] # Re: "avec les détails graphiques réglés sur le minimum"

      Posté par  . Évalué à 2. Dernière modification le 06 juillet 2012 à 19:43.

      Je viens de faire des essais en augmentant les graphismes. En mettant tout sur Normal et Anisotropie sur 4, je reste au même nombre de FPS.

      En fait il y a une option qui fait tout de suite chuter les performances, c'est "Soft particules" (r_softParticles). Si c'est activé je tombe à 15-20 FPS ce qui devient injouable. Mais visiblement c'est "normal" : https://bugs.freedesktop.org/show_bug.cgi?id=36918

      Une petite explication sur les soft particules: http://www.gamerendering.com/2009/09/16/soft-particles/

      • [^] # Re: "avec les détails graphiques réglés sur le minimum"

        Posté par  . Évalué à 1.

        Ah,pas si mauvais donc, mais c'est réellement stable niveau FPS, au moins 30?
        C'est un jeu multi et plutôt "quasi fast FPS", 60fps ne serait pas de trop pour ETQW.
        Aucun artéfact en moyen aussi ?

        • [^] # Re: "avec les détails graphiques réglés sur le minimum"

          Posté par  . Évalué à 1.

          Avec des graphismes au plus bas c'est plus jouable quand même effectivement, on reste sur du 30 FPS mais selon les cartes il y a très régulièrement des chutes à 10 FPS et ça saccade, c'est assez désagréable pour jouer. Dans les scènes intérieures (bâtiment par exemple) on monte beaucoup en FPS.

          Sinon je n'ai vu absolument aucun artefact.

  • # Un autre point de vue

    Posté par  . Évalué à 3.

    C'est drôle, en lisant ton journal, je me dis « chouette, ça a peut-être avancé niveau perfs », et je regarde le résultat de ta commande pour mon système actuel :

    % uname -r ; cat /proc/cpuinfo | grep "model name" ; lspci -nnk |grep -A 2 "VGA" ; glxinfo |grep -A 3 "OpenGL vendor" ; glewinfo |grep s3tc 3.2.0-2-amd64
    model name      : AMD Athlon(tm) X2 260 Processor
    model name      : AMD Athlon(tm) X2 260 Processor
    01:05.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI RS780 [Radeon HD 3200] [1002:9610]
            Subsystem: Giga-byte Technology GA-MA78GM-S2H Motherboard [1458:d000]
            Kernel driver in use: radeon
    --
    02:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI Manhattan [Mobility Radeon HD 5430 Series] [1002:68e1]
            Subsystem: PC Partner Limited Device [174b:3000]
            Kernel driver in use: radeon
    OpenGL vendor string: X.Org
    OpenGL renderer string: Gallium 0.4 on AMD CEDAR
    OpenGL version string: 2.1 Mesa 8.0.3
    OpenGL shading language version string: 1.20
    zsh: command not found: glewinfo
    
    

    Niveau soft, c'est pareil ; niveau hard, on va dire CPU équivalent, mais carte effectivement moins puissante (je n'utilise plus l'intégrée).

    Et bah moi je fais juste de la 2D, l'accélération c'est juste pour les effets de gnome shell… Et bien c'est pas très fluide tout ça ! Certes, j'ai un gros affichage :

    % xrandr | head -1
    Screen 0: minimum 320 x 200, current 4020 x 1680, maximum 8192 x 8192
    
    

    Mais franchement, c'est à la limite du supportable tellement les trucs sont lents des fois (et c'est réellement du à l'affichage ; sur l'intégrée en simple écran, ça va). Je ne pense pas que la carte soit limitante, enfin j'espère, donc je pense qu'il reste encore des efforts à faire au niveau de ces drivers. Mais ça s'améliore régulièrement…

  • # sur les fonctionnalités 3D de radeon

    Posté par  . Évalué à 6.

    Pour info il y a un tableau qui récapitule toute les fonctionnalités du pilote radeon :

    http://www.x.org/wiki/RadeonFeature

  • # ACHAT D'UNE 6670

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

    J'ai acheté une 6670 car Diablo III sous 4650 était un peu juste.

    Refroidissement passif (merci la descente en finesse de gravure)

    J'ai esséy avec le driver libre… y'avait pas moyen encore (mageia 2) du coup, je usis en fglrx.

    Mai sje ne désespère pas que les drivers libres y arrivent.

Suivre le flux des commentaires

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