Grâce à un moteur graphique très propre, 3DMark 11 représente une rare opportunité d'observer les différentes étapes nécessaires à la construction d'un rendu 3D temps-réel moderne tel qu'utilisé dans les jeux vidéo récents…
Lire la suite ...

Damien, vraiment cool comme dossier, tu a utilisé quel soft pour être capable de découper le rendu en étape comme ça??

J'ai utilisé GPU Perf Studio d'AMD et Parallel Nsight de Nvidia qui permettent d'observer les draw calls un par un.

Très bon dossier, beaucoup de joueur (ou autre) devraient le lire afin de mieux comprendre ce qui se passe dans leur machine et notamment la différence que la puissance machine peut provoquer.

ça sent bien les limites du raster quand même

D'ailleurs, ça serait-y voué à être complété par un bon vieux ATi vs nVidia, puis un GCN vs Cayman?
 
C'est assez intéressant dans l'absolu, mais ce comparo permettrait justement d'avoir une analyse plus poussée des perfs de chaque famille de GPU.
 
Bon, après il faut encore que les outils renvoient des infos comparables, pas comme les debuggers CPU
 
Au passage, gros pluzun à Barbare128... y'a un peu trop de raytracing pour du rasterizing

Oui c'est voué à être complété avec une comparaison AMD/NV, avec quelques critiques, mais avant cela il était intéressant de profiter des données obtenues pour un dossier plus générique sur le fonctionnement du rendu 3D.
 
Concernant la comparaison, les chiffres ne sont qu'à peu près comparables, le coût de l'instrumentation n'étant pas identique. Tout cela prend énormément de temps, surtout du côté des GPU Nvidia avec lesquels il faut croiser les données de deux outils pour obtenir des chiffres pertinents. 5 scènes, 3 modes graphiques, plusieurs GPU, ce n'est pas  simple, on ne pourra observer que quelques cas.

Je suis soufflé par la technique employée pour l'antialiasing. Simplement très astucieux, mais j'ose pas voir la tête des mecs qui ont pondu l'algo, rien que d'y penser ça donne le vertige.

Superbe article, comme d'habitude ici. Rien à changer dans la qualité et la pertinence de vos articles depuis PCFun, et ça remonte à loin.

Super article. Un peu de pédagogie, ça change des courbes de FPS.

 
 
Il y a de l'écho mais il est clair que c'est un super article!
 
Mon cerveau s'est délecté de cette lecture comme un rotofil jubilerait d'entammer un champ d'orti frais...
 
Merci à vous.
 
HFR: what else?
 

 
andragogie

C'est ce que j'appelle un Article !

Bon, bah on va attendre de voir alors... espérons juste que ça ne tourne pas en eau de boudin comme les tests CPU.
 
Pour une fois, ça permettrait de mettre le doigt sur les véritables différences entre GPU, y compris au niveau du driver D3D qui a tout l'air de se comporter très différemment entre nVidia (favoriserait l'IPC) et AMD (favoriserait le nombre de cores, dans une certaine limite).

 
L'algorithme utilisé n'a rien de spectaculaire en fait, il existe depuis trèèèèès longtemps

Bravo!!! C'est très instructif. Ca montre bien que les développeurs de jeux et ceux qui travaillent avec eux ne sont pas de simples grands enfants qui auraient passé leur vie à sécher l'école...

En effet l'antialiasing est très sommaire au contraire. depuis le deferred il existe 40 techniques, mais celle-ci est la plus ancestrale.
Ce qui m'impressionne le plus c'est le boke. le coup du filtre de fou avec sa FFT c'est ambitieux mais très dans le vent. (bcp de petites demo dernierement sur cet effet)

Aie, je vois que certains ne connaissent pas grand chose a la technique d'antialiasing employée.
L'algo de détection des arrêtes externes sur une scène en 3D n'est pas courant (vous parlez certainement de détection des contours sur une image plate), surtout vu le temps passé.
Je vous met donc au défi, messieurs les malins, de traiter avec autant d'efficacité la même image en 1.4 ms.
A noter que votre algo doit être le plus précis possible, car le RT généré est utilisé pour des opérations gourmandes par la suite. A vous de prouver que vous êtes aussi malin que ça.

L'explication sur le rendu différé est très floue: un objet nécessaire à l'éclairage peut très bien ne pas être visible au final, il n'est pas pour autant ignoré. ( source de lumière, miroir, objet induisant une ombre, etc...)
 
Une simple texture ne peut pas être utilisée pour l'éclairage, il est nécessaire d'avoir sa normale pour y appliquer de la lumière.
 
Quelqu'un peut il éclaircir ce paragraphe ?

N'empêche on comprend mieux pourquoi ils balancent le Source, Cry et Unreal Engine à toutes les sauces, ça fait un sacré travail d'économisé !

  Merci pour cet article vraiment utile à des profanes tels que moi, cela permet d'évaluer la charge de tel ou tel paramètre, donc de savoir sur quel paramètre il vaut mieux jouer si on veut gagner quelque performance.
 
   Quand ce sera possible, la même chose avec une app openGL récente (3.x , 4.x), ce serait parfait .
S'il n'y a pas moyen, je me contenterais d'une analyse du idtech5 (sachant que c'est du 2.1, me semble-t-il), merci d'avance.

 
La normale permet de savoir sur quelle face du triangle tu appliques la texture, en gros.  
 
Imagine que tu dessines un cube. avec une normale pointant vers l'intérieur, les textures seront plaquées a l'intérieur du cube, et seules les surfaces intérieures seront dessinées. Si tu inverses les normales (en les faisant pointer a l'extérieur), tu vas dessiner/voir l'extérieur du cube. Il faut bien entendu placer la caméra et les sources de lumiere au bon endroit, sinon tu vois rien.
 
exemples: tu veux afficher un cube qui traine par terre: tu mets les normales vers l'extérieur.
 
Tu veux afficher un ciel, ou un horizon: tu fais un cube gigantesque qui englobe tout (ok maintenant on fait des demi spheres, mais a l'époque du glide c'était un cube ), et tu fais pointer les normales vers l'intérieur.

A propos de l'effet profondeur de champ, pourquoi le moteur génère t il une passe qui définit les pixels flous alors qu'il pourrait bosser a partir de la depth pass déjà calculée précèdement ?