(MAJ) sortie de clodo + Screenshots de BoB in-game !

[ChrisDNT]

Sur le multicore...

http://simhq.com/forum/ubbthreads.php/t ... ost3249155

... pas bon.

Comment en effet faire durer une simulation basée sur une technologie dépassée ou un pis-aller (ce machin "hybride") ? Désolé, mais en 2011, un jeu doit être en 64 bits et compatible multicores !

[Gourmand]

Désolé, mais en 2011, un jeu doit être en 64 bits et compatible multicores !

un jeu pas forcement, mais une simu, oui. c'est inconcevable que sa ne soit pas
multi-core, d'ailleurs je ne le conçois pas... a voir si dans leur ini ils ont bien mit le multi-core, ou si ils ont tellement reduit les settings qu'un seul core suffisait....
dans 1946 la gestion multicore existais deja...

[Shane]

GOURMAND, non dans IL2 1946 la gestion multicore n'xistait pas.
change le processaffinitymask= dans IL2 1946 et dis moi si tu gagne 1 seul fps en plus.
ca a déja été testé des dizaines de fois et ca ne change absolument rien.
Luthier a par contre répondu pour IL2 COD et a proposé aux simmers de tester IL2COD en mettant le processaffinitymask=1 pour le faire tourner sur un seul core afin de voir la difference.
je n'ai pas eut le temps d'essayer, mais je le ferais afin de voir.
par contre j'avais deja vérifié l'occupation cpu dans le gestionnaire de taches et m'etait etonné de voir que cette occupation cpu variait entre 19% et 45%. ce qui est effectivement faible comparé par exemple a ROF qui lui est tres bien multitreadé. et occupe entre 65 et 85% de mon cpu.
je suis donc d'avis qu'IL2 COD est bien multithreadé, mais pas suffisamment.
ou alors que le thread principal est trop gourmand par rapport aux autres. ce qui fiat qu'il y a un thread qui bloque les autres a un moment donné.
les bons moteurs savent par exemple partager tout ce qui est affichage entre plusieurs cores vu que c'est une tache tres lourde.
le reste des taches etant a son tour placé sur differents cores comme: la physique sur un core, le son sur un autre, etc...
pour les taches les plus legeres un seul core peut en recevoir plusieurs, et pour les plus lourdes il est quasi impreatif qu'elles puissent etre reparties entre plusieurs cores.

dans un de nos jeux ici sorti sur xbox360 il y a qq années, quand le moteur avait été optimisé pour passer de 1 a 3 cores (la xbox360 a un tricore pour rappel) on avait gagné au moins +60 a +80% de fluidité.

c'est donc vraiment indispensable avec les moteurs recents d'avoir une bonne repartition entre les cores.
et de ce coté la, ca semble assez peu optimisé sur IL2COD.
ou en tous cas la charge cpu a l'air vraiment tres faible comparativement a la quantité de trucs a gerer et a afficher.

[Gourmand]

bon je me suis enfin mit a lire se thread sur simhq
si je comprend bien
y a un coeur dedier au son + l'affichage des texture en streaming et le reste au jeu

[UF_Zargos]

Arrêtez moi si je dis une ânnerie ...
Si on arrivait à optimiser le multi-core ça voudrait dire que l'on pourrait charger plus efficacement les "gros" processeurs genre i5 ou i7 et que ça soulagerait les cartes graphiques qui de ce fait pourraient consacrer plus de ressources à un meilleur rendu graphique ?

[raoul volfoni]

En fait, l'optimisation multi processeurs permettrait au soft d'aller coller des calculs sur les processeurs les plus délestés, et ainsi procéder à une répartition de la charge sur les différents coeurs... les anciennes versions de processeurs Intel ou AMD seraient aussi bénéficiaires de cette fonctionnalité, pas seulement les derniers joujoux sortis

[Shane]

