Maxwell un problème de performance en Async Compute/Async Shader ?

Maxwell un problème de performance en Async Compute/Async Shader ? - Carte graphique - Hardware

Marsh Posté le 01-09-2015 à 12:23:09    

Je reprends la suite du topic fermé et recréé un topic approprié

 

http://forum.hardware.fr/hfr/Hardw [...] m#t9598542

 

Ses dernières semaines ont été agités, entre la sortie de l'alpha de Ashes Of Singularity et les benchmarks des Async Compute/Shader.

 

En fait, il y a deux problèmes de fond :

 

D'un côté Oxide en partenariat avec AMD pour le développement de Ashes Of Singularity annonce que Nvidia ne supporte pas vraiment les Async Compute/Shader, que Nvidia a demandé de les désactiver car ceux-ci faisait baisser les performances.

 

D'un autre côté, un développeur de Beyond3D a développé un programme pour tester les Async Compute/Shader. Sur les cartes AMD, la tâche compute prends un certain temps(plus élevé que chez Nvidia mais est fixe) mais l'utilisation des Async Compute/Shader est bénéfique, le fait d'ajouter une charge graphique n'augmente pas le temps nécessaire au traitement. De plus même avec 128 kernels les performances ne faiblissent pas, même sur GCN 1.0 qui n'est sensé gérer que 16 files d'attente.

 

De leur côté les Geforces traitent les tâches computes très rapidement mais en fonction du nombre de files d'attente(16 pour Maxwell 1, 31 pour Maxwell 2). Au dela les performances baissent mais restent à un niveau correct.(En compute la GTX 960 rivalise avec la Fury X). Une fois les tâches en parallèle, au lieu de ne pas augmenter le temps de traitement les tâches s'additionnent et le temps nécessaire au traitement se voit augmenter. Les Async Compute/Shader ne sont donc pas actifs au sens propre du terme.

 

/!\ Ce test ne compare pas l'efficacité des unités Compute, il sert juste à déterminer si l'Async Compute/Shader est actif. Selon l'optimisation du code les AMD peuvent fournir beaucoup plus de puissance en Compute.

 

http://i.imgur.com/pbKOCci.png

 

Du coup les développeurs peuvent très bien partirent dans plusieurs directions.

 

 - Limiter les Async Compute/Shader à 31 kernels(voir 62) pour avantager les Geforces, les AMD ne tireront pas partie de leurs puissance de traitement supplémentaires en termes d'Async Compute/Shader
 - Augmenter à la limite à plus de 62 kernels et avantager la puissance de traitement des Async Compute/Shader d'AMD plombant alors les performances des Geforces.
 - Ne pas utiliser les Async Compute/Shader

 


Les consoles tirant partis de l'architecture GCN, les développeurs peuvent très bien prendre la seconde solution car comme nous l'avons vu les 128 threads ne pose aucun problème à la R9 280X malgré un nombre d'ACE réduit.

  

Certains jeux annoncent déjà leurs utilisations de l'Async Compute/Shader :

 

 - Rise Of Tomb Raider
 - Fable
 - Deus Ex: Mankind Divided

 

Nous attendons de plus amples informations de la part de Nvidia par rapport aux Async Compute/Shader.

 


Quelques infos par ici :

 

https://forum.beyond3d.com/threads/ [...] its.54891/

 

https://www.reddit.com/r/nvidia/com [...] a_cant_do/

 

https://forum.beyond3d.com/threads/ [...] ead.57188/

 

https://www.reddit.com/r/pcgaming/c [...] rt/cullj3d

 


Je compléterais le topic au fur et à mesure.

 
Spoiler :

Ne t'inquiètes pas je n'essayes pas de minimiser le problème(sinon je n'aurais pas demandé de renommer le topic ainsi). Mais le fait que les performances régressent en DirectX12 m'interpelle sachant que seul l'API change. L'Async Compute/Shader n'est pas actif en DirectX11. Au pire les performances devraient être similaires.
 
Pour les AMD les performances augmentent car DirectX12 permets de réduire l'overhead, les cartes ne sont plus bridés par le cpu et peuvent s'exprimer. L'Async Compute/Shader permets de gagner en temps de rendu et d'augmenter les fps.
 
Mais ce qui me chagrine c'est que pour la même scène et les mêmes settings, la charge graphique devraient être similaire. Malheureusment cela ne semble pas être le cas. La faute sûrement à l'utilisation de tâches compute et graphiques qui se fait en parallèle sur AMD alors que cela est effectué en série sur Nvidia(car désactivé).
J'aimerais connaitre la raison de la demande de désactivation par Nvidia(pilotes pas encore optimisé, limitation hardware ? Peu importe ce que cela est, j'ai besoin de savoir).
 
En tout cas on voit que l'optimisation de l'overhead des pilotes DirectX11 est telle que l'apport de DirectX12 est discutable pour les possesseurs de cartes Nvidia dans ce jeu.
 
Les limitations sont les suivantes : 16 files d'attente pour GCN 1.0, 1.1(Tahiti, Bonaire, Pitcairn), 64 pour GCN 1.2(Hawaii, Tonga). 16 pour Maxwell 1, 31 pour Maxwell 2.
 
