Ben voilà, l’encodage vidéo c’est différent du jeux video. Toutes les données sont connues à l’avance.
Tu ne t’amuses pas à modifier la vidéo en cours d’encodage par ex.
Donc effectivement tu peux charger les données par lot et faire le traitement de la sorte.
Pour un jeu vidéo, tout dépend, par défintion, des actions du ou des joueurs. Choses que tu ne peux pas prévoir, tu es donc forcement dans l’attente de ces actions qui vont avoir un impact sur tout le reste du processus.
Et non, en temps réel tu n’as qu’1 ou 2 images d’avance (au delà tu as un retard/latence qui devient gênant), la vidéo arrive au fil de l’eau (filmée par une caméra par ex.)
A la base non car pour calculer un bloc de pixels tu as besoin des données des blocs précédents, les blocs d’une image sont tous interdépendants, difficile de les grouper par lots dans ces conditions.
Pour une vidéo en temps réel c’est pareil, la prochaine image dépend de ce que vont faire les acteurs devant la caméra par ex. Les contraintes sont exactement les mêmes.
Edité le 24/10/2008 à 11:23
Je ne pense pas, non.
Ca s’en rapproche mais il y a tout de meme beaucoup moins d’interaction.
Tu ledis toi même tu as ou un deux images d’avances, c’est « suffisant » pour faire ton traitement sans contraintes « extérieures ». A ce moment là tes images sont figées pour le CPU et il peut faire son processus comme si c’etait de l’image fixe. Le plus dur pour toi étant d’arriver à faire en sorte que le traitement soit suffisemment rapide pour qu’il puisse passer aux images suivantes à temps.
Pour un jeu video, les images sont générées au niveau du frame buffer du GPU, c’est donc pas là-dessus que le CPU va pouvoir travailler. Par contre il va devoir faire le liens entre les données du moteur physique, celles du moteur d’IA, celles des actions du ou des joueurs, etc. Toutes ces données sont liées, changent en permanence, et sont majoritairement dépendante des actions du ou des joueurs.
On a donc trois, voir quatre processus principaux (on va eviter de trop rentrer dans les détails) qui ont besoins des mêmes données en même temps, sachant que ces données changent constamment en fonction des résultats de chaque processus. Et ces même données doivent être envoyés le plus rapidement possible à la carte vidéo pour que celle-ci fasse son boulot et que le joueur ai un affichage instantané de l’action qu’il vient d’effectuer.
C’est tout sauf trivial cette histoire 
Si tu recalcules tout en permanence en fonction des actions des joueurs tu peux avoir des soucis, avant de calculer une image, idéalement il faut figer les positions et actions des joueurs étant donné que tout ce qui se passe dans l’image est censé se passer au même instant. L’idéal est de ne rafraichir les actions/positions du joueur, PNJ… qu’à chaque image (un peu comme le Vsync au niveau de la CG), ou du moins le temps de recalculer l’ensemble des positions des éléments 3D qui composent la scène puis d’envoyer le tout vers la CG. Ou justement de regrouper ces éléments sous forme de lots et de ne raffraichir les données d’entrée (actions du joueur, physique) que de temps en temps (mais suffisamment souvent pour éviter les mouvements saccadés). Enfin bref je suis sûr qu’il existe des solutions mais possible que ça remette en cause pas mal de choses (et que donc les développeurs attendent un peu avant de se lancer là-dedans), quand un algo n’a pas été prévu pour être (fortement) parallélisé, il faut souvent presque tout repenser si on veut que ce soit efficace.
Edité le 24/10/2008 à 11:52
Bonjour,
Le poilu et almalexia vous semblez calé niveau prog.
Pour un 4 coeurs finalement ce qui compte le plus (pour les jeux vidéo) c’est le cache L3 qui permet les interconnexions entre les différents coeurs. Pour vous le cache L3 des core 2 Quad sera-t-il suffisant lorsque les jeux seront optimisés multi-coeurs? Ou est-ce que le core i7 sera mieux adapté? Je ne connais pas la taille du cache L3 pour le i7.
Pour vous il faudra combien de temps pour avoir des jeux optimisés Quad?
Les Core 2 Quad n’ont pas de L3 à cause de leur conception. Ce sont deux Code 2 Duo collés ensemble. Il ne peut y avoir de cache partagé L3 entre les quartes curs. Les échanges se faisant par le FSB
Pour le Core i7 : On saura quand il sera là. On peut quand même se dire que les gars de chez Intel ne sont pas nés de la dernière pluie et qu’ils font les choses qui vont dans le « bon sens ».
Mais actuellement on peut voir qu’AMD avec ses quad « natifs » Phenom X4 qui ont un cache L3 ne supplantent pas les Code 2 Quad « old-school ». Et les principes du cache du i7 sont assez semblables à ceux du Phenom… (après d’autres choses diffèrent bien sur mais ça donne une idée)
Difficile à dire tellement il y a de composantes qui entrent en jeux. Rien de garanti que les jeux puissent (je parle en général sans m’arrêter sur certains cas particuliers) vraiment tirer parti d’un quad-core… tout comme si ça se trouve dans 2-3ans ce deviendra quasi-obligatoire.
On est d’accord sur ce point 
Edité le 24/10/2008 à 12:32
Bon ok je m’intéresse de plus en plus au hardware mais j’apprends sur le tas. Du coup mes connaissances au sujet du FSB sont limitées. Peut tu m’expliquer un peu plus l’échange par le FSB. Merci.
Deuxième question : une core 2 duo a un FSB de 1333 Mhz. On fait bien 1333/2 pour avoir le FSB par coeur?
Du coup pour un core 2 quad, aussi à 1333 Mhz il faut donc faire 1333/4. Si le FSB des coeurs du Quad passe à 333 Mhz au lieu de 666 pour les Duo, cela change t il les perf.
Encore merci.
On m’a déjà expliqué ça une fois mais pas sûr de pouvoir le ressortir
Je sais que quand un proc va écrire dans la RAM, il écrit en même temps dans le cache de l’autre proc pour éviter les problèmes de cohérence. Ca marche aussi bien pour un C2Q (qui est égal à 2 C2D) que pour une machine multiproc (genre 2 C2Q = 4 C2D)
Edité le 24/10/2008 à 13:48
Ce n’est vraiment pas tout les Q6600 qui s’OC à 3.8 Ghz et ceux qui le font ne sont pas toujours confortables pour une utilisation de tout les jours :neutre:
edit: Ceux qui disent qu’un QUAD est moins performant dans les jeux qu’un DUAL CORE sont en tord, à fréquence égale, s’ils sont de même génération ils seront égaux en terme de performances dans les jeux
Edité le 24/10/2008 à 16:31
oui mais souvent les quads sont moins haut en fréquence @stock donc ils disent ca 
Bien sûr qu’à fréquence égale ils sont aussi performants, mais en général quand on hésite entre quad et dual c’est pour un budget à peu près similaire, et pour le même prix le dual est plus performant car il a plus de cache et une fréquence plus élevée.
grilled ? :ane:
Même pas vrai :o
[:shy]
En gros, faire ce qui se fait déjà dans le domaine des automates: Figer l’état de la table des entrées avant d’executer le un cycle Cpu d’automate.
C’est clair que ça permet de bosser sur des données certaines et surtout qui ne risquent pas d’évoluer en cours de cyle de programme (manquerait plus que ça :paf:² )
Ouai … mais non pas du tout
Tu peux déja commencer par lire ça
et peut-etre aussi ça:
Tu devrais y voir plus clair ensuite
OK merci pour les infos. Je lirai ton article car il a l’air interéssant.
Par contre tu peux me faire un petit résumé sur le point que je t’ai demandé. Les core 2 duo ont bien un FSB de 666 par coeur et un core 2 quad un FSB de 333.
Si oui, des baisses de perf sont elles possible ou observées.
Merci
Non. Un code 2 Duo c’est un processeur à par entiere qui a un FSB. CeFSBest de x MHZ et n’est absolument pas divisé par deux.
Chaque coeur peut acceder au FSB à la frequence nominale soit 1333 (par ex). Il faut juste savoir que le 1333 c’est en fait 4*333Mhz. La vrai frequence du FSB c’est 333Mhz mais elle est multipliée par quatre grace au Bus type QuadPumped (heritage du Pentium4) qui permet de transporter 4 bit de données par coup d’horloge.
Apres forcement si les deux coeurs tentent un acces mémoire (donc via le FSB) en meme temps, il se partageront la bande passante du Bus. C’est d’autant plus vrai pour un Core 2 Quad qui est une addition de 2 Core 2 Duo dans e meme P et que les 2 Core 2 Duo ne peuvent communiquer ensemble que via le FSB (pas de lien direct entre les 4 coeurs)
Merci de tes lumières Le Poilu.
La conclusion de ce topic c donc que pour aujourd’hui et demain un core 2 Duo est le mieux adapté au gaming.
Pour toi, même lorsque les programmes seront optimisés multicoeurs est ce que le système de connexion par le FSB ne sera pas une limite dans les transferts des données pour les calculs en parallèle nécéssaire au jeux vidéo.
Dernière petite question : pour FarCry 2 on voit que la config conseillée est un core2duo mais ils ne précisent pas la fréquence. Sais-tu à combien de Ghz on culmine actuellement sur les jeux. C pour savoir la marge que je pourrais avoir en prenant un E8400.
A plus.
avec un c2d a 2.4ghz tu fait tourner ce que tu veux mais un c2d a 2.6 2.8 ghz pour être vraiment a l’aise le plus important c’est la carte graphique ds les jeux !
Edité le 25/10/2008 à 02:35
Non, surtout que d’ici là le core i7 auira du se généraliser et ce dernier n’a plus de FSB vu que le controleur mémoire est integré au CPU.