Peut-on créer des jeux pc auto-optimisables,puisant la puissance là où elle se trouve

[kenshironeo]

Dans beaucoup de commentaires de jeux pc, on lit souvent, tel soft tire surtout sur le proc, ou bien, ce jeu utilise beaucoup la RAM, tel soft repose surtout sur la capacité de la carte graphique.
Alors je me demandais s'il ne serait pas possible de concevoir un jeu qui s'adapterait au pc de l'utilisateur.

Par exemple, jeux xxx détecte que j'ai un processeur très bon et une carte moyenne, il bascule en mode processeur et va avant tout puiser sur le processeur.
Ou inversement, il décide de puiser sur la carte graphique et de dépenser le reste de ses efforts sur la ram.

Le processus d'optimisation se fait grâce à un système faisant qu'une partie du code source change en permanence, étant pour ainsi dire mutante.

S'il existe des jeux puisant avant tout sur des processeurs, ou sur des composants spécifiques, ne peut-on pas créer un jeu qui aura la faculté de gérer les ressources matérielles de l'ordinateur comme un caméléon informatique.

Est-ce rigoureusement possible ou faisable de faire en sorte qu'un composant puisse systématiquement en rattraper un autre, en quelque sorte de donner au hardware un "esprit d'équipe" techniquement parlant, un jeu disposant d'un outil autonome d'optimisation des performances globales, avec un programme dans le programme.

Par exemple on dit que Dragon age tourne surtout sur le processeur, et Rage sur la ram, dans ces cas-là, on pourrait changer cet état de fait ,dire au programme "non,sers toi davantage de la GPU".

J'espère avoir exprimé assez clairement mon idée, en gros, si l'on devait concevoir le pc comme une paire de jambes, faire en sorte qu'en fonction des circonstances on puisse s'appuyer plus sur la jambe gauche que la jambe droite ou inversement.

[tim987]

Ça commence comme ça, et on finit avec Skynet et des terminators qui exterminent la race humaine.

[GdabZ]

On ne marche pas avec ses oreilles, on n'entend pas avec sa bite.

Un GPU n'est pas structuré comme un CPU.

[Jano_Lapin]

On ne marche pas avec ses oreilles, on n'entend pas avec sa bite.

[freddy021]

On ne marche pas avec ses oreilles, on n'entend pas avec sa bite.

Ton post peut laisser imaginer que tu marches avec ta bite...ça laisse songeur...

[neurosol]

Il demande seulement à savoir si le GPU pourrait se transformer en "canne" si besoin.
Les Sandy bridges aident bien le GPU, eux. Pourquoi pas l' inverse ?

[Frypolar]

Il demande seulement à savoir si le GPU pourrait se transformer en "canne" si besoin.
Les Sandy bridges aident bien le GPU, eux. Pourquoi pas l' inverse ?

Absolument pas. Les Sandy Bridge, et ce ne sont pas les seuls processeurs dans ce cas, embarquent un GPU en plus du CPU (au passage on parle d’APU). Cette partie GPU n’aide pas la carte graphique si on en possède une, c’est l’un ou l’autre, pas les deux en même temps. Un CPU et un GPU ont des architectures différentes qui sont plus ou moins adaptés aux différents types de calcul qu’effectue un ordinateur. Suivant ce qu’il faut calculer, tu sollicites le CPU ou le GPU. Si tu prends le mauvais tu perds un temps fou. Un CPU n’aide pas un GPU, il fait juste sa part de calcul, dans le domaine où il excelle. Et la RAM n’a strictement rien à voir, son rôle est très différent donc on en revient au message de GdabZ.

Le processeur qui se tape les calculs normalement effectués par la carte graphique c’est ce qui se fait sur console car la partie GPU est minable. C’est faisable car il y a un seul modèle de processeur et un seul modèle de carte graphique.

[MrPapillon]