bien evidemment.
comem dit plus haut, idealement la charge d'affichage devrait etre répartie sur 2 cores au moins, puis la pysique sur un autre et le son sur un autre.
si effectivement la seule chose qu'ils ont multithreadé c'est le son, forcement, ca peut pas etre bien fluide avec tout ce qu'il y a a gerer.
peut etre qu'ils auraient du dédier une partie du budget a faire former certains de leurs ingés au multithreading si ca n'a pas été fait.
je dis ca snas savoir ce qu'il en est, mais a l'heure actuelle ca merite un ingé a plein temps ce genre de taches. vu l'importance que ca peut avoir.
tiens pour voir faudrait que j'essaye ROF en mettant l'affinité sur un seul core afin de voir comment il se comporte. a mon avis ce sera un désastre.

[Gourmand]

heu je crois que la question de zargos reposais justement sur le type de calcul...
a savoir si sa pouvais alleger la CG pour eviter de la fumée noire, ou si quoiqu'il arrive c'est indépendant et la CG morflera elle a fond

[Vevster]

LOL ! Déjà les premiers mods :D

Y a des zombies aussi ?????

et des booobs ???? :Jumpy:

[Shane]

non c'est pas comme ca que ca marche.
le fait de repartir mieux la charge sur les cores ne soulagera pas la carte graphique.c'est juste qu'actuellement qq chose dans le code bloque ou ralenti le cpu tellement que tout le programme freeze.
si la charge tait mieux repartie tout irait mieux.
mais il n'y a pas de transfert de cahrge entre cpu et carte graphique.

soit le proc envoie trop de choses a la CG et la cg ne peut plus suivre et le jeu se met a ramer (ce qui n'est pas le cas ici) soit le cpu est trop chargé sur un de ses cores, et la cg se tourne les pouces en attendant que le cpu lui envoie des trucs a afficher. et c'est plutot le cas ici.
preuve:
j'ai testé avec une GTX285 et avec une GTX580.
entre les deux evidemment les fps ne sont pas du tout les memes. ca va du simple a plus du double pour les memes settings.
mais les blocages comme ceux qui arrivent a l'approche d'un groupe de bombardiers sont les memes.
ils sont justes plus importants avec la 285.
dans un cas je tombe a 5fps dans l'autre cas je tombe a 9fps. alors qu'il n'y a pas grand chose a afficher (en plein ciel a 3000m d'altitude avec une douzaine de bombardiers.)

[Cartman]

Non, les CPU ne sont pas du tout adaptés aux calculs graphiques.

Et si vous voulez l'avis d'un programmeur de jeux-vidéos, je me permet de le donner:
Faire un jeu optimisé sur plusieurs CPU n'est pas, mais alors pas facile du tout. On ne peut pas paralléliser toutes les opérations, c'est très complexe.

La solution qu'a choisi 1C, c'est à dire celle de mettre 1 thread pour gérer le son et un autre pour streamer les textures, en plus du thread principal, est un peu la solution simple mais aller plus loin devient difficile.