En dessous de 32 files les Geforce sont plus rapides, au dessus les performances sont réduitent mais reste correctes. Le problème des premiers benchmarks Async Compute/Shader c'est que sur les Geforce le temps nécessaire a un rendu + tâche compute s'ajoute, alors que cela ne devrait pas(principe même de l'Async Compute/Shader).
 
Du coup cela revient à ma question de plus haut. Que se passe t-il avec les Async Shaders/Compute chez Nvidia ?

Message cité 1 fois
Message édité par matyas69 le 04-09-2015 à 09:18:56
Reply

Marsh Posté le 01-09-2015 à 12:23:09   

Reply

Marsh Posté le 01-09-2015 à 12:37:38    

Benchmark Async Compute/Shaders

 

GTX 960 :

Spoiler :

Compute only:
1. 8.52ms
1. 8.53ms
2. 8.52ms
3. 8.53ms
4. 8.52ms
5. 8.53ms
6. 8.52ms
7. 8.52ms
8. 8.51ms
9. 8.53ms
10. 8.52ms
11. 8.54ms
12. 8.55ms
13. 8.53ms
14. 8.52ms
15. 8.53ms
16. 8.52ms
17. 8.52ms
18. 8.51ms
19. 8.53ms
20. 8.52ms
21. 8.54ms
22. 8.55ms
23. 8.54ms
24. 8.53ms
25. 8.53ms
26. 8.53ms
27. 8.53ms
28. 8.53ms
29. 8.58ms
30. 8.59ms
31. 8.57ms
32. 16.99ms
33. 19.13ms
34. 19.11ms
35. 19.11ms
36. 16.99ms
37. 19.21ms
38. 21.32ms
39. 17.03ms
40. 19.11ms
41. 16.99ms
42. 19.11ms
43. 19.11ms
44. 21.28ms
45. 19.15ms
46. 19.11ms
47. 19.11ms
48. 19.11ms
49. 19.11ms
50. 16.99ms
51. 19.18ms
52. 19.13ms
53. 19.12ms
54. 19.11ms
55. 19.12ms
56. 16.99ms
57. 19.12ms
58. 21.30ms
59. 16.99ms
60. 19.11ms
61. 16.99ms
62. 19.11ms
63. 19.12ms
64. 25.50ms
65. 29.71ms
66. 25.46ms
67. 27.57ms
68. 25.46ms
69. 25.51ms
70. 27.57ms
71. 25.45ms
72. 27.57ms
73. 27.63ms
74. 29.73ms
75. 27.57ms
76. 27.57ms
77. 25.46ms
78. 27.64ms
79. 27.58ms
80. 27.57ms
81. 25.46ms
82. 25.52ms
83. 27.61ms
84. 25.46ms
85. 27.57ms
86. 25.46ms
87. 31.89ms
88. 27.60ms
89. 27.57ms
90. 25.46ms
91. 25.46ms
92. 27.66ms
93. 25.48ms
94. 25.46ms
95. 27.57ms
96. 38.20ms
97. 38.18ms
98. 33.91ms
99. 33.91ms
100. 40.35ms
101. 36.02ms
102. 36.02ms
103. 36.11ms
104. 36.04ms
105. 33.91ms
106. 36.03ms
107. 38.20ms
108. 33.93ms
109. 33.91ms
110. 36.11ms
111. 36.04ms
112. 36.03ms
113. 33.92ms
114. 38.19ms
115. 33.92ms
116. 33.92ms
117. 38.24ms
118. 38.19ms
119. 36.03ms
120. 36.08ms
121. 38.18ms
122. 33.92ms
123. 33.91ms
124. 36.11ms
125. 36.04ms
126. 36.03ms
127. 33.93ms
128. 44.52ms
Graphics only: 39.48ms (42.50G pixels/s)
Graphics + compute:
1. 47.97ms (34.98G pixels/s)
2. 47.93ms (35.00G pixels/s)
3. 47.93ms (35.00G pixels/s)
4. 47.97ms (34.98G pixels/s)
5. 47.93ms (35.00G pixels/s)
6. 47.92ms (35.01G pixels/s)
7. 47.93ms (35.00G pixels/s)
8. 47.91ms (35.02G pixels/s)
9. 47.95ms (34.99G pixels/s)
10. 47.92ms (35.01G pixels/s)
11. 47.92ms (35.01G pixels/s)
12. 47.95ms (34.99G pixels/s)
13. 47.91ms (35.02G pixels/s)
14. 47.93ms (35.00G pixels/s)
15. 47.94ms (34.99G pixels/s)
16. 47.94ms (34.99G pixels/s)
17. 48.02ms (34.94G pixels/s)
18. 47.93ms (35.01G pixels/s)
19. 47.92ms (35.01G pixels/s)
20. 47.97ms (34.97G pixels/s)
21. 47.96ms (34.98G pixels/s)
22. 47.97ms (34.97G pixels/s)
23. 47.93ms (35.01G pixels/s)
24. 47.94ms (34.99G pixels/s)
25. 47.97ms (34.98G pixels/s)
26. 47.95ms (34.99G pixels/s)
27. 47.95ms (34.99G pixels/s)
28. 47.94ms (35.00G pixels/s)
29. 47.93ms (35.00G pixels/s)
30. 48.01ms (34.94G pixels/s)
31. 47.96ms (34.98G pixels/s)
32. 56.45ms (29.72G pixels/s)
33. 56.39ms (29.75G pixels/s)
34. 56.39ms (29.75G pixels/s)
35. 58.56ms (28.65G pixels/s)
36. 56.39ms (29.75G pixels/s)
37. 58.58ms (28.64G pixels/s)
38. 56.40ms (29.75G pixels/s)
39. 58.60ms (28.63G pixels/s)
40. 56.39ms (29.75G pixels/s)
41. 58.56ms (28.65G pixels/s)
42. 56.40ms (29.75G pixels/s)
43. 56.48ms (29.71G pixels/s)
44. 56.39ms (29.75G pixels/s)
45. 56.43ms (29.73G pixels/s)
46. 56.41ms (29.74G pixels/s)
47. 56.40ms (29.75G pixels/s)
48. 58.58ms (28.64G pixels/s)
49. 56.40ms (29.75G pixels/s)
50. 58.59ms (28.63G pixels/s)
51. 56.39ms (29.75G pixels/s)
52. 58.56ms (28.65G pixels/s)
53. 56.40ms (29.75G pixels/s)
54. 56.47ms (29.71G pixels/s)
55. 56.39ms (29.75G pixels/s)
56. 58.58ms (28.64G pixels/s)
57. 56.40ms (29.75G pixels/s)
58. 56.42ms (29.74G pixels/s)
59. 58.54ms (28.66G pixels/s)
60. 56.40ms (29.75G pixels/s)
61. 56.45ms (29.72G pixels/s)
62. 56.41ms (29.74G pixels/s)
63. 56.47ms (29.71G pixels/s)
64. 64.85ms (25.87G pixels/s)
65. 67.05ms (25.02G pixels/s)
66. 64.85ms (25.87G pixels/s)
67. 67.04ms (25.02G pixels/s)
68. 64.87ms (25.86G pixels/s)
69. 67.04ms (25.03G pixels/s)
70. 64.85ms (25.87G pixels/s)
71. 67.00ms (25.04G pixels/s)
72. 64.88ms (25.86G pixels/s)
73. 67.00ms (25.04G pixels/s)
74. 64.88ms (25.86G pixels/s)
75. 67.00ms (25.04G pixels/s)
76. 67.01ms (25.04G pixels/s)
77. 64.85ms (25.87G pixels/s)
78. 69.18ms (24.25G pixels/s)
79. 64.85ms (25.87G pixels/s)
80. 64.94ms (25.83G pixels/s)
81. 64.85ms (25.87G pixels/s)
82. 67.06ms (25.02G pixels/s)
83. 64.89ms (25.86G pixels/s)
84. 67.08ms (25.01G pixels/s)
85. 64.86ms (25.87G pixels/s)
86. 67.03ms (25.03G pixels/s)
87. 64.86ms (25.87G pixels/s)
88. 67.00ms (25.04G pixels/s)
89. 64.89ms (25.86G pixels/s)
90. 67.00ms (25.04G pixels/s)
91. 67.03ms (25.03G pixels/s)
92. 64.86ms (25.87G pixels/s)
93. 67.01ms (25.04G pixels/s)
94. 64.85ms (25.87G pixels/s)
95. 67.07ms (25.01G pixels/s)
96. 73.30ms (22.89G pixels/s)
97. 73.39ms (22.86G pixels/s)
98. 73.31ms (22.89G pixels/s)
99. 75.45ms (22.24G pixels/s)
100. 73.38ms (22.86G pixels/s)
101. 73.31ms (22.89G pixels/s)
102. 75.51ms (22.22G pixels/s)
103. 73.31ms (22.89G pixels/s)
104. 75.46ms (22.23G pixels/s)
105. 73.35ms (22.87G pixels/s)
106. 73.31ms (22.89G pixels/s)
107. 75.50ms (22.22G pixels/s)
108. 73.32ms (22.88G pixels/s)
109. 73.37ms (22.87G pixels/s)
110. 75.50ms (22.22G pixels/s)
111. 73.30ms (22.89G pixels/s)
112. 73.38ms (22.86G pixels/s)
113. 73.30ms (22.89G pixels/s)
114. 75.49ms (22.23G pixels/s)
115. 75.51ms (22.22G pixels/s)
116. 73.32ms (22.88G pixels/s)
117. 73.55ms (22.81G pixels/s)
118. 73.33ms (22.88G pixels/s)
119. 73.37ms (22.87G pixels/s)
120. 73.35ms (22.87G pixels/s)
121. 75.46ms (22.23G pixels/s)
122. 75.50ms (22.22G pixels/s)
123. 73.31ms (22.89G pixels/s)
124. 73.37ms (22.87G pixels/s)
125. 73.37ms (22.87G pixels/s)
126. 75.46ms (22.23G pixels/s)
127. 75.50ms (22.22G pixels/s)
128. 81.76ms (20.52G pixels/s)

 

R9 280X :

 
Spoiler :

Compute only:
1. 49.01ms
2. 49.00ms
3. 49.00ms
4. 49.00ms
5. 49.00ms
6. 49.02ms
7. 49.01ms
8. 49.02ms
9. 49.01ms
10. 49.00ms
11. 49.01ms
12. 49.00ms
13. 49.01ms
14. 49.01ms
15. 49.00ms
16. 49.01ms
17. 49.01ms
18. 49.01ms
19. 49.01ms
20. 49.01ms
21. 49.02ms
22. 49.01ms
23. 49.01ms
24. 49.01ms
25. 49.01ms
26. 49.02ms
27. 49.01ms
28. 49.01ms
29. 49.02ms
30. 49.01ms
31. 49.02ms
32. 49.01ms
33. 49.01ms
34. 49.01ms
35. 49.01ms
36. 49.02ms
37. 49.01ms
38. 49.01ms
39. 49.02ms
40. 49.00ms
41. 49.01ms
42. 49.01ms
43. 49.01ms
44. 49.01ms
45. 49.01ms
46. 49.02ms
47. 49.01ms
48. 49.01ms
49. 49.01ms
50. 49.01ms
51. 49.01ms
52. 49.01ms
53. 49.01ms
54. 49.02ms
55. 49.01ms
56. 49.01ms
57. 49.01ms
58. 49.01ms
59. 49.02ms
60. 49.01ms
61. 49.01ms
62. 49.01ms
63. 49.01ms
64. 49.02ms
65. 49.00ms
66. 49.01ms
67. 49.01ms
68. 49.01ms
69. 49.02ms
70. 49.01ms
71. 49.01ms
72. 49.01ms
73. 49.01ms
74. 49.02ms
75. 49.01ms
76. 49.01ms
77. 49.01ms
78. 49.01ms
79. 49.02ms
80. 49.01ms
81. 49.01ms
82. 49.02ms
83. 49.00ms
84. 49.03ms
85. 49.01ms
86. 49.01ms
87. 49.02ms
88. 49.01ms
89. 49.03ms
90. 49.00ms
91. 49.01ms
92. 49.02ms
93. 49.01ms
94. 49.02ms
95. 49.01ms
96. 49.01ms
97. 49.01ms
98. 49.01ms
99. 49.02ms
100. 49.01ms
101. 49.01ms
102. 49.02ms
103. 49.00ms
104. 49.01ms
105. 49.01ms
106. 49.01ms
107. 49.01ms
108. 49.00ms
109. 49.02ms
110. 49.01ms
111. 49.01ms
112. 49.02ms
113. 49.01ms
114. 49.02ms
115. 49.01ms
116. 49.01ms
117. 49.02ms
118. 49.01ms
119. 49.01ms
120. 49.01ms
121. 49.01ms
122. 49.02ms
123. 49.01ms
124. 49.01ms
125. 49.01ms
126. 49.00ms
127. 49.02ms
128. 49.00ms
Graphics only: 47.38ms (35.41G pixels/s)
Graphics + compute:
1. 49.12ms (34.16G pixels/s)
2. 49.12ms (34.16G pixels/s)
3. 49.11ms (34.16G pixels/s)
4. 49.13ms (34.15G pixels/s)
5. 49.12ms (34.16G pixels/s)
6. 49.16ms (34.13G pixels/s)
7. 49.12ms (34.16G pixels/s)
8. 49.14ms (34.14G pixels/s)
9. 49.13ms (34.15G pixels/s)
10. 49.13ms (34.15G pixels/s)
11. 49.16ms (34.13G pixels/s)
12. 49.14ms (34.14G pixels/s)
13. 49.15ms (34.14G pixels/s)
14. 49.15ms (34.14G pixels/s)
15. 49.15ms (34.14G pixels/s)
16. 49.16ms (34.13G pixels/s)
17. 49.16ms (34.13G pixels/s)
18. 49.15ms (34.13G pixels/s)
19. 49.14ms (34.14G pixels/s)
20. 49.15ms (34.13G pixels/s)
21. 49.16ms (34.13G pixels/s)
22. 49.17ms (34.12G pixels/s)
23. 49.15ms (34.14G pixels/s)
24. 49.15ms (34.13G pixels/s)
25. 49.15ms (34.13G pixels/s)
26. 49.17ms (34.12G pixels/s)
27. 49.16ms (34.12G pixels/s)
28. 49.17ms (34.12G pixels/s)
29. 49.16ms (34.13G pixels/s)
30. 49.16ms (34.13G pixels/s)
31. 49.17ms (34.12G pixels/s)
32. 49.16ms (34.12G pixels/s)
33. 49.15ms (34.14G pixels/s)
34. 49.15ms (34.14G pixels/s)
35. 49.16ms (34.13G pixels/s)
36. 49.15ms (34.13G pixels/s)
37. 49.17ms (34.12G pixels/s)
38. 49.17ms (34.12G pixels/s)
39. 49.15ms (34.13G pixels/s)
40. 49.18ms (34.11G pixels/s)
41. 49.16ms (34.13G pixels/s)
42. 49.16ms (34.13G pixels/s)
43. 49.15ms (34.14G pixels/s)
44. 49.15ms (34.13G pixels/s)
45. 49.15ms (34.14G pixels/s)
46. 49.16ms (34.13G pixels/s)
47. 49.15ms (34.14G pixels/s)
48. 49.16ms (34.13G pixels/s)
49. 49.16ms (34.12G pixels/s)
50. 49.16ms (34.13G pixels/s)
51. 49.18ms (34.11G pixels/s)
52. 49.17ms (34.12G pixels/s)
53. 49.16ms (34.13G pixels/s)
54. 49.17ms (34.12G pixels/s)
55. 49.16ms (34.13G pixels/s)
56. 49.17ms (34.12G pixels/s)
57. 49.15ms (34.13G pixels/s)
58. 49.18ms (34.12G pixels/s)
59. 49.15ms (34.13G pixels/s)
60. 49.16ms (34.13G pixels/s)
61. 49.17ms (34.12G pixels/s)
62. 49.17ms (34.12G pixels/s)
63. 49.16ms (34.13G pixels/s)
64. 49.17ms (34.12G pixels/s)
65. 49.17ms (34.12G pixels/s)
66. 49.18ms (34.11G pixels/s)
67. 49.17ms (34.12G pixels/s)
68. 49.17ms (34.12G pixels/s)
69. 49.18ms (34.11G pixels/s)
70. 49.17ms (34.12G pixels/s)
71. 49.18ms (34.11G pixels/s)
72. 49.16ms (34.13G pixels/s)
73. 49.19ms (34.11G pixels/s)
74. 49.21ms (34.10G pixels/s)
75. 49.16ms (34.13G pixels/s)
76. 49.18ms (34.11G pixels/s)
77. 49.17ms (34.12G pixels/s)
78. 49.18ms (34.11G pixels/s)
79. 49.17ms (34.12G pixels/s)
80. 49.18ms (34.12G pixels/s)
81. 49.19ms (34.10G pixels/s)
82. 49.16ms (34.13G pixels/s)
83. 49.17ms (34.12G pixels/s)
84. 49.18ms (34.11G pixels/s)
85. 49.16ms (34.13G pixels/s)
86. 49.17ms (34.12G pixels/s)
87. 49.17ms (34.12G pixels/s)
88. 49.16ms (34.13G pixels/s)
89. 49.18ms (34.11G pixels/s)
90. 49.17ms (34.12G pixels/s)
91. 49.20ms (34.10G pixels/s)
92. 49.16ms (34.13G pixels/s)
93. 49.17ms (34.12G pixels/s)
94. 49.18ms (34.11G pixels/s)
95. 49.18ms (34.12G pixels/s)
96. 49.18ms (34.11G pixels/s)
97. 49.17ms (34.12G pixels/s)
98. 49.16ms (34.13G pixels/s)
99. 49.17ms (34.12G pixels/s)
100. 49.18ms (34.12G pixels/s)
101. 49.19ms (34.11G pixels/s)
102. 49.17ms (34.12G pixels/s)
103. 49.19ms (34.11G pixels/s)
104. 49.19ms (34.11G pixels/s)
105. 49.19ms (34.11G pixels/s)
106. 49.19ms (34.10G pixels/s)
107. 49.17ms (34.12G pixels/s)
108. 49.18ms (34.12G pixels/s)
109. 49.19ms (34.11G pixels/s)
110. 49.17ms (34.12G pixels/s)
111. 49.20ms (34.10G pixels/s)
112. 49.16ms (34.13G pixels/s)
113. 49.19ms (34.11G pixels/s)
114. 49.20ms (34.10G pixels/s)
115. 49.17ms (34.12G pixels/s)
116. 49.18ms (34.12G pixels/s)
117. 49.16ms (34.13G pixels/s)
118. 49.19ms (34.10G pixels/s)
119. 49.18ms (34.11G pixels/s)
120. 49.18ms (34.12G pixels/s)
121. 49.19ms (34.11G pixels/s)
122. 49.18ms (34.11G pixels/s)
123. 49.17ms (34.12G pixels/s)
124. 49.19ms (34.11G pixels/s)
125. 49.18ms (34.11G pixels/s)
126. 49.19ms (34.11G pixels/s)
127. 49.19ms (34.11G pixels/s)
128. 49.19ms (34.11G pixels/s)


Message édité par matyas69 le 02-09-2015 à 06:51:54
Reply

Marsh Posté le 01-09-2015 à 15:16:40    

C'est compliqué d'activer ou désactiver l'utilisation de l'Async Compute selon le GPU sur un même jeu? Je doute que ce soit aussi lourd que de développer en parallèle une version DX11 et une DX12.

Message cité 1 fois
Message édité par kimujix le 01-09-2015 à 15:19:59
Reply

Marsh Posté le 01-09-2015 à 15:22:12    

kimujix a écrit :

C'est compliqué d'activer ou désactiver l'utilisation de l'Async Compute selon le GPU sur un même jeu? Je doute que ce soit aussi lourd que de faire une version DX11 et une DX12.


 
Non ce n'est pas dur, mais le fait de ne pas pouvoir en tirer avantage apporte moins de performance aux Geforces. DirectX12 permets d'augmenter la limite de draws calls(en réduisant l'overhead), ajoute de la flexibilité mais l'Async Compute/Shader reste quand même une fonctionnalité importante de DirectX12.

Reply

Marsh Posté le 01-09-2015 à 17:42:13    

Donc rien n'empêche réellement d'intégrer l'Async Compute en tant qu'option qui s'activera ou non selon le GPU détecté. Ça évitera aux GPUs Maxwell de s’emmêler les pinceaux à cause de leur vrai-faux support (cf Ashes of singularity) et on aura un bonus de perfs avec les GPUs GCN.
 
C'est quand même beaucoup moins méchant que le principe de Gameworks ou pire le coup de la tesselation appliquée à des éléments invisibles ou trouzmilles triangles pour un truc qui n'en nécessite que 3 pour arrondir un angle. Ces méthodes font chuter les perfs chez tout le monde, c'est juste un peu moins lourd chez Nvidia. Async Compute fait gagner des perfs, en l'intégrant on ne pénalise pas les cartes Nvidia, il suffit qu'il se désactive si ça leur cause des soucis. Et puis c'est une ressource accessible à tous, ce n'est pas un truc proprio, si Nvidia le veut ils n'ont qu'a sortir des GPUs qui le gèrent (et ils auront probablement un support complet avec Pascal).
 
C'est comme si à l'époque des premières cartes accélératrices on s'était dit "bon alors on ne va pas faire de version glide parce que les gens qui n'ont pas de 3Dfx ne pourront pas en profiter". On gagne quelque chose si on a le matos pour ou on ne gagne rien si on l'a pas, mais on ne retire rien à personne.


Message édité par kimujix le 01-09-2015 à 17:45:43
Reply

Marsh Posté le 01-09-2015 à 20:06:32    

http://tof.canardpc.com/preview2/645bd8b8-6026-4150-91b6-7d13967ea1a1.jpg

 

http://forum.beyond3d.com/posts/1869304/

 

http://tof.canardpc.com/preview2/778342f9-3fc8-41b2-a5db-d722d789d555.jpg

 

http://forum.beyond3d.com/posts/1869302/


Message édité par Invite_Surprise le 01-09-2015 à 20:10:14
Reply

Marsh Posté le 02-09-2015 à 13:21:13    

PCPer a fait un article sur le sujet et attend des réponses de NVidia.
http://www.pcper.com/reviews/Edito [...] us-Shaders

Reply

Marsh Posté le 02-09-2015 à 23:16:06    

matyas69 a écrit :

Je reprends la suite du topic fermé et recréé un topic approprié
 
 
D'un autre côté, un développeur de Beyond3D a développé un programme pour tester les Async Compute/Shader. Sur les cartes AMD, la tâche compute prends un certain temps(plus élevé que chez Nvidia mais est fixe) mais l'utilisation des Async Compute/Shader est bénéfique, le fait d'ajouter une charge graphique n'augmente pas le temps nécessaire au traitement. De plus même avec 128 kernels les performances ne faiblissent pas, même sur GCN 1.0 qui n'est sensé gérer que 16 files d'attente.  
 
De leur côté les Geforces traitent les tâches computes très rapidement mais en fonction du nombre de files d'attente(16 pour Maxwell 1, 31 pour Maxwell 2). Au dela les performances baissent mais restent à un niveau correct.(En compute la GTX 960 rivalise avec la Fury X). Une fois les tâches en parallèle, au lieu de ne pas augmenter le temps de traitement les tâches s'additionnent et le temps nécessaire au traitement se voit augmenter. Les Async Compute/Shader ne sont donc pas actifs au sens propre du terme.


 
A la lecture du thread de beyond3d, j'ai l'impression qu'il faut comprendre plutôt que le temps sur gcn n'augmente pas en fonction du nombre contrairement à maxwell car le code de calcul (le kernel compute) ne semble pas être adapté aux gcn (driver peut-être)
 
In the second test the loop iterates 524,288 times. That's 20ms. So now we get to some truth about this kernel, it runs vastly slower on AMD than on NVidia. OK, there's still 6 ms that I can't explain (which is as much time as GM200 spends), but I think we've almost cracked one of the mysteries for the bizarre slowness on AMD
 
Apart from that I can't help wondering if the [numthreads(1, 1, 1)] attribute of the kernel is making AMD do something additionally strange.
 
https://forum.beyond3d.com/threads/ [...] 88/page-18
 
bon après je ne suis pas spécialiste même si mon métier est développeur à la base.
 

Reply

Marsh Posté le 03-09-2015 à 06:50:09    

mogana a écrit :

 

A la lecture du thread de beyond3d, j'ai l'impression qu'il faut comprendre plutôt que le temps sur gcn n'augmente pas en fonction du nombre contrairement à maxwell car le code de calcul (le kernel compute) ne semble pas être adapté aux gcn (driver peut-être)

 

In the second test the loop iterates 524,288 times. That's 20ms. So now we get to some truth about this kernel, it runs vastly slower on AMD than on NVidia. OK, there's still 6 ms that I can't explain (which is as much time as GM200 spends), but I think we've almost cracked one of the mysteries for the bizarre slowness on AMD

 

Apart from that I can't help wondering if the [numthreads(1, 1, 1)] attribute of the kernel is making AMD do something additionally strange.

 

https://forum.beyond3d.com/threads/ [...] 88/page-18

 

bon après je ne suis pas spécialiste même si mon métier est développeur à la base.

 


 
Citation :


AMD
Sur les cartes AMD, la tâche compute prends un certain temps(plus élevé que chez Nvidia mais est fixe) mais l'utilisation des Async Compute/Shader est bénéfique, le fait d'ajouter une charge graphique n'augmente pas le temps nécessaire au traitement.

 

MAXWELL
une fois les tâches en parallèle, au lieu de ne pas augmenter le temps de traitement les tâches s'additionnent et le temps nécessaire au traitement se voit augmenter. Les Async Compute/Shader ne sont donc pas actifs au sens propre du terme.


 

Je comprends pas ce que tu veux dire c'est exactement ce que je dis.

 

Apparemment depuis la dernière version les Radeons ne sont plus affectés par cette latence et se comporte maintenant comme les Geforces en compute mais au final c'est toujours la même histoire les Geforces s'engorgent beaucoup plus vite que les Radeons. J'ai l'impression de revivre la même chose qu'à l'époque des HD 58XX et des GTX 4XX avec la tesselation mais en sens inverse :D

 

Apparemment et cela revient plus fois depuis quelques jours, ce serait apparemment dû au fait que Nvidia a besoin d'un scheduler software pour utiliser le Mixed Mode alors que celui d'AMD est hardware. En utilisant le Graphics mode seul, le scheduler est hardware(bon pour la VR)

 
Citation :

As you can see, Maxwell 2.0 does support mixed mode and upto 31 compute queues in conjunction with its primary graphics Queue. No other Nvidia architecture has this capability without involving a complete mode switch. Now this where things get a bit muddy. Since there is no clear documentation, and since Nvidia has yet to release an official statement on the matter, it is alleged (read: not confirmed in any way), that Nvidia’s mixed mode requires the use of a software scheduler which is why it is actually expensive to deploy even on Maxwell 2.0.

 

On attends toujours la réaction de Nvidia.

Message cité 1 fois
Message édité par matyas69 le 03-09-2015 à 07:05:25
Reply

Marsh Posté le 04-09-2015 à 00:00:39    

matyas69 a écrit :


 

Citation :


AMD
Sur les cartes AMD, la tâche compute prends un certain temps(plus élevé que chez Nvidia mais est fixe) mais l'utilisation des Async Compute/Shader est bénéfique, le fait d'ajouter une charge graphique n'augmente pas le temps nécessaire au traitement.

 
MAXWELL
une fois les tâches en parallèle, au lieu de ne pas augmenter le temps de traitement les tâches s'additionnent et le temps nécessaire au traitement se voit augmenter. Les Async Compute/Shader ne sont donc pas actifs au sens propre du terme.



 
Je comprends pas ce que tu veux dire c'est exactement ce que je dis.
 
Apparemment depuis la dernière version les Radeons ne sont plus affectés par cette latence et se comporte maintenant comme les Geforces en compute mais au final c'est toujours la même histoire les Geforces s'engorgent beaucoup plus vite que les Radeons. J'ai l'impression de revivre la même chose qu'à l'époque des HD 58XX et des GTX 4XX avec la tesselation mais en sens inverse :D
 
Apparemment et cela revient plus fois depuis quelques jours, ce serait apparemment dû au fait que Nvidia a besoin d'un scheduler software pour utiliser le Mixed Mode alors que celui d'AMD est hardware. En utilisant le Graphics mode seul, le scheduler est hardware(bon pour la VR)
 

Citation :

As you can see, Maxwell 2.0 does support mixed mode and upto 31 compute queues in conjunction with its primary graphics Queue. No other Nvidia architecture has this capability without involving a complete mode switch. Now this where things get a bit muddy. Since there is no clear documentation, and since Nvidia has yet to release an official statement on the matter, it is alleged (read: not confirmed in any way), that Nvidia’s mixed mode requires the use of a software scheduler which is why it is actually expensive to deploy even on Maxwell 2.0.


 
On attends toujours la réaction de Nvidia.


 
Ce que je dis c'est que peut-être le code n'est pas efficient sur gcn et que donc le temps unitaire des compute n'est pas à considérer.
En gros tu as t < 10ms sur nvidia et y > 40ms sur amd, et bien ce que semble dire certains gars sur beyond3d, c'est que le code lui-même n'est pas adapté à gcn et que donc on ne peut conclure sur l'efficacité des unités de calcul elles-mêmes (en effet j'ai du mal à imaginer qu'en compute only qu'une unité nvidia soit 5 fois plus rapide qu'une unité amd, mais qui sait).
par contre, en augmentant le nombre de tâches ça évolue à la baisse sur nvidia et constant sur amd.
enfin bref, c'est juste ce que je comprends,  je ne suis pas un expert.


Message édité par mogana le 04-09-2015 à 00:41:58
Reply

Marsh Posté le 04-09-2015 à 00:00:39   

Reply

Marsh Posté le 04-09-2015 à 09:11:21    

C'est le cas, de toute façon le test ne testait pas l'efficacité des unités mais si l'Async Compute était actif.

Reply

Marsh Posté le 04-09-2015 à 10:46:54    

matyas69 a écrit :

C'est le cas, de toute façon le test ne testait pas l'efficacité des unités mais si l'Async Compute était actif.


 
on est d'accord  :jap:

Reply

Marsh Posté le 09-09-2015 à 18:38:30    

Reply

Marsh Posté le 09-09-2015 à 18:59:01    

Franchement si cela s'avère vrai que Nvidia essaie de forcer l'arrêt de l'utilisation de l'Async Compute / Shader ça serait franchement déguelasse pour les utilisateurs de Radeons puisque leur cartes auront de la marge sous la pédale. Cela dit je peux comprendre que les utilisateurs de Geforce aimeraient pouvoir jouer :o

Reply

Marsh Posté le 10-09-2015 à 20:20:42    

Zurkum a écrit :

Franchement si cela s'avère vrai que Nvidia essaie de forcer l'arrêt de l'utilisation de l'Async Compute / Shader ça serait franchement déguelasse pour les utilisateurs de Radeons puisque leur cartes auront de la marge sous la pédale. Cela dit je peux comprendre que les utilisateurs de Geforce aimeraient pouvoir jouer :o


De ce que j'ai compris, la désactivation n'aurait lieu que si le jeu détecte une GeForce. Sur les Radeon ça fonctionnerait normalement avec un net gain. Comme ça, tout le monde est content  :jap:  


---------------
L'innovation, c'est extra :)
Reply

Marsh Posté le 10-09-2015 à 21:03:32    

Lyto a écrit :


De ce que j'ai compris, la désactivation n'aurait lieu que si le jeu détecte une GeForce. Sur les Radeon ça fonctionnerait normalement avec un net gain. Comme ça, tout le monde est content  :jap:  


 
ça c'est seulement pour Ashes Of Singularity, ça dépendra des jeux et donc du bon vouloir des développeurs.

Reply

Marsh Posté le 11-09-2015 à 03:22:02    

Il y a quand même un truc qui m'intrigue avec le bench d'Ashes of Singularity. A part Project Cars je ne connais aucun jeu DX11 où la GTX 980 met un tel vent à la R9 390X, sans DX12 la 390X est complètement à la ramasse. Pourquoi ici c'est la cata alors qu'ailleurs elle se défend plutôt bien face à la GTX 980?

Message cité 1 fois
Message édité par kimujix le 11-09-2015 à 04:41:54
Reply

Marsh Posté le 11-09-2015 à 04:12:59    

kimujix a écrit :

Il y a quand même un truc qui m'intrigue avec le bench d'Ashes of Singularity. A part Project Cars je ne connais aucun jeu DX11 où la GTX 980 met un tel vent à la R9 390X, sans DX12 la 390X est complètement à la ramasse. Pour ici c'est la cata alors qu'ailleurs elle se défend plutôt bien face à la GTX 980?


 
Les GeForce sont supérieurs aux Radeon en draw calls ST&MT sous DX11 ainsi qu'en puissance brute pour les calculs géométriques, donc pour les scènes très complexes en DX11 elles vont exploser les Radeon.
 
La vrai question est savoir si le bench de AoS est représentatif de l'expérience en jeux ou si il sert a comparer des scènes complexes sous DX11 à la même chose en DX12. (Un des buts premier de DX12 étant justement d'être plus efficace dans les scènes complexes)


