Le multicore prend de l'ampleur dans les jeux

C'est bien normal

Patoch a écrit:
Après s'adapter fait partie de leur métier. C'est comme si un juriste se plaignait de l'apparition de nouvelles lois ou qu'un comptable fasse de même pour de nouvelles normes qui changent profondément leur métier. :neutre:

Mais ils se plaignent :neutre:

jijiz a écrit:
->zarmathoustra
Tout à fait, 64 bits obligatoire pour 4 go de ram. Avis à ceux qui pensent que ça sert à rien... On disait la même du giga lorsque l'on avait 256 mo de ram.

Pas nécéssairement les Windows 2000 server gèrent plus de 4Go de ram en étant 32 bits

megadub a écrit:

Les bi-pro ça date pas d'hier... les dévs auraient du s'adapter depuis longtemps :o

Sinon, les problèmatiques de lock et cohérence de lecture ça date pas non plus d'hier, ce qui a été fait depuis plus de 30 ans dans les SGBD notamment devrait pouvoir resservir.. c'est pas comme si il fallait tout réinventer :neutre:

C'est pas parce que le concept existe depuis longtemps que ca fait que c'est simple, la programmation multithread est pleine de pièges dans tous les cas. Et de plus même si les bipro existent depuis longtemps ca fait très peu de temps que les particuliers en sont équipés en masse