Avec chance cependant, la simulation de vol est un genre de jeu qui permet de paralléliser certaines choses. Le calcul des modèles de vol peut très bien l'être, ainsi que l'IA.(chaque avion/ia s'update en parallèle des autres). Mais si logiquement c'est évident ça ne l'est jamais en pratique. Ca reste quelque chose de très complexe à mettre en place, et il faut le faire dès le début.

Et si on prend par exemple un I7 à six cœurs avec hyperthreading, ça permet de gérer 12 coeurs. C'est bien beau, mais avant de trouver comment compartimenter de façon logique son programme en 12 sous systèmes indépendants, il peut se passer beaucoup de temps.

C'est pour ça qu'a terme on s'oriente vers un système ou le compilo analyse, avec des balises mises par le programmeur, quelle partie du programme il est possible de mettre sur un autre thread. Ca permettra de simplifier le travail mais c'est encore loin d'être disponible et fonctionnel.

[Shane]

pour le site simhq. un moyen de savori si y'a vraiment que le son qui est multithredé, c'est simple:
tu benche avec son, puis tu rebenche sans son, si le fps ne change pas d'un poil, alors c'est ue le son est bien multithreadé.
si le moteur est bien fait, en reglant tous les niveaux sonores a 0, il ne devrait plus calculer les sons allegeant donc la charge cpu.
or si le son est bien multithreadé, dansle gestionnaire de taches on ne devrait plus voir qu'n seul core utilisé au lieu d'un core plus un peu d'un 2eme core.
car le son doit pas bouffer des masses sur le 2eme core quand meme.

[Shane]

cartman, ah je suis tout a fait d'accord que c'est tres complexe a faire c'est d'ailleurs pour ca que j'ai signalé qu'avoir un ingé dédié a ce genre de tache me semble indispensable.

d'ailleurs en general dansles boites il y a le programmeur princpal qui coordonne les autres.
puis plusieurs ingés qui sont chacun spécialisés.
un pour la physique, un pour l'ia, un pour l'affichage, un pour le son, etc..
et donc il en faut aussi un pour la gestion du multithreading.

[bandini]

Pas forcément soulager la partie GPU, mais plus charger les coeurs, oui. Prenons un exemple fictif :

Tu approches d'un Box de bombardier :
Un seul coeur est chargé du calcul des DM et les FM des bomber à tour de role plus la gestion du moteur de ton spit.
Un autre coeur s'occupe du son.
Un autre coeur s'occupe de regarder ou tu te trouves, vers ou tu avance, et précharge la map en avance.

Tu as un job qui prend beaucoup plus de temps que les autres. Il de vient le goulot d'étranglement.

On pourrait imaginer (mais c'est très facile à dire, avec des si.....) que les DM et FM des différents bomber soit calculés simultanément sur plusieur coeurs.

Le problème c'est que c'est pas forcément facile de faire ce découpage du code a posteriori. En developpant un moteur "from scratch", c'est le genre de chose auquel il faut penser dès le début.
Et Rise Of Flight a montré que c'était possible de faire ça correctement.

Mais bon, on nage en pleine spéculation avec pour seul infos des propos d'Oleg.

Edit :
Grillé.
Bon, le multi tache c'est certes balèze mais :
- en developpant un moteur en 2006, c'est un peu évident qu'il faut mettre le paquet là dessus.
- c'est balèze, mais c'est quand meme leur métier.
- d'autre jeu font ça très bien, comme Rise Of Flight.

[Rototof]

désoler de remettre ca .Et la vitesse de la ram ca peut joué?

[jeanba]

oui

[raoul volfoni]

Si tu as de la DDR2 à 233Mhz, tu risques en effet de mal la sentir passer... mais si tu es en DDR3, à moins de n'avoir que de la no name en low speed, ça ne devrait pas trop jouer sur les perfs...

[Buzzz]

d'après ce qui a été testé, quand le jeu est en pause, l'affichage est très fluide. ça n'est donc clairement pas la partie graphique qui fait peiner le proc, mais tout le reste.

[DadiCool]

Bonjour,
Je ne suis pas spécialiste mais j'ai cru comprendre que ROF savait tirer partie des multicores ?
Quelle solution a été retenue ?

A+ et bon vol

[jeanba]

désoler de remettre ca .Et la vitesse de la ram ca peut joué?

Si j'en crois ma vieille expérience qui date d'un temps que les moins de 20 ans ne peuvent pas connaitre : en théorie oui, puisque plus tu as de threads, plus tu vas aller puiser souvent dans la mémoire.
Et donc, la vitesse de RAM consitue vite un goulot d'étranglement, sous réserve que :

• Tu as assez de RAM
• Tes threads sont tellement occupés qu'ils n'ont pas le temps d'aller récupérer les données dont ils ont besoin dans la RAM

Intuitivement, je dirais que quand on en sera là avec CloDo, on sera content

Edit : si je dis des bêtises, n'hésitez pas à me donner un lien sur la maladie d'Alzheimer

[phoenix]

pour le site simhq. un moyen de savori si y'a vraiment que le son qui est multithredé, c'est simple:
tu benche avec son, puis tu rebenche sans son, si le fps ne change pas d'un poil, alors c'est ue le son est bien multithreadé.
si le moteur est bien fait, en reglant tous les niveaux sonores a 0, il ne devrait plus calculer les sons allegeant donc la charge cpu.
or si le son est bien multithreadé, dansle gestionnaire de taches on ne devrait plus voir qu'n seul core utilisé au lieu d'un core plus un peu d'un 2eme core.
car le son doit pas bouffer des masses sur le 2eme core quand meme.

C'est facile Le son est géré par windows. Si vous voulez baisser le son dans Clodo, il faut faire un alt tab, et baisser le son dans le mélangeur windows. Bienvenue en 2011. Ah oui, pour la musique, c'est du on off, on la met ou on la met pas. Le menu sonore de Clodo. Relancez FB et allez voir le menu sonore. Allo Houston we have a problem. Ah, on me souffle dans l'oreillette que c'est du WIP, alors je me sens tout de suite rassuré.



Par contre, si vous avez de 2.0, 2.1, 3.1, 5.1, 7.1, vous allez en profitez. Ah oui, pour tester le son, c'est les effets windows, même pas un moteur.

[kev-47]

Si j'en crois ma vieille expérience qui date d'un temps que les moins de 20 ans ne peuvent pas connaitre : en théorie oui, puisque plus tu as de threads, plus tu vas aller puiser souvent dans la mémoire.
Et donc, la vitesse de RAM consitue vite un goulot d'étranglement, sous réserve que :

• Tu as assez de RAM
• Tes threads sont tellement occupés qu'ils n'ont pas le temps d'aller récupérer les données dont ils ont besoin dans la RAM

Intuitivement, je dirais que quand on en sera là avec CloDo, on sera content

Edit : si je dis des bêtises, n'hésitez pas à me donner un lien sur la maladie d'Alzheimer

Le contrôleur de mémoire est indépendant des cores. C'est lui qui sert à stocker, acheminer, et déplacer les octets calculés par les cores.
http://en.wikipedia.org/wiki/Memory_controller

[STEFOSTEF]

http://forum.1cpublishing.eu/showthread.php?t=19644

Dev Report for 28 March
google translator

As the western version comes out 31th of the number we have patches with the changes laid out in the evening on the 30th. The exact content of it will be announced on the evening of 30th. Likely to be more and interim patches in the evening on the 29th. The size of patches will be quite small.

What to expect on the 31st:

1. Bids farewell to anti-epileptic, while you can. The other day it will disappear forever.

2. Optimized trees. Even cleaned up the memory.

3. The problem with the freezes at a close look at the operational bombers are not yet solved, but we kind of caught her by the tail.

4. Most probably hope that as we solve the problem with the physical model are not getting a message that broken-off wings.

5. Found that fix a bug in the last minute before release, when the sound is turned off at the cabin, "flew" forward, killed the binaural. I apologize to those who told me about this, and I just could not believe. Mend, tests.

6. Corrected texts of briefings and Subtitles radio reports.(rus)

7. Dramatically improved interface server/client multiplayer.

8. Removed the 16-bit resolution for all.

Well, the programmers are reading messages on bugs and small things for something clean. But as I said, the main priority for this week - to improve performance.

[maverick6]

Ca fait plaisir, ils se bougent un peu ...

[jeanba]

Le contrôleur de mémoire est indépendant des cores. C'est lui qui sert à stocker, acheminer, et déplacer les octets calculés par les cores.
http://en.wikipedia.org/wiki/Memory_controller

Pour exécuter une tâche, le processeur a besoin d'une certaine quantité de données, si il ne les a pas, il est obligé d'attendre qu'on les lui fournisse, c'est le rôle du contrôleur de mémoire dont tu parles.