---------------
You have no chance to survive make your time.
Reply

Marsh Posté le 11-09-2015 à 04:43:04    

Il n'y a aucun jeu DX11 qui fasse autant appel à ces fonctions que AoS?

Reply

Marsh Posté le 11-09-2015 à 05:13:45    

kimujix a écrit :

Il n'y a aucun jeu DX11 qui fasse autant appel à ces fonctions que AoS?


 
Faudrait que je retrouve l'article pour les chiffres exacts, mais de mémoire les jeux DX11 utilisent 200k~500k draw calls en moyenne avec les plus complexes qui monte jusqu'à ~700k. On est encore assez loin des ~1.1 millions supporté par les R9 (~2.3 millions en MT pour une GTX980). Le problème n'existe pas en DX12 parce qu'une simple 290X peu en faire ~16 millions.
 
Donc c'est possible que le bench de AoS sature les Radeon en DX11.

Message cité 1 fois
Message édité par Kernel-Panic le 11-09-2015 à 05:14:18

---------------
You have no chance to survive make your time.
Reply

Marsh Posté le 11-09-2015 à 07:26:26    

Kernel-Panic a écrit :


 
Faudrait que je retrouve l'article pour les chiffres exacts, mais de mémoire les jeux DX11 utilisent 200k~500k draw calls en moyenne avec les plus complexes qui monte jusqu'à ~700k. On est encore assez loin des ~1.1 millions supporté par les R9 (~2.3 millions en MT pour une GTX980). Le problème n'existe pas en DX12 parce qu'une simple 290X peu en faire ~16 millions.
 