[

jijiz a écrit:
->ingham_

Ok ! En fait, j'ai qques notions de prog parralelle, rendu 3d et c'est vrai que s'il mettre des mutex sur chaque entité du jeu... ca sert plus à rien d'avoir 10 coeurs.

C'est clair que prendre une application mono-thread, la couper en morceaux et mettre des mutex (ou tout autre moyen de synchro) ça marchera pas dans tous les cas. Et dans un jeu je pense que ça doit être assez catastrophique... Les structures de données doivent être pensées pour des accès concurrents, à mon avis c'est la clef. Toute l'application tourne autour de ça.

Après y a le problème de l'adaptation aux CPU: un dual est souvent plus rapide par cœur et prend donc l'avantage si un thread est très (trop) gourmand. Si on veut avoir une appli qui tourne correctement quelque soit la configuration, il faut s'arranger pour ne jamais avoir de thread de cette nature: pas toujours facile, et c'est certainement pas encore prévu dans les jeux actuels. Le rendu, la physique ou l'IA qu'il faut traiter en deux morceaux ça doit sérieusement compliquer la tâche.

Il n'est pas précisé quel est le processeur utilisé dans le test. On ne sait que : 1 core vs 2 core. Ca peut être un athlon 2800+ contre un QX6850. ^^
ce serait bizarre mais bon.
Arrêtez moi si je me trompe.

Je suis plus que dubitatif de voir des perfs plus que doublées entre deux cores et un seul sur le graphique montré.

Aucun bench ne donne deux fois plus de perfs en passant d'un à deux coeurs. Même si en théorie c'est possible ce n'est jamais le cas en réalité.

De plus les GPU utilisés sont précisés mais pas les CPU. Alors moi aussi je peux faire un bench avec P4+9800x2 d'un coté et E8500+9800x2 de l'autre et montrer que les perfs sont doublées...

supernaz a écrit:

Fantominus a écrit:
Passer d'une moyenne de +/- 12fps à +/- 60fps (soit 5 fois plus !) en passant de 1 à 2 cores, j'ai comme l'impression qu'il y a quelque chose de bizzare ....

+1
une moyenne de 10 FPS sur Accassin's Creed avec une 9800GX2, meme avec 1 seul proco, je suis vraiment TRES sceptique...

Visiblement t'a un peu de mal avec les graphiques...

kpouer a écrit:
C'est pas parce que le concept existe depuis longtemps que ca fait que c'est simple, la programmation multithread est pleine de pièges dans tous les cas. Et de plus même si les bipro existent depuis longtemps ca fait très peu de temps que les particuliers en sont équipés en masse

Le fait qu'il y ait des bi-cœurs n'est qu'une simple motivation supplémentaire pour se pencher sur le problème.
Ce qui était un plus avant, devient une nécessité. Mais heureusement, on a pas attendu les bipro pour développer le parallélisme, d'abord dans les OS, puis dans les applis. Ca n'est plus une simple découpe interface / traitement comme au début, maintenant on a la possibilité de séparer plusieurs traitements (et biensûr l'interface), ce qui même sur un mono-cœur offre de gros avantages.

Je ne sais pas si quelqu'un l'a déjà dit mais pour les sceptiques comme:

supernaz a écrit:

Fantominus a écrit:
Passer d'une moyenne de +/- 12fps à +/- 60fps (soit 5 fois plus !) en passant de 1 à 2 cores, j'ai comme l'impression qu'il y a quelque chose de bizzare ....

+1
une moyenne de 10 FPS sur Accassin's Creed avec une 9800GX2, meme avec 1 seul proco, je suis vraiment TRES sceptique...

Il est bon de lire sur le graphique qu'il s'agit d'un bench CPU, il est donc normal que l'influence du CPU soit très importante. :oui:

Ce n'est pas simple pour les développeurs. Ils ont des contraintes de temps terribles.
C'est déjà dur de pondre du code mal optimisé, alors ensuite si faut repartir sur chaque procédure pour l'optimiser dualcore...en conservant le planning prévu, c'est utopique

Nehalem a écrit:
il est donc normal que l'influence du CPU soit très importante. :oui:

Euh c'est quoi exactement un "bench CPU" mesuré en FPS?

hamsterfou a écrit:
Je suis plus que dubitatif de voir des perfs plus que doublées entre deux cores et un seul sur le graphique montré.

Aucun bench ne donne deux fois plus de perfs en passant d'un à deux coeurs. Même si en théorie c'est possible ce n'est jamais le cas en réalité.

Ca dépend de l'appli et comment elle est codée. Tu as théoriquement deux fois plus de puissance, donc en pratique pas tout à fait.
Mais le résultat en FPS dépend de la façon dont l'appli est organisée. Si tu as une partie qui génère les données à rendre qui bouffe disons 20% sur le monocoeur, il te reste 80% pour le rendu. Sur un double coeur, si la génération des données prend toujours 20% d'un cœur, c'est 180% qui sont dispo pour le rendu si celui-ci exploite au moins deux threads au lieu de 80%... Tu as ton x2.
Donc c'est possible, ça dépend comment le programme est conçu et s'il ajuste la consommation de tous les threads ou pas, et comment il l'ajuste. Ca dépend aussi de la capacité des traitement slourd à se répartir correctement.

Mais tu as raison, il peut facilement y avoir une différence à cause d'une comparaison avec deux CPU trop différents (fréquence, cache...).

ils ont réussi à démontrer qu'un double core était plus puissant qu'un simple core ? waaawww TROP fort. -_-'

Euh c'est quoi exactement un "bench CPU" mesuré en FPS?

Tu préfères quand c'est calculer en os de dinde?
C'est généralement el cas dans une résolution basse, ou simplement lorsque le jeu utilise à un moment souhaité plus de puissance cpu que gpu

Nikooo a écrit:

Il me semble qu'Intel a fournit des docs et des outils de dév pour les multicoeurs, donc c'est sûr que se renouveller, c'est pas toujours facile, les gens aiment le status quo....

:neutre:

Ces docs sont spécifiques aux processeurs Intel ou ce sont des docs "génériques" ?

---

megadub a écrit:

yplenet a écrit:

Le besoin de faire du multi-thread est relativement nouvelle, il n'existe donc pas de forcément de méthodes fiables ni de librairies.
Rome ne s'est pas fait en un jour et il faudra un bout de temps avant que tous les outils soient adaptés.

Les bi-pro ça date pas d'hier... les dévs auraient du s'adapter depuis longtemps :o

Sinon, les problèmatiques de lock et cohérence de lecture ça date pas non plus d'hier, ce qui a été fait depuis plus de 30 ans dans les SGBD notamment devrait pouvoir resservir.. c'est pas comme si il fallait tout réinventer :neutre:

Ca date pas d'hier mais c'était quand même plutôt réservé à des applis "pros". Et je doute que ces dévs aient migré vers le développement de jeux ;)

Sinon comme dit plusieurs fois le boulot actuel d'un développeur de jeu c'est de réussir à finir dans les temps, alors si en plus ils faut anticiper sur les technos à venir... :paf:

Aerel a écrit:
ils ont réussi à démontrer qu'un double core était plus puissant qu'un simple core ? waaawww TROP fort. -_-'

:non: Ils ont montré qu'une application donnée se comportait mieux sur un double cœur que sur un simple. Ce qui est bien plus intéressant, bien que trop limité :paf:
Y a une notion d'utilité qui apparait et que tu n'as pas quand tu dis simplement "un dual-cœur est plus puissant qu'un simple-cœur".
Acheter un dual ou un quad s'il ne sert à rien, c'est du gaspillage.

Proutie66 a écrit:

Euh c'est quoi exactement un "bench CPU" mesuré en FPS?

Tu préfères quand c'est calculer en os de dinde?
C'est généralement el cas dans une résolution basse, ou simplement lorsque le jeu utilise à un moment souhaité plus de puissance cpu que gpu

Maintenant, je titre de la news c'est "le multi-core prend de l'ampleur dans les jeux", donc le but c'est de voir si le multi-cœur est utile dans les jeux, pas de savoir si le mono cœur c'est mieux que le bi-cœur ou pas ou si les FPS sont une bonne mesure de la puissance d'un CPU: on sait que non, suffit d'aller voir un test CPU pour voir que ce n'est qu'un petit test parmi d'autres. C'est pas le cas ici.

pete_get27 a écrit:
megadub : oué enfin un sgbd les contraintes temporelles sont pas les mêmes..

Bah si :neutre: Les SGBD comme d'autres applis sont au multi-core depuis un bon moment et les problématiques sont strictement identiques :)

Des jeux comme rFactor ou GTR2 et Race07 permettent l'utilisation des doubles coeurs (on rajoute une option à la fin de la commande (style rfactor.exe dual=enable).

Enfin, pour des Core 2 Duo ou X2, c'est une bonne chose ;)

Chacun son taf, le taf des programmeurs evolue alors au boulot !
Autrefois les secretaires bossaient avec des machines à écrire, maintenant faut savoir se servir d'un pc et de Word (entre autre) !
Chacuns son affaire, tout est question d'evolution !

Wahouuuuu ... tout et son contraire ! Magnifique.

Je prends pas la peine de quoter les posts, cela reviendrait à quoter tout le topic.

Je poserai le débat d'une manière différente : une application multi-threadée (tirant parti d'un multi-core et/ou multi-processeur) n'est pas l'oeuvre d'un programmeur mais le fruit d'une analyse fonctionnelle puis technique. Avec une bonne analyse, pas besoin de verrous en pagaille, et une structure de donnée bien faite permet la réentrance et donc le massivement multi-threadé.

Maintenant, la problématique pour les jeux, de part les contraintes de calendrier font que les analystes et les programmeurs ne se reposent que sur les librairies qu'il maitrisent avec toutes les contraintes hérités des noyaux des jeux sous MS-DOS (CàD la bonne grosse boucle sans fin qui teste tout les événements tout le temps). Ce sont des assembleurs, ils ne conçoivent rien d'un point de vue technique ... je ne suis même pas sûr qu'ils savent ce qu'est emacs. :/

megadub a écrit:

pete_get27 a écrit:
megadub : oué enfin un sgbd les contraintes temporelles sont pas les mêmes..

Bah si :neutre: Les SGBD comme d'autres applis sont au multi-core depuis un bon moment et les problématiques sont strictement identiques :)

Disons que tu n'as quand même pas de pb si y a une petite saturation qui arrive de temps en temps lors de grosses charges: ça passe souvent inaperçu ou presque. Un jeu qui te fait des saccades c'est pas vendable :paf: