[Korgall]

Tout droit sortis de Reddit :

Citation :

This is something we'll be working on until release. You'll see improvements with each beta weekend.
The cold hard technical speak is: we need to fix the main CPU thread getting stalled on occlusion queries to the GPU; we need to fix driver compatibility issues; we'll continue offloading work to other threads.
~ MO

Quelqu'un pour expliquer en détail ?

[Korgall]

D'après ce que j'ai compris, le jeu aurait du mal à gérer l'affichage d'un grand nombre de joueur sachant que celui-ci est actuellement limité (clipping):

Citation :

Requête d'occlusion

Le tampon de profondeur permet de tester si un objet est visible. En l'interrogeant, on peut connaître le nombre de fragments qui passent le test de profondeur.
C'est utile, par exemple, pour éviter de restituer un objet complexe si la requête d'occlusion de sa boîte englobante retourne qu'aucun fragment n'est visible.
La requête et sont traitement s'opérent en 6 étapes :
- Générer un identifiant de requête, à l'aide de glGenQueries().
- Indiquer le début de la requête avec glBeginQuery(GL_SAMPLES_PASSED, ...).
- Restituer la géométrie à tester
- Indiquer la fin de la requête avec glEndQuery(GL_SAMPLES_PASSED).
- Demander le nombre de fragments visibles avec glGetQueryObject[u]iv().
- Libérer les ressources liées aux requêtes, avec glDeleteQueries().

Source

[Inambour]

Mdr c'est imbuvable ta source pour les novices.

L'Occlusion Query c'est le fait d’éliminer du rendu d'une image les polygones ou les objets cachés par d'autres et donc invisible pour le joueur/à l'écran. Ça fait foutrement gagner en perf en aval du calcul mais parfois ça en bouffe beaucoup pour calculer la chose, le tout étant de trouver un juste milieu et d'opti à fond.
Exemple : des brins d'herbes qui se chevauchent, des cailloux, des objets en mouvements qui éclipsent un autre (pensez éclipse de soleil pour avoir une idée précise dans le temps, sinon je développerais plus).

Ce rendu est effectué par le hardware et via le Direct X (9 sur GW2), l'Open GL.
Le truc c'est que là au lieu de bien partager le boulot entre toute les "pièces" hardware il semble que tout soit filé au CPU l'asphyxiant à terme et rendant le GPU un peu obsolète.

Le reste parle d'opti driver, ça je pense que c'est normal et dans la continuité.

[Korgall]

Je suis un novice

Donc en gros, le problème viendrait donc de leur moteur qui ne gère pas les requêtes entre CPU et GPU suffisamment rapidement ? Ils disent bien que le CPU "calle" donc en gros serait ralenti car le GPU serait pas assez rapide à lui envoyer la réponse sur oui ou non il doit afficher un élément à l'écran ? Ou alors c'est l'inverse ?

Une confirmation sur l'offload sur les autres coeurs :

Citation :

We've spent some time on performance improvements and will move more of the team on to performance as time goes on. Specifically, we've moved some of our processing that was done on our main thread on to other threads.
-Peter

[Kazek37300]

Ca sent le moteur moisis, qui sera optimisé à la SWTOR ou pour afficher 4 pov mob devant toi, faudra exagérer sur le clipping, et avoir un config monstrueuse pour compenser le moteur...

[Inambour]

Citation :

Publié par Kazek37300

Ca sent le moteur moisis, qui sera optimisé à la SWTOR ou pour afficher 4 pov mob devant toi, faudra exagérer sur le clipping, et avoir un config monstrueuse pour compenser le moteur...

J'avoue que j'ai pensé direct au clipping et par extension à tout les mmo à open rvr foireux qui ont utilisé ce système (Rift, SWTOR pour ne citer qu'eux).

Citation :

Publié par Korgall

Je suis un novice

Donc en gros, le problème viendrait donc de leur moteur qui ne gère pas les requêtes entre CPU et GPU suffisamment rapidement ? Ils disent bien que le CPU "calle" donc en gros serait ralenti car le GPU serait pas assez rapide à lui envoyer la réponse sur oui ou non il doit afficher un élément à l'écran ? Ou alors c'est l'inverse ?

Une confirmation sur l'offload sur les autres coeurs :

Moi aussi j'suis un novice (je hais le dev' !!) je connais par contre la définition de souvenirs des cours de dev en bts.