Donc c'est possible que le bench de AoS sature les Radeon en DX11.


Intéressant.  :jap:  
Et quand tu parles des "plus complexes" tu veux parler de quels moteurs de jeu par exemple ?


---------------
L'innovation, c'est extra :)
Reply

Marsh Posté le 15-09-2015 à 13:22:23    

Bonjour,
Il y a ce lien qui parle du sujet
https://www.reddit.com/r/pcmasterra [...] port_dx12/
Je poste pas pour l'article en lui même, qu'on connaît déjà tous, mais surtout pour les commentaires en dessous qui sont intéressants.

 

Apparemment Ark Survival evolved aurait dû avoir son patch directX 12 mais il n'est pas sorti et on ne sait pas pourquoi.
Bien que n'ayant aucune preuve, on peut supposer que nvidia est en train de jouer de son influence pour qu'on utilise pas async compute dans les jeux actuels. d'ou le retard de directX12 dans ark.

 

En tout cas nvidia communique pas alors que le sujet est très grave, donc il veulent que ça passe innaperçu et vont se servir de leur influence pour que async compute ne soit pas utilisé. En effet c'est quand même vachement étrange qu'on ai eu un seul bench directX12 et depuis nada, vous trouvez pas ?

 

ça va durer jusqu'à la prochaine génération de gforce.

 

En tout cas acheter une maxwell aujourd'hui c'est acheter une carte qui a une durée de vie de six mois.

 

En effet async compute semble être la fonction qui donne un coup de pied au cul aux perfs.

Message cité 1 fois
Message édité par LePcFou le 15-09-2015 à 13:24:34

---------------
Keyboard not found
Reply

Marsh Posté le 15-09-2015 à 13:37:11    

Salut,
 

LePcFou a écrit :

Apparemment Ark Survival evolved aurait dû avoir son patch directX 12 mais il n'est pas sorti et on ne sait pas pourquoi.
Bien que n'ayant aucune preuve, on peut supposer que nvidia est en train de jouer de son influence pour qu'on utilise pas async compute dans les jeux actuels. d'ou le retard de directX12 dans ark.


 
Une simple supposition ...
 

LePcFou a écrit :

En tout cas nvidia communique pas alors que le sujet est très grave, donc il veulent que ça passe innaperçu et vont se servir de leur influence pour que async compute ne soit pas utilisé. En effet c'est quand même vachement étrange qu'on ai eu un seul bench directX12 et depuis nada, vous trouvez pas ?


 
... se transforme en accusation (avec sous entendu et sans aucune preuve).
 

LePcFou a écrit :

ça va durer jusqu'à la prochaine génération de gforce.
 
En tout cas acheter une maxwell aujourd'hui c'est acheter une carte qui a une durée de vie de six mois.


 
Puis viens les propos complétement farfelu et trollesque.
 

LePcFou a écrit :

En effet async compute semble être la fonction qui donne un coup de pied au cul aux perfs.


 
Et pour finir l’affirmation erroné, mais qui passe bien, pour enfoncer le clou.  :o  
 
 
@LePcFou je suis désolé, mais c'est à cause de commentaires comme le tiens que le Topic précédent à été fermé. C'est très dommage de ne pas pouvoir discuter "Hadware & technique" dans ce genre de situation, à cause d'affirmation et de grossier raccourcis comme tu viens de nous en faire la démonstration.  :fou:


Message édité par Crashdent le 15-09-2015 à 13:37:30

---------------
Parce que je suis un troll : j'ai déconseillé Winrar sur clubic.
Reply

Marsh Posté le 15-09-2015 à 14:54:38    

La modération confirme [:neostranger].
Faites attention à ce que vous écrivez et évitez les informations à l'emporte pièce qui ressemble plus à des idées personnelles que des faits :sarcastic:.


---------------
Topic .Net - C# @ Prog
Reply

Marsh Posté le 15-09-2015 à 15:02:53    

Juste une petite question:
 