Un jeu ne se reprogrammera jamais ou alors seulement sur quelque chose de très simple et de prévu (certains très vieux jeux le faisaient, mais ça sert plus à rien maintenant). Sinon le code ne se modifiera jamais aléatoirement pour s'améliorer tout seul, ça existe au niveau de la recherche en IA mais c'est très très coûteux en temps de calcul et c'est dans des environnements prévus pour. Et pour un résultat vraiment minimaliste. Mais y a pas besoin de cet extrême, il n'y a aucun intérêt à "recoder" automatiquement le jeu, on a pas de contraintes qui nous obligerait à ça, il suffit juste d'ajuster les ratios et la config à la volée, c'est pas très compliqué sur l'idée de base. Ce qui est compliqué c'est surtout qu'en général beaucoup de jeux ne sont pas prévus (manque de temps) pour pouvoir s'adapter facilement à tout. Le moteur de Rage et certains autres moteurs essayent petit à petit de proposer du code qui peut très bien s'exécuter sur 1 ou 50 cores sur un CPU ou qui adapte leur contenu aux tailles de la mémoire. Ça sera encore plus simple si on passe à des archis unifiées dans le futur (plus de GPU, mais un CPU avec beaucoup beaucoup de cores).

Pour l'instant on peut coder certaines parties du code pour que ça tourne sur du GPU (compression de texture sur Rage par exemple qui est déporté en fonction des besoins du CPU au GPU). Mais comme le langage est différent, il faut que ça soit précodé. Après on peut partir dans de la sf en se disant que le jeu pourrait s'exécuter dans une machine virtuelle comme Java et que tout ce petit machin pourrait se déplacer sur n'importe quel matos (cpu, gpu) tant qu'il dispose d'une implémentation de cette machine virtuelle (un peu comme ce que fait java entre les os et les machines). Le problème c'est que ce n'est pas à l'ordre du jour, un jeu exigeant demande un max de perfs. Par contre des structures comme OnLive peuvent y trouver un intérêt sur le long terme. En regardant encore plus loin, on peut se demander si on ne peut pas créer du hardware spécifique pour se charger de l'émulation ou voire pire, du hardware qui interprète directement cette machine virtuelle (cf http://en.wikipedia.org/wiki/PicoJava pour le Java).

Sinon le problème pour un jeu vidéo est assez simple :
- On ne veut pas forcément perdre le contrôle sur la qualité que l'on affiche, que ce soit le joueur ou le développeur. Le joueur préfère plutôt cet effet que celui-là au détriment de celui-là. Certains joueurs veulent voir la qualité max au détriment des fps et d'autres non.
- Ça complique le travail des devs de manière exponentielle sur toute la durée du projet et ça n'apporte pas grand chose de clairement utile. Un code qui est moins prévisible et complexe entraîne soit plus de bugs à l'arrivée soit une phase de tests encore plus longue.

[MetalDestroyer]

Blablabla optimisation.

En l'état, un jeu ne peux se reposer uniquement sur le CPU ou la RAM. J'espère que tu parles bien de la partie graphique. Le CPU est encore loin d'être suffisamment puissant pour te générer un rendu top moumoute avec un framerate décent à moins que tu préfères un jeu sans moteur physique, sans IA, sans presque rien en fait.
La RAM ne permet pas d'améliorer sensiblement le rendu. Pour le cas de RAGE, sa bande passante élevée et le fait d'avoir une quantité non négligeable aide à faire afficher des textures de meilleurs qualités pour le MegaTexture. Mais bon, le problème c'est que RAGE charge/décharge sans cesse les textures de la RAM, hors tes textures elles proviennent de ton disque dur. Et là, le seul moyen d'avoir un rendu optimal sans ces popups de textures c'est d'installer le jeu sur un disque SSD.

[kenshironeo]

Le GPU et le CPU ne calcule donc pas forcément les mêmes choses.Je partais du principe que certains aspects du jeu pouvaient être indifféremment calculés par l'un ou l'autre des composants.
L'idée d'un CPu unifié serait bien sympa, mais pour y parvenir il faudrait idéalement que la compagnie qui le fabrique ait une expérience dans les gpu et les cpu.(donc par exemple le mieux serait qu'intel et nivida ne fassent q'un?)

Si les sandy bridge par exmeple ont une gpu intégrée ça peut-être vu comme un premier pas dans ce sens?(même si insuffisant pour des résulatst optimaux)

[Leucha]

Ca change rien, CPU unifié, ca ne veux pas dire grand chose. CPU et GPU, c'est comme moteur diesel et moteur essence. Grosso merdo, le GPU peut faire des calculs à la volée sur des éléments unitaires et isolé (un pixel par exemple) alors qu'un CPU peux combiné plusieurs éléments qui n'ont rien à voir entre eux (bon, j'explique mal, et j'ai un peu paumé mes connaissances en GPU/CPU, si quelqu'un peu me corriger ?). Tu vois qu'ainsi, ca ne peut fonctionner que dans le sens GPU>CPU, mais ce dernier est moins bien construit pour effectuer les calculs demandé à un GPU et sera plus lent.

[MetalDestroyer]

Nan, mais le CPU peut faire du rendu similaire à ton GPU, sauf qu'il n'est pas fait pour car bien trop lent.

[Frypolar]

L'idée d'un CPu unifié serait bien sympa, mais pour y parvenir il faudrait idéalement que la compagnie qui le fabrique ait une expérience dans les gpu et les cpu.(donc par exemple le mieux serait qu'intel et nivida ne fassent q'un?)

Si les sandy bridge par exmeple ont une gpu intégrée ça peut-être vu comme un premier pas dans ce sens?(même si insuffisant pour des résulatst optimaux)

Quel est l’intérêt de tout unifier ? Dans le cas d’un petit GPU c’est une question de coût de fabrication et surtout de flinguer la concurrence (nVidia) puisque tu imposes ton GPU avec ton processeur. Pour le haut de gamme et bien tu ne peux pas coupler une carte graphique digne de ce nom avec un processeur récent. Suffit de regarder une carte graphique récente : t’as un PCB qui doit faire le tiers d’une carte mère et un GPU qui dégage tellement de chaleur qu’on peine à le refroidir efficacement. De plus c’est sur le marché des GPU bas de gamme que les fabricants réalisent le gros de leur chiffre c’est donc sur ce secteur qu’ils doivent concentrer leurs efforts, pas sur les cartes graphiques de joueur.

Nan, mais le CPU peut faire du rendu similaire à ton GPU, sauf qu'il n'est pas fait pour car bien trop lent.

C’est pas une question de puissance ou de lenteur mais d’architecture. Un CPU n’est pas construit de la même façon qu’un GPU car on ne lui demande pas la même chose. C’est comme comparé une formule 1 à une voiture de rallye, ce n’est absolument pas pertinent puisque ces deux types de voitures sont construits dans des buts différents.

[znokiss]

Après la précommande cautionne-t-elle le sabotage des jeux ?, Des jeux et des idées, qu'ont-ils à nous dire ? et L'élitisme dans le jeu vidéo: vanitas vanitatum? ; bienvenue dans le nouveau topic philo-interrogatif de la semaine présenté par kenshironeo.

[Raoul Wolfoni]

On ne marche pas avec ses oreilles, on n'entend pas avec sa bite.

Un GPU n'est pas structuré comme un CPU.

J'ai trouvé ma signature si tu permets...

[gripoil]

Après la précommande cautionne-t-elle le sabotage des jeux ?, Des jeux et des idées, qu'ont-ils à nous dire ? et L'élitisme dans le jeu vidéo: vanitas vanitatum? ; bienvenue dans le nouveau topic philo-interrogatif de la semaine présenté par kenshironeo.

Et si on faisait un sous forum pour ces questions ? Comme ça j'y mettrais pas les pieds
Je pense qu'on devrait retourner au rendu software on s'ferait moins chier avec tout ce matos ...

[Monsieur Odd]

Après la précommande cautionne-t-elle le sabotage des jeux ?, Des jeux et des idées, qu'ont-ils à nous dire ? et L'élitisme dans le jeu vidéo: vanitas vanitatum? ; bienvenue dans le nouveau topic philo-interrogatif de la semaine présenté par kenshironeo.

J'aurais du me douter d'un truc.
Je propose BHL comme sous-titre.

[doshu]

J'aurais du me douter d'un truc.
Je propose BHLBHV comme sous-titre.

A question sans réponse, sous-titre sans solution

[Monsieur Odd]

Faut être belge pour comprendre, j'ai compris, mais habitant à Paris j'ai quand même d'abord tilté sur "Bazar de l'hotel de ville".

[doshu]

^^

L'absence d'indice était volontaire . Bien trouvé

[Lazyjoe]

Placement automatique de code sur une architecture hybride cpu multicore/gpu ? Mais c'est le sujet de ma thèse ça !

Et crois-moi c'est pas près de se généraliser avant un bon moment (faudrait déjà qu'on réussisse à avoir un truc qui marche xD ).

Un GPU en fait c'est un ensemble de processeurs simples qui exécutent tous en même temps le même calcul pas trop complexe. Du coup ça marche bien pour des calculs réguliers et indépendants du genre appliquer une transformation géométrique à des milliers de triangles ou un calcul de couleur à des millions de pixels. Dans "marche bien" il faut comprendre "100 fois plus vite qu'un CPU dans les meilleurs cas".

Donc généralement on fait les calculs qui marchent bien sur GPU dessus, et les calculs qui marchent bien sur CPU sur ce dernier, et dans l'ensemble ça fonctionne bien. A terme on va vers une forme d'unification (les GPU deviennent de plus en plus généralistes et permissifs, exemple dans la dernière archi nvidia on peut exécuter plusieurs threads différents en même temps sur différentes parties de la carte; et les CPU vont aller de plus en plus vers un style "multicore massif"), mais les deux architectures vont garder leurs caractéristiques principales encore un bon moment.

[znokiss]

Tu casse tout avec ton post sérieux, Lazyjoe. Là, on arrivait presque aux gifs de loutres qui clignotent.

[Lazyjoe]

C'est la faute à kayl ça

http://forum.canardpc.com/threads/62...fs-anim%C3%A9s

[[gik]]

Je pense qu'il est confusionné à cause du Tesla de nVidia.
Un CPU c'est bon à tout faire mais comme un pied (m'enfin heureusement il y a plein d’instructions) alors qu'un GPU ça fait peu mais bien (syndrome d'asperger un peu).

Grossièrement: faut voir la carte graphique comme un ordinateur massivement parallèle mauvais pour le calcul en virgule flottante mais efficace pour certaines simulations où la précision n'est pas cruciale (d'où physx). Quand on a besoin d'un troupeau de petits threads, on peut utiliser le gpu (décodage/encodage vidéo, rendu 3d, cryptographie).

Pour être plus précis, des warps qui contiennent les threads (threads qui doivent tous exécuter les mêmes instructions).
Si on désactive des threads, on ne peut pas les remplacer, c'est un warp avec plus de threads actifs qui prend le relais.
Il y a aussi plein de contraintes liées principalement à la bande passante (donc aux latences) et au groupement de requêtes. Même si les dernières cartes nVidia sont plus souples, c'est pas simple, faut optimiser.

Bref: Non, CPU et GPU ne sont pas interchangeables pour les jeux vidéos.
Techniquement on peut faire du rendu logiciel, genre le bench' CPU des anciens 3dMark mais c'est d'une lenteur...
Ou en sens inverse, avec les nouveaux logiciels de rendu 3D qui utlisent CUDA au lieu du CPU (c'est pas les même algos et ça tend à être moins photo-réaliste).
Puis quand c'est possible, ça reviens à porter du code sur une autre plateforme.
Il faut pas compter sur les devs de jeux vidéos pour optimiser ce genre de trucs sur un chie-lliard de configurations matérielles possibles. C'est déjà bien trop complexe.
Par-contre dans les milieux scientifiques et les calculateurs haute performances ça se fait.

On peut imaginer que du clustering (mutualisation de plusieurs ordinateurs) serait une solution viable et peu couteuse pour le jeux vidéo.
En utilisant le PCI-Express comme interface (pour pas trop chier sur les latences).
Hélas, on préfère acheter des tablettes et autres gadgets plutôt que des laptops en ce moment.
Sans compter qu'il faudrait un OS capable de le faire et les acteurs du marché pour pousser.
Donc ça ne risque pas d'arriver.

Dans la même veine: Pourrait-on faire fonctionner Crysis sur un ordinateur quantique? Oui et non à la fois! Sinon 42.

[MrPapillon]

Comme j'avais dit plus haut, il y a quand même une porte de sortie avec OnLive et OTOY qui eux peuvent faire autant d'expérimentations que chez les universitaires puisque tout s'exécute chez eux, du cloud. Par contre eux sont plus dans la problématique de faire passer un jeu de 1 cpu à 50 que d'un cpu à un gpu.

[[gik]]

Du cloud? C'est juste du jargon flamby pour décideurs préssés (comme leveraging et outsourcing, c'est juste bon pour le business loto)

Ce truc ressemble au minitel, enfin aux mainframes des années 70 et le SaaS ce n'est valable que pour les entreprises.
Tu n'as qu'une simple machine à disposition sur un serveur, avec un logiciel de contrôle à distance sophistiqué.
Je me sentirais enfermé. Plus de contrôle sur ses données et plus du tout de mods (j'évoque ni le ping, ni l'abonnement).

Moi je parle de grappe de calcul avec son propre matos. Mais n'incluant pas seulement CPU, ram et stockages mais en plus... les GPU (ça s’éloigne pas trop du SLI).
Windows HPC ne sait pas faire ce genre de trucs.

Il y aurait plusieurs façons de faire (c'est juste pour l'inspiration):
- Soit le top du must, un système d'exploitation distribué (à la Plan9), irréalisable.
- Soit un maitre et des nœuds (façon Linux sous Kerrighed, OpenMPI ou le défunt OpenMosix).
- Soit avec des agents en espace utilisateur (comme certains logiciels de rendu 3D, ou BOINC) pourquoi pas inclus dans les pilotes de GPU. Pratique mais trop lent.

Le hic? Je pense que c'est techniquement de l'ordre du possible mais ce doit être horriblement complexe à faire: Genre implémenter un ordonnanceur potable et du qos de derrière les fagots afin de repartir les tâches sur toutes les unités, que les machines restent utilisables mais mutualisées. J'aurais bien vu un sale hack basé sur l'hyperviseur Xen (je pense au PCI passthrough) pour peu qu'on ai le CPU qui va bien. Point de détail: normalement avec du PCI-e >8x, ça pose pas trop de soucis pour repartir la charge. Plus besoin d'Infiniband et tout.

[Lazyjoe]

Houlà ça devient sérieux et technique ici.
Des clouds genre OnLive à mon avis il se cassent pas trop la tête, ils vont juste utiliser leur cluster en mode farm, en réservant X puissance de calcul donnée pour chaque utilisateur. Et ils ne vont certainement pas attribuer des dizaines de processeurs pour une seul client, donc la parallélisation du code est moins problématique.

[[gik]]

D'après wikipedia, OnLive, c'est plutôt un CPU+GPU par utilisateurs pour les jeux qui sont exigeants, sinon c'est juste de l’hébergement mutualisé classique avec plusieurs comptes par machines.
Les techos de streaming vidéo hardware sont brevetées. C'est vraiment du StreamMyGame au fond mais sans l'auto-hébergement.

Gaikai et OTOY ce doit pas être bien différent, sauf pour ce dernier qui offre en plus d'autre services à la façon d'Amazon EC2: entre autres un accès à leur cluster pour faire du rendu 3D.

Si c'est juste pour du rendu, LuxRender (ou tout autre chose qui gère le calcul distribué), un VPN et un chan IRC. Voilou, une communauté pour faire une ferme de calcul (seul les résultats sont uploadés sur le maitre qui se charge d'assembler l'image). Mais on s’éloigne encore un peu plus du sujet.

Sinon je suis tombé sur un papier intéressant: une technique appelée rendu amorti: on calcule par avance tout ce qui ne dépend pas de la localisation des joueurs sur un cluster. Pas mal pour les grosses lan et les mmo. Encore faut-il que les jeux soient conçus de la sorte

[MrPapillon]

Oui pour l'instant le cloud version OnLive c'est pas encore du calcul réparti, les jeux sont pas prévus pour et ça m'étonnerait qu'ils se cassent la tête à faire une virtualisation aussi poussée derrière. Par contre rien n'empêche un jeu d'être prévu pour qu'il soit facilement scalable sur du multi-procs. Et ce que propose OTOY pour le coup c'est de passer au raytracing ce qui permet au client de calculer un max de rayons et le cloud se charge de compléter les infos de diffusion de la lumière petit à petit. Donc le temps de latence est moins important surtout qu'on commence à voir des algos pour éviter que le rendu de la radiosité soit de la bouillie de pixels même loin de la convergence. Après tout ça c'est pas près de se généraliser, mais il suffit de quelques jeux démo technique style indies simples pour donner de la viabilité au truc.

Après on peut voir aussi l'intérêt de pouvoir utiliser du multi-proc, c'est de pouvoir récupérer de vieux procs peu chers qu'on underclock et en aligner en masse à la place d'avoir à acheter des procs récents coûteux et à la limite de la surchauffe pour que ça tourne sur les jeux récents. Un cpu underclocké ça doit avoir une sacrée durée de vie. En tout cas rien ne les empêche de changer leur fonctionnement du jour au lendemain sans que ça ait de conséquence sur les utilisateurs.