Sauf erreur to stall en anglais veut dire "annuler, empêcher, bloquer" et donc sa phrase voudrait dire que le cpu bloque le transfert d'HOC (hardware occlusion queries son vrai nom). J'ai bon ? La tournure de sa phrase est pas facile à comprendre, limite tu peux effectivement saisir le contraire, j'veux bien un peu d'aide pour la traduction aussi >.<.

[sankaman]

Salut, en gros on ne peut rien y faire faut attendre que les devs trouve une soluce.
J'ai bien résumé?
Perso je n'y connais rien non plus ^^

[Jurian]

Citation :

Publié par Kazek37300

Ca sent le moteur moisis, qui sera optimisé à la SWTOR ou pour afficher 4 pov mob devant toi, faudra exagérer sur le clipping, et avoir un config monstrueuse pour compenser le moteur...

Ouai enfin, on est déjà loin de çà, même sans optimisation !
J'affiche déjà 60 personnes sans trop de lag, là où sur SWTOR je jouais en mod diapo dès que j'avais plus de 20 personnes.

[Korgall]

Citation :

Publié par Inambour

Sauf erreur to stall en anglais veut dire "annuler, empêcher, bloquer" et donc sa phrase voudrait dire que le cpu bloque le transfert d'HOC (hardware occlusion queries son vrai nom). J'ai bon ? La tournure de sa phrase est pas facile à comprendre, limite tu peux effectivement saisir le contraire, j'veux bien un peu d'aide pour la traduction aussi >.<.

D'après wikipedia : stalling in pipeline computing introduces a delay before the processor can resume execution.

Une autre définition si ça peut aidé : Hardware Occlusion Queries (HOQ) have many uses. A HOQ is the process of determining whether one or more rendered objects are visible on a per-pixel level (one or more occluder convex or concave can occlude it).

En provenance de guru :

Citation :

I just researched it a bit more. It looks like he wasnt talking about occlusion as a principle, but specifically the occlusion query function in DirectX 9 and above. The CPU does tell the GPU what to draw and then goes about its business, but in the case of that function, the CPU says "draw this" and then waits for the GPU to respond back with the number of pixels it has rendered. Thats where the blockage is coming from. Optimization to reduce the lag between the processor giving a render command and then querying for the pixels created to render the thing. I would assume it needs the pixels for bounding to correctly handle things like pathing and collision.

It's about efficiency. That choke-point could be a problem on slower processors. Odds are its wouldn't be normally noticeable unless the processor was doing a ton of other stuff at the same time. Thats where the threading comes into play. Let's say your processor is crunching a bunch of numbers in a WvW siege and then does an occlusion query, your frame-rate may hiccup. But if those calculations are being done in one thread, and the occlusion query is going on its own thread, hen they don't get in each others way. Its like lanes in a highway.

These changes bode well for budget PCs. Clearing the pipes of communication between processor and graphics card and offloading expensive operations to their own threads will make things run smoother. Lower end systems benefit more since they have limited resources, so improvements like this might be more noticeable to people with low end rigs than higher end rigs.

En gros, le CPU enverrait des demandes d'occlusion (je dois l'afficher ou pas ce joueur ?) et le GPU mettrait trop de temps à répondre. Du coup, au lieu de pouvoir être chose en attendant, le CPU doit attendre que le GPU réponde et on perd donc en perf.
Le fait qu'ils n'aient pas encore réussi à avoir des drivers abouti pour la carte graphique et qu'il est difficile d'offload des calculs sur d'autres threads aggrave ce problème.

Pour revenir sur le Clipping même si c'est un peu hors sujet : il y en a sur WAR ? D'après ce que j'ai compris, en plus de jouer côté client, le clipping est surtout là pour soulager le serveur de jeu et empêcher le lag que l'on peut observer sur WAR à plus de 150 joueurs regroupé dans un fort (observé hier soir).

[Inambour]