Si DX12 est un dérivé de Mantle, les perfs des AMD ne se seraient pas déjà envolées par rapport à DX11 sur Battlefield par exemple ?
EDIT : sauf si évidemment Mantle ne prenait de toute manière pas les "Async..." ?

Message cité 1 fois
Message édité par Hive le 15-09-2015 à 15:03:28
Reply

Marsh Posté le 15-09-2015 à 15:07:09    

Hive a écrit :

Si DX12 est un dérivé de Mantle, les perfs des AMD ne se seraient pas déjà envolées par rapport à DX11 sur Battlefield par exemple ?
EDIT : sauf si évidemment Mantle ne prenait de toute manière pas les "Async..." ?


 
Mantle, initialement, c'est pour remettre les FX dans la course qu'AMD à investie la dedans.
 
DX12 devrais avoir le même objectif, mais étendu à plus de jeux (pas seulement battlefield).

Message cité 1 fois
Message édité par Crashdent le 15-09-2015 à 16:38:11

---------------
Parce que je suis un troll : j'ai déconseillé Winrar sur clubic.
Reply

Marsh Posté le 15-09-2015 à 15:15:04    

Comme je l'avais dit dans un topic en passant, NVidia a parfaitement optimisé ses cartes pour du Directx11, larguant AMD derrière dans le très haut de gamme.  
 
AMD a développé Mantle, repris ensuite dans directx12, donc AMD avait déjà conscience des enjeux à bas niveau que représente la nouvelle API et a pu créer une architecture orentée dx12 mais qui (malheureusement diront certains) n'était pas forcément très optimisée dx11 (quoique AMD se défend quand même très bien quoi qu'on en dise sur la plupart des segments), API du moment.  
 
D'après moi (je vais me faire taper) les tests qui sortiront bientôt n'ont pas vraiment d'importance puisque les deux acteurs principaux vont sortir d'ici un an (~) leurs nouvelles gammes totalement tournées vers dx12, avec en plus une architecture totalement remaniée et un nouveau type de mémoire (HBM2).  
 
Et c'est là que tout se jouera vraiment, surtout la survie d'AMD qui est asphyxié d'un côté par NVidia et ses 80% de parts de marché et de l'autre par ses créanciers qui attendent un remboursement important en 2017 il me semble (à confirmer, j'ai aussi 2019 qui trotte en tête).
 
D'où une question qui, pour moi, a toute son importance : est-ce que pour vous ces tests seront déterminants pour passer par exemple d'une 970 à une 380x si la domination AMD est confirmée ? Je ne pense pas que les résultats entraînent de gros changements de camp surtout sur une génération de CG qui sera déjà bien entamée.


---------------
Alim Seasonic platinum SS-1200XP; Asus P8Z77-m PRO; i5-3570k @ 4.2 GHz; 16 Go DDR3; 2*2To Seagate; Intel 128 go 320 series; Samsung 250go 850 evo; SLI Asus GTX670 DCUII @ 1137 MHz; Fractal Design Define R3;
Reply

Marsh Posté le 15-09-2015 à 15:18:45    

A ce sujet j'ai vu 2019 moi, mais je n'ai pas de source à citer.


---------------
Topic .Net - C# @ Prog
Reply

Marsh Posté le 15-09-2015 à 15:23:26    

Crashdent a écrit :


 
Tu ne confond pas CPU et GPU par hasard ?
 
Mantle, initialement, c'est pour remettre les FX dans la course qu'AMD à investie la dedans.
 
DX12 devrais avoir le même objectif, mais étendu à plus de jeux (pas seulement battlefield).
 
ASync Compute fait partie du logiciel coté carte graphique. Donc absent de Mantle à priori.  :wahoo:  


Mantle pour remettre dans la course les FX   :lol:  
 
je te cite et te renvoie ta propre remarque ( même si elle ne s'adressait pas à moi ) car en terme de raccourci bien foireux tu le surpasses largement  :sarcastic:

Citation :

@LePcFou  Crashdent   je suis désolé, mais c'est à cause de commentaires comme le tiens que le Topic précédent à été fermé. C'est très dommage de ne pas pouvoir discuter "Hadware & technique" dans ce genre de situation, à cause d'affirmation et de grossier raccourcis comme tu viens de nous en faire la démonstration.  :fou:
 

Reply

Marsh Posté le 15-09-2015 à 15:25:30    

Golbam a écrit :

D'où une question qui, pour moi, a toute son importance : est-ce que pour vous ces tests seront déterminants pour passer par exemple d'une 970 à une 380x si la domination AMD est confirmée ? Je ne pense pas que les résultats entraînent de gros changements de camp surtout sur une génération de CG qui sera déjà bien entamée.


 
A mon avis non.
 
Le facteur temps est essentiel. Personne n'est dupe, les cartes DX11 seront forcément larguées quand DX12 sera pleinement opérationnelle (avec les 14/16nm de gravure et la HBM2).
 
Mais cette transition ne va pas se faire en 3 semaines, ça va prendre plus d'un an (grand minimum). Et même après, les grosses cartes DX11 ne seront pas ridicules (très bonne puissance de calcul).
 
La vrai question, c'est plutôt acheter en 2015, ou attendre 2016.  ;)  
 
La 970 restera une excellente carte et un très bon choix pour jouer dans les 2 prochaines années. La question de "l’après" se posera quand on y sera.
 
Les possesseurs de HD7950 et GTX 670 auront surement une bonne raison de faire l'upgrade dans 1an et demi.  ;)


---------------
Parce que je suis un troll : j'ai déconseillé Winrar sur clubic.
Reply

Marsh Posté le 15-09-2015 à 15:32:46    


 
Effectivement, je me plante complétement (faut que j'arrête de lire les commentaires et que je me concentre sur les articles sérieux).  :fou:  
 
Il me semblais tout fois qu'il y avais un gain coté CPU : http://www.gamersnexus.net/guides/ [...] -benchmark Non ?  :??:  


---------------
Parce que je suis un troll : j'ai déconseillé Winrar sur clubic.
Reply

Marsh Posté le 15-09-2015 à 15:32:53    

Crashdent a écrit :


La vrai question, c'est plutôt acheter en 2015, ou attendre 2016.  ;)  
Les possesseurs de HD7950 et GTX 670 auront surement une bonne raison de faire l'upgrade dans 1an et demi.  ;)


 
;) ;) ;)
 
