Dual core : Athlon 64 X2 4800+ et 4400+

Rendu 3D et compression vidéo en arrière plan, et vice-versa

Cette fois nous avons décidé d’aller plus loin en combinant le rendu 3d studio max 7 (multi thread) avec l’encodage DiVX sous VirtualDub (mono thread). Sont reportés la somme des temps nécessaires à la réalisation des deux tâches l’une après l’autre (le rendu étant 1.17 à 2.22x fois plus rapide de base que l’encodage selon le CPU), le temps global pour finir les deux tâches avec 3ds max au premier plan et le temps global avec virtualdub au premier plan.


C’est à une exception près le couple encodage DiVX au premier plan / rendu 3d au second plan qui est le plus rapide. Par ailleurs, quand 3d studio est au premier plan, il est toujours le premier à finir, par contre quand c’est Virtual dub c’est variable : avec HyperThreading ou dual core, c’est 3ds qui termine en premier, et sans c’est Virtual dub. Par ailleurs, toujours sans HT et dual core, le fait de lancer les deux applications en parallèle ralentit légèrement le temps d’exécution global.

Les gains les plus importants sont enregistrés sur les processeurs Intel dual core sans HT, ce dernier ayant ici un impact fort négatif sur ce type de processeur, la gestion de threads répartis sur les 4 processeurs logiques semblant poser problème sous Windows.

Chez AMD les gains sont toutefois également plus que notables puisqu’on atteint tout de même 44% ce qui est loin d’être négligeable. En fait sur les processeurs dual core dans ce cas où l’application mono thread prend de base nettement plus de temps que la multi thread, le fait de lancer les deux tâches en même temps fait que l’ensemble de ces tâches s’effectue dans un temps comparable à celui pris pour la tâche mono thread seule.

Jeu et compression vidéo en arrière plan

Voici notre dernier scénario multitâche, à savoir le jeu pendant une compression vidéo DiVX sous Virtual dub en arrière plan. Ce genre de chose est assez difficile à mesurer précisément dans tous les cas de figure, et nous couplerons donc des chiffres à proposer pour Pacific Fighters à un ressenti sous Far Cry.

Pour Pacific Fighters, nous avons mesuré la moyenne du framerate obtenu dans notre replay habituel de 2 minutes sans rien derrière, puis avec la compression en arrière plan, et enfin en abaissant la priorité de Virtual dub d’un cran et en le forçant sur le CPU0 sur les CPU simple core, ceci afin d’obtenir un framerate plus élevé lorsque cela était nécessaire.

Il faut noter que ce n´était pas le cas ici pour les processeurs dual core pour la simple et bonne raison que la compression DiVX sous Virtualdub n’est pas vraiment multithreadée. Lorsque c’est le cas pour la tache en arrière plan, il vous faudra alors soit baisser la priorité de cette tache en arrière plan multithreadée, soit attribué une affinité sur un des deux processeurs pour celle-ci, afin de ne pas voir vos les performances de la tache au premier plan (le jeu) baisser de manière trop importante. Une fois ces réglages effectués, comme dans le cas ci-dessous le jeu ne verra pas ses performances baisser notablement, et la tache multithreadée s’exécutera à la vitesse d’un des deux core, voir plus si le réglage de la priorité suffit et que le jeu n’utilise pas toujours le CPU à son maximum.

Bien entendu ces informations ne seraient pas utiles sans une autre qui est l’avancement de la compression pendant la durée du replay. On reporte donc cet avancement après 2mn05s (temps de chargement du replay + replay) sans rien, après le replay, et après le replay avec l’affinité et la priorité de virtual dub réglées manuellement.


La première chose à noter en observant la seconde colonne de résultats est que le framerate moyen, si il est d’habitude révélateur des performances et de la jouabilité, n’est l’est pas ici sur les processeurs simple core sans HyperThreading. En effet, malgré un framerate moyen assez élevé, le tout était très saccadé et injouable ! Malheureusement le chiffre de framerate le plus bas rapporté par FRAPS ne donne pas vraiment d’information sur ce phénomène puisqu’il s’agit d’un framerate le plus bas moyen sur une seconde.

En effet si pendant un dixième de secondes on à 5 frames affichées après 0.02, 0.02, 0.02, 0.02 et 0.02 secondes d’un côté et 5 autres affichées après 0.01, 0.01, 0.06, 0.01 et 0.01 secondes, le chiffre rapporté par fraps sera identique alors que la sensation de fluidité sera meilleure dans le premier cas.

Le dual core démontre ici tout son intérêt puisque le framerate dans le jeu ne baisse que très peu alors que l’avancement de la compression vidéo monothread en arrière plan a avancée dans les mêmes proportions qu’en laissant le PC inactif.

Les processeurs mono core ne permettent bien entendu pas d’aller aussi loin. Sans HyperThreading c’est injouable sauf si l’on baisse la priorité de la compression … ce qui fait qu’elle n’avance plus alors d’un poil pendant le jeu. Cela reste tout de même encore injouable du fait d’une micro saccade toutes les 3-4 secondes.

Seul l’HyperThreading permet d’avoir un framerate assez faible mais régulier avec un bon avancement de la tâche en arrière plan, ou un framerate plus élevé mais un avancement moindre en abaissant la priorité de l’encodage.

Pour ce qui est nos observations sous Far Cry, elles sont similaires à ce que nous avons mesurés sous Pacific Fighters. Far Cry est donc complètement injouable sur un processeur mono core sans hyperthreading avec une tâche lourde lancée en arrière-plan, même si l’on abaisse sa priorité. Avec le dual core, c’est parfait !