Ah en effet, vu comme ça c'est plus clair ! :>

WAR y avait du clipping mais comparé à celui de Rift et SWTOR c'était du pipi de chat, du genre au dela de 100+ joueurs alors que sur les deux autres au dessus de 30 (et encore) tu découvrais des potes à tes côtés à chaque pas en avant...

[Rammi]

Citation :

Publié par Inambour

Sauf erreur to stall en anglais veut dire "annuler, empêcher, bloquer" et donc sa phrase voudrait dire que le cpu bloque le transfert d'HOC (hardware occlusion queries son vrai nom). J'ai bon ? La tournure de sa phrase est pas facile à comprendre, limite tu peux effectivement saisir le contraire, j'veux bien un peu d'aide pour la traduction aussi >.<.

Perso je comprend, en paraphrasant, que la gestion des requetes d'occlusion addressées du CPU au GPU ont un impact négatif sur le processus principal du CPU (en gros ça le fout à la bourre sur tout le reste).

[Aapef]

La bonne solution est celle qui avait été appliquée sur Aion : ne laisser afficher que les noms lors du GvG massif

Surtout que sur GW2, il n'y aura pas les noms, ce sera donc encore mieux

[Razorbac]

si c'est pour faire comme aion et leurs solution a la con. Taper des noms, autant lancer comme sort des gommes

[Beroq]

Citation :

Publié par Razorbac

si c'est pour faire comme aion et leurs solution a la con. Taper des noms, autant lancer comme sort des gommes

Petite préférence pour un build blanco.

[Rammi]

Ouais bin va falloir bosser un peu Anet






Gpu à 25 % de charge, même pas en fréquence 3D
Bien sur, c'est pas fluide

[Sebajuste]

Etant développeur, (et ayant développer de petits moteurs 3D il y a plusieurs années), je peux affirmer que les choses sont encore un peu plus compliqué ^^


Le problème des performances est global, et ne touche pas que le coté purement "affichage".

Par exemple, le flux réseau. Chaque client ne reçoit que la position des joueurs les plus proche de façon à limiter le nombre de données et de synchronisation avec le serveur. Et parmi cette liste, seule une partie sera affiché à l'écran.

Même si la partie graphique est souvent la partie la plus gourmande, les ralentissements ne sont pas forcément du qu'à l'affichage. Je me souviens il y a 5 ans, d'avoir doublé mes FPS en changeant de processeur, et en gardant ma carte graphique.



Quand à la source, elle date ^^ Ces fonctions OpenGL sont totalement obsolètes. Les shaders on depuis 10 ans complètement remplacer ce genre de fonctionnalités.

D'ailleurs, les allés / retour entre le GPU et le CPU étaient en effet trop contraignant, et les optimisations ont toujours visés... à s'en passer quand nécessaire.

Si "test" il doit y avoir, ceux-ci sont désormais réalisés par les shaders (donc par le GPU) et il n'y a plus (ou très peu) de retour vers le CPU.

Qu'est ce qu'un shader ? Pour faire simple, ce sont des programmes qui sont envoyer à la carte graphique pour réaliser des traitement. En deux mots: on programme la carte graphique.

Ma main au feu qu'ils ont des shaders spécifique pour l'occlusion (Même si personnellement j'aurais eu tendance à penser que des boites englobante traités par CPU eu été plus rapide... N'étant pas professionnel dans le domaine de la 3D, je leur fait confiance).


Et pour gagner encore du temps de transfert CPU / GPU, les textures et les modèles 3D sont envoyé à l'initialisation dans la VRAM, et ne sont donc plus en RAM.
A ce niveau, les quelques transfert restant sont nécéssaire pour les modèles animés, dont il est nécessaire de mettre à jour à chaque mouvement.



Et de toute façon, il arrive à un moment, où le moteur ne peux plus être optimisé (ou quasiment plus). Et ce stade est souvent atteints dans tous les jeux vidéos. Alors comment certains jeux arrivent à améliorer encore les choses ?

Le réponse tiens en trois lettre : le LOD (Level of Detail).