Qu'on me mette du DP1.4 (parce que le 1.3 bon, voilà quoi), et des écrans 4K G sync 144 Hz 3D Radis (oui totalement kikoo et alors?) et je serai comblé.
 
Je me demande si Intel mettra du Intel HD Graphics sur ses i7-X960X pour booster dx12 ? :P


---------------
Alim Seasonic platinum SS-1200XP; Asus P8Z77-m PRO; i5-3570k @ 4.2 GHz; 16 Go DDR3; 2*2To Seagate; Intel 128 go 320 series; Samsung 250go 850 evo; SLI Asus GTX670 DCUII @ 1137 MHz; Fractal Design Define R3;
Reply

Marsh Posté le 15-09-2015 à 16:15:26    

TotalRecall a écrit :

La modération confirme [:neostranger].
Faites attention à ce que vous écrivez et évitez les informations à l'emporte pièce qui ressemble plus à des idées personnelles que des faits :sarcastic:.


C'est bien beau de poster pour dire que ça ne passe pas, mais encore faudrait il censurer pour pas que ça soit pris pour argent content par le premier lurker venu. ;o


---------------
Abordez la pente du bon côté ! \o/ Let the light surround you \o/ To bleed or not to be...
Reply

Marsh Posté le 15-09-2015 à 16:17:47    

Crashdent a écrit :


 
Effectivement, je me plante complétement (faut que j'arrête de lire les commentaires et que je me concentre sur les articles sérieux).  :fou:  
 
Il me semblais tout fois qu'il y avais un gain coté CPU : http://www.gamersnexus.net/guides/ [...] -benchmark Non ?  :??:  


Gain CPU oui. Sauf que le CPU est très rarement limitant actuellement à part dans de rares scènes dans de rares jeux qui plus est.
Bien qu'il y est du gain, donc, mais de là à dire que ça va relancer une archi, faut pas exagérer.


---------------
Abordez la pente du bon côté ! \o/ Let the light surround you \o/ To bleed or not to be...
Reply

Marsh Posté le 15-09-2015 à 16:25:10    

Le Profanateur a écrit :


C'est bien beau de poster pour dire que ça ne passe pas, mais encore faudrait il censurer pour pas que ça soit pris pour argent content par le premier lurker venu. ;o


Et puis quoi encore ? On peut intervenir pour les injures ou les trolls au premier degré, mais pour les simples divergences d'opinion ou les arguments spécieux il n'y a pas grand chose à faire, c'est un forum ici, pas une école maternelle, les gens n'ont qu'à brancher leur cerveau en lisant et ne pas s'arrêter au premier message. Si par contre l'auteur insiste malgré les avertissements, il y a le bouton d'appel à la modération.


Message édité par TotalRecall le 15-09-2015 à 16:25:40

---------------
Topic .Net - C# @ Prog
Reply

Marsh Posté le 15-09-2015 à 16:27:38    

Tout à fait, merci pour la précision. :jap:
Edit pour pas surcharger la page : Non ceci ne présage pas de possibles alertes :o Bien que certains trolleurs récurent dans la cat news mériterait un ban tellement c'est puérile et saoulant... :fou:


Message édité par Le Profanateur le 15-09-2015 à 16:42:28

---------------
Abordez la pente du bon côté ! \o/ Let the light surround you \o/ To bleed or not to be...
Reply

Marsh Posté le 15-09-2015 à 16:31:00    

En lisant ta réponse je ne sais pas pourquoi j'ai l'impression que je vais bientôt recevoir une alerte modération [:joce]


---------------
Topic .Net - C# @ Prog
Reply

Marsh Posté le 15-09-2015 à 16:41:12    

Pas brillant d'appeler à la censure en France pays de la liberté.
Essaye plutôt de trouver des arguments constructifs pour expliquer le silence de nvidia sur le sujet.
Ce silence n'est il pas lourd de sens ?
Et n'oublions pas que c'est une marque qui a rajouté de la tesselation inutile dans Crysis 2 pour faire chuter les perfs des radeon quand même.
Également on est sûr qu'ils ont fait pression pour faire retirer async compute dans ashes of singularity, n'est il pas légitime de penser qu'ils le font aussi pour d'autres applications, connaissant nvidia ?

Message cité 1 fois
Message édité par LePcFou le 15-09-2015 à 16:45:15

---------------
Keyboard not found
Reply

Marsh Posté le 15-09-2015 à 16:43:25    

J'y suis pour rien (pour une fois [:rhetorie du chaos])


Message édité par Le Profanateur le 15-09-2015 à 16:43:39

---------------
Abordez la pente du bon côté ! \o/ Let the light surround you \o/ To bleed or not to be...
Reply

Marsh Posté le 15-09-2015 à 16:43:28    

LePcFou a écrit :

Pas brillant d'appeler à la censure en France pays de la liberté.
Essaye plutôt des arguments pour expliquer le silence de nvidia sur le sujet. Et n'oublions pas que c'est une marque qui a rajouté de la tesselation inutile dans Crysis 2 pour faire chuter les perfs des radeon quand même.


 
Je vois pas en quoi le fait d'ajouter une option désactivable fait chuter les perfs de quoi que ce soit. C'est comme si on te donnait un vélo et que tu as une voiture à côté et que tu te sentes obligé de prendre la vélo à la place de la voiture et qu'en suite tu râles que ça va plus lentement alors que c'est une option en plus uniquement si tu as la puissance pour... Enfin tu persistes à désigner NV comme le grand méchant.


---------------
Alim Seasonic platinum SS-1200XP; Asus P8Z77-m PRO; i5-3570k @ 4.2 GHz; 16 Go DDR3; 2*2To Seagate; Intel 128 go 320 series; Samsung 250go 850 evo; SLI Asus GTX670 DCUII @ 1137 MHz; Fractal Design Define R3;
Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed