Tu as tout à fait raison ; d'ailleurs, dans l'idéal, CPU et GPU devraient être scalés de concert. Ça a toujours été le cas, mais c'est encore plus vrai maintenant que les cartes puissantes se démocratisent et ont un gros
sex-appeal commercial.
Par exemple, CU utilise DX11 et en particulier un certain nombres de nouveaux algorithmes (nouvelles APIs) qui viennent avec, qui sont très sympas, mais aussi potentiellement assez coûteux en RAM. Genre, l'OIT dont vous avez entendu parler récemment dans les newsletters. Cette montée en capacité
software n'est pas toujours suivie d'une montée en puissance
hardware (on n'est pas tous des Crésus !). Pour bien en profiter, il vaut mieux privilégier une config homogène, même si à la base DX11 c'est coté carte graphique.
En effet, pour des raisons architecturales (utilisation de listes chaînées de fragments par pixels, notamment), nombre de ces nouveaux algorithmes sont
fortement capés en mémoire à cause de leur empreinte quadratique (O(n^2) : 2x plus de pixels => 4x plus d'empreinte RAM ; 4x plus de pixels => 16x plus d'empreinte RAM). La montée en charge peut venir d'une augmentation de la résolution d'écran (en général, c'est ce qu'on fait quand on s'offre une nouvelle carte graphique :
moar pixels! ), mais aussi simplement d'une « résolution de calcul » accrue. Car qui dit nouvelle carte graphique, dit augmentation des réglages de qualités : anti-aliasing +++ / distance d'affichage +++ / résolution des meshs & textures +++, etc. En plus de ça, on attaque des jeux récents, qui utilisent tous ces nouveaux algos dispensieux. Au final, on augmente massivement la charge sur la VRAM parce qu'on veut faire plein de calculs graphiques parallélisables, et ça passe : le duo GPU/VRAM et le bus entre les deux sont conçus pour. Sauf que quand la carte est utilisée à sa pleine capacité, et ça arrive d'autant plus vite que l'intégrateur (le revendeur de GPU) a sous-dimensionné la VRAM de la carte pour afficher un prix attractif, tout l'aspect non-parallélisable qui est à traiter en CPU prend un sacré coup. Le CPU gère la boucle d'état du jeu (update de coordonées, de stats, de tout un tas de données à propos des entités rendues ou pas à l'écran, code réseau éventuel, son, etc. plus l'OS et tout le tintouin), donc s'il n'arrive pas à suivre le rythme, le jeu va se « déphaser » entre son état interne et son état visuel, avec pour résultat, soit de bons fps bruts mais un rendu imparfait voire franchement dégradé (présence d'artifacts types lag en jeu : sauts de coordonnées, apparitions fantômes ou retardées, etc.), soit des fps réduits. Dans le cas des artifacts, ils sont perçus comme des glitchs visuels, mais en fait ils n'ont pas une origine proprement GPU, ils résultent d'un problème de mise à l'échelle CPU/GPU. Dans tous le cas, le CPU va tourner à fond pour essayer de suivre le clocking GPU. Surchauffe, baisse des performances du CPU, cercle vicieux. Pour les MMOs, PvP de surcroît, ça peut être assez ennuyeux.
Je doute que CSE s'amuse à implémenter les toutes dernières optimisations mémoire coté client qu'il serait possible d'amener au-dessus des APIs standards de DX11 (du type
Adaptive Buffer et leurs variantes, pour l'OIT, par exemple) — certes, elles permettraient de casser l'emprunte mémoire quadratique et de mieux synchroniser des CPU/GPU disparates, mais ils sont déjà assez en retard comme ça… Et ça reste de l'optimisation, l'archi de fond restera la même, les problèmes de scaling qui vont avec aussi.
Donc bref, attention aux cartes graphiques puissantes montées en parallèles de CPU (+RAM dédiée) trop justes. Dans le cas particulier de CU, l'arrivée du cluster dédié aux calculs physiques pour alléger le travail des CPUs coté client devrait un peu aider, mais alors les joueurs sont d'autant plus dépendants du lag et de la vitesse réseau. Pas forcément plus « démocratique ».
En résumé : CPU et GPU (et leurs RAMs respectives) à scaler en même temps dans l'idéal.