Et là, ce sont les graphiste qui prenne le relais. Il s'agit de dessiner le même modèle 3D, la même texture, en plusieurs fois, à différentes "résolution". Et le modèle effectivement dessiné sera choisi en fonction de sa distance avec la caméra.

Là plupart des jeux se contentent de 3 à 4 niveau de LOD (enfin... je suis pas sur...). Bon peu importe en fait ^^ Si on a du temps et de l'argent, une boite de dev peut très bien augmenter ce nombre pour rapidement perdre en détail dès qu'un objet s'éloigne de la caméra, tout en permettant une transition douce entre les modèle.

Dans GW 1, c'était très visible avec les modèle "fixe" (maison, arbre, rocher...) éloignés. Ils étaient tout simplement en 2D ! et remplacés par leur modèle 3D dès qu'on s'approcher.

Entre afficher 50 carrés en 2D, et 50 modèles 3D texturés, il n'y a pas photo sur les performance.


On peux très certainement aussi géré le LOD, pas uniquement en fonction de la distance, mais en fonction du nombre. Ex: si il y a 10 joueurs, leu jeu peut se permettre de tous les mettre en haute définition. Si il y en a 150, ils seront tous les basse définition, même les plus proche.


N'étant pas un professionnel du jeu vidéo, j'espère ne pas avoir dis de bêtise ^^ Mais je suis sur qu'Anet a déjà exploré toutes les pistes.

Reste alors à paramétrer "le moteur". A partir de quand afficher tel model ? Il n'y a pas de secret, il faut beaucoup de test, et de temps.


( Pour ma part, sur un i7 3.4Ghz, 8Go RAM, GTX 275 j'ai pas eu de ralentissement avec sur plus de 50 joueurs en WwW)

[Korgall]

Si "il n'y a plus (ou très peu) de retour vers le CPU", comment expliquer leur phrase ?

De plus, on a 2 choses séparées : l'optimisation du moteur qui provoque une sur-utilisation du CPU et le clipping qui est côté serveur et non côté client (même si ça aggravera encore la sur-utilisation du CPU quand ils arriveront à l'augmenter).

Le LOD est déjà présent dans le jeu avec l'affichage des textures lointaines en low res mais je ne l'ai pas remarqué sur des joueurs.

[~Sorcha]

J'avais vu le message sur reddit et je m'étais déjà posé des questions sur le clipping. Le moteur de GW1 & 2 diminue le nombre de polygones par modèle animé en fonction de la distance, pourquoi ne pas remplacer les ennemis très éloignés par des sprites 2d.
C'est moche mais plus fonctionnel que l'apparition soudaine d'un bus.

[gutgut]

J’apporte ma pierre a l'édifice comme on dit. La non optimisation du donjon.

Config: I7 940 3 Ghz
N295GTX (MSI) avec les fréquences d'usine

Au niveau drivers, j'ai essayé avec les deux derniers certifiés en date, pas eu le courage de remonter sur des drivers encore plus ancien.

Même en WvW de masse j'avais pas des baisses de fps aussi drastiques, il m’arrivait de tomber à 20 fps mais pas en dessous. Dans le donjon, à partir de la fin du premier coffre c'est l'orgie graphique. Il m'arrivait de tomber en dessous des 10 FPS, le tout en gardant une consommation système stable.

C'est beau de vouloir optimiser, encore faut il utiliser les ressources disponibles x)

[GoodGame]

[Mode Gros troll des cavernes On]

En fait on vous l'a pas dit mais GW2 Wvw c'est du tour par tour !!!!

[Mode Gros troll des cavernes Off]

sans dec' je ne voudrais faire que du wvw mais quand je vois des yoyos 10-60 j'ai très peur.
en pve 0 soucis mais bien souvent en wvw le ventilo de ma cv restait au min... bouhhh
si ils n'ont pas réglé le soucis à la sortie je vais me faire un 1-80 en pve sur 5 persos en attendant mieux bouhhh

[Melila]

J'avais raté ce thread en juin, j'ai appris pas mal de choses sur le clipping qui m'inquiète un peu...

J'espère qu'ils pourront améliorer ce point-ci, car voir apparaitre soudain un bus à 3-4m ca fait drole