Reprise du message précédent :
 
 
 
tu meriterai qu'on te cite dans l'ecole "la foire aux cancres" ...

Quand tu lis que les GPU Nvidia c'est de la merde le débat ne vaux plus rien à cause de kikoulol.
Des GPU qui consomme 100 Watts de moins ou plus que la concurrence et qui pourtant font mieux avec une Gen en moins je me dis on à beau critiquer et encore Nvidia je dis bravo
Quand AMD reviendra dans la course CPU/GPU on pourra vraiment commencer à faire un débats.

 
La finesse est une fonction inverse. Plus elle augmente, plus la taille diminue.
On augmente bien la finesse de gravure mais on diminue la taille de ces dites gravures.
 
Edit : Exemple avec un écran, la finesse (en DPI), plus elle augmente, plus la taille de l'écran a résolution équivalente, diminue.

Ça c'est un autre problème, pour leurs GPU non pas vraiment de retard, enfin pas en perfs brut, la conso à la limite sur un GPU beaucoup s'en moque moi le premier, je veut de la perfs pour un prix max à ne pas dépasser point la dessus c'est le géant vert qui a des leçons à prendre sur les tarifs, ça s'applique aussi au CPU pour le coup.
Y en a un peu marre de la politique du viol tarifaire  

C'est rare que les leaders d'un marché soient les moins chers, surtout quand tu n'as que 2 vrais concurrents au total...

Après t'as toujours de bonnes affaires. La 970 KFA à moins de 300, c'est un très bon prix. A l'inverse, la 980 n'a pratiquement aucun intérêt.

Mais ce n'est pas forcément mieux chez AMD avec les 390/390X alignées sur les GeForce pour des perfs similaires mais une conso x2 (et donc la dissipation/température du boitier qui va avec).
Sans même parler des 980 Ti, Nano ou autre Fury...

Je rêve d'un retour à une politique tarifaire à la 8800 GT où tu avais du haut de gamme à 220 euros... même si tu peux en trouver chez AMD avec les anciennes 290.

 
 
, t'aurais pu simplement dire , une gravure plus fine

Oui, mais regarde bien l'étymologie de ta phrase : on dit bien plus (+) fine, pas moins (-) fine, la finesse augmente donc bien.
D'ailleurs du coup, y'a plein d'articles HFR qu'il faut réécrire. Puisque dans certains me semble bien avoir vue la finesse qui diminue (etc). Me semble pas que ça soit Marc qui face l'erreur mais Damien.

 
D'ailleurs pour info, Nvidia s'est penché sur Luxmark (où les cartes AMD les battaient assez franchement et a optimisé on compilateur OpenCL). Toute l'optimisation serait dans les échanges avec la mémoire. Les devs de Luxrender se demandent d'ailleurs si du côté AMD il n'y a pas quelques chose de similaire à faire.
Pour info, en gros, sur Luxmark 3.1, une GTX980 égale désormais une Titan, qui égale une AMD Fuji et bat une AMD 390x. Pour l'instant les gens de Luxmark demandent de prendre tout avec des pincettes car Luxmark 3.1 (au contraire du 3.0), même si sous OpenCL, est désormais optimisé purement Nvidia.

Source svp ?

 
pluzun

J'ai trouvé ca :
http://www.luxrender.net/forum/vie [...] 34&t=12359
 
En gros le render inclu maintenant des optimisations suggérées par Nvidia. Et ils conseillent de ne pas comparer les résultats du 3 avec le 3.1.
 
Mais rien qui dit que AMD ne bénéficie pas aussi des optimisations ou que cela degrade ses perfs.

Dans l'absolu, il ne dit pas que leur code est spécifiquement optimisé nV, il indique que des optimisations proposées par nV ont été intégrées.
Si c'est algorithmique, ou de la cache friendlyness, c'est grosso-modo cross-vendor.

cocto81 va nous en dire plus

 
Pas forcément. Sur luxrender, les datatset sont trop gros pour être intégrés directement dans la vram, y'a donc une partie qui est dans la ram, ça reste un cas d'usage. Du coup, si c'est de l'algo pour packer les dataset, Nvidia aura un avantage : moins d'overhead pour les transferts.
En HPC tu limite les dataset a la taille de la vram sur tes accélérateurs et tu ne les charge qu'une fois la tâche ou le travail du µkernel terminé, d'où le fait que ça soit dit "distribué" (le compilo est censé tailler les workset a la bonne taille, et l'ingé/chercheur doit coder son appli pour avoir un rendement fonction de l'archi qui est a sa disposition. Pas forcément évident, entre ceux qui font des lectures streamées directement depuis le clust de masse et ceux qui savent pas faire des workset qui utilisent maxi la taille de la vram, les profils IO pas forcément adaptés ... Le taff est difficile pour un scheduleur ou un admin HPC quand tu tombe sur des blaireaux qui codent comme des boeufs )
 
 
Mais j'attend toujours la teneur des modifs du moteur pour en jauger. A vue de pif, je vois pas quelles modifs peuvent impacter un µK censé être utilisable dans un maximum de cas et pseudo commercial, même si utiliser pour des bench. Je vois pas l'intérêt de luxrender de faire ça sachant qu'ils sont eux même en concurrence face a d'autres solutions d'accélération-coucou adobe ?- juste pour faire plaisir a nvidia sur un benchmark qui utilise leurs moteur (luxmark n'est pas censé pouvoir influencer luxrender pour le moteur quoi)

Si c'est de l'algo pour packer les dataset, à priori c'est générique.
 
Sauf si c'est un codepath spécifique nV, mais c'est pas ce qui est sous-entendu par:
 
"Among other features, it includes some OpenCL optimization suggested by NVIDIA to LuxRender project"

cocto81

 
Sans la réponse de cocto81, on en sait rien et tout au plus, on peut faire des suppositions. (enfin, si, les optimisations doivent pas être si violentes que ça, mais aucunes traces.)

Il vous fait une réponse en 2 tomes, il faut savoir attendre un peu !

C'est très simple. Si on lit le site Luxmark, les forums, rubrique 3.1 du dev.
La seule amélioration est dua au nouveau moteur Luxrender + l'intervention de Nvidia pour en optimiser les règlages.
C'est la le problème.
je me réfère à Cycles sur Blender.
Cycle a été codé sur Cuda par des gens qui faisaient du Cuda. Ces mêmes gens ont porté le code Cuda tel quel sur OpenCL.
Résultat : ça plantait dur AMD, ça marchait sur Nvidia (en plus lent). Conclusion de ces gens : la plateforme AMD est buguée.
Passage d'un type de chez AMD pour leur apprendre à coder l'OpenCL tel qu'il doit être codé... et ça marche.
Le truc c'est qu'un fois les moteur OpenCL au point, les gens trouvaient qu'AMD était sensiblement plus lent que Nvidia, mais qu'en jouant sur les tiles de rendu AMD dépassait en vitesse Nvidia dans les meilleurs règlages de cette dernière. Mais les deux règlages sont globablement opposés.
 
Alors, Luxmark est un bench qui en fait prérègle le rendu sur Luxrender de différentes scènes, de légère à lourde. Avec les mêmes règlages on avantage AMD ou Nvidia ou on désavantage les 2... bref, dans ces conditions c'est pas fiable si l'une des marque donne les "bons règlages". Il da  

Ouais donc rien de nouveau que ce que l'on a déjà dit.  
 
Les sources pour : les devs déconseillent la 3.1, tu les donne toujours pas.
Pas plus que celle, comme quoi le travail pour optimiser pour Nvidia a degradé l'optimisation AMD.

Comme d'hab... cocto81 rajoute sa part d'interprétation sur ce qu'il a vu. Et encore une fois c'est biaisé anti-nVidia... En l'occurrence c'est pas nVidia qui a mis ses mains sur le moteur, il ne semble pas y avoir de baisse de perfs sur les Radeon, et quand la situation inverse arrive la situation est un peu plus complexe que des devs incompétents...
 
Enfin bon, j'imagine qu'on va bientôt voir arriver un nouveau vecteur pour tes intox...

Merci d'insister pour me demander une réponse documentée.
 
Voilà la première optimisation qui est l'usage du cache. Cet usage fait gagner 10-20%, voire 25% sous Linux à Nvidia. Très insuffisant pour presque doubler les perfs.
http://www.luxrender.net/forum/vie [...] 34&t=12223
 
Nvidia a suggéré aussi l'usage sur ses dernières variantes OpenCl (ce qui prouve un intérêt clair de Nvidia vers ce test) de l'option
-cl-fast-relaxed-math et d'autres optimisations de compilation (OpenCL overclocking sur Luxrender) suggérées aussi par Nvidia.
http://www.luxrender.net/forum/vie [...] =8&t=12265
 
 
Cette option augmenterait, sur les derniers pilotes OpenCL Nvidia, les perfs en calcul officiellement de 16% sur Nvidia contre 3% sur AMD (sur AMD ça n'a aucun intérêt donc car AMD semble être IEEE d'office et interdit même certains de ces calculs non IEEEE par des erreurs NAN).
En réalité une augmentation par rapport à l'usage IEEE de 35% sur les tests Luxmark 3.1 avec les nouveaux pilotes Nvidia sur Maxwell.
 
De quoi s'agit-il ?
Luxrender est un moteur de rendu réaliste. Il compte sur des calculs de lumière juste, c'est à dire à la norme IEEE. De fait l'OpenCL et l'usage GPU en tant que processeur mathématique ne pouvait à l'origine se démarquer de l'obligation des cartes d'être aux normes IEEE.
L'OpenCl optimization se débarrasse de cette justesse de calculs, prabablement totalement chez Nvidia (au vu des différences).
Quand on connait les problèmes de règlage de qualité au poil pour gagner du temps sans générer des artefacts sur les rendus réalistes, il est exclu de procéder ainsi en pratique (ça peut s'avérer rapidement contre-productif).
Or la scène et la qualité du rendu restant le même, se priver d'un calcul juste relève désormais d'un calcul à qui peut fournir un moteur qui ne plante pas quitte à rendre n'importe quoi.
Autant dire que ce que suggère Nvidia sur Luxmark c'est de truander ! Ca démontre l'esprit dans lequel fonctionne cette marque.
 
 
Affligeant !
 
D'où le bémol des devs sur Luxmark 3.1 par rapport à 3.0, pas comparables plutôt que l'un supplantant l'autre. Mais ils insistent pas trop dessus.
http://www.luxrender.net/wiki/LuxMark
J'imagine que l'équipement "de test" gracieusement envoyé par Nvidia à cette fin (chose documentée) leur a suffit pour mettre un bémol à cette modification dans la rigueur de la procédure.
A noter qu'un testeur postant sur le site Luxmark est libre de compiler son noyau de test avec ses options et que vsiblement les cartes Nvidia postées ne s'en sont pas privées (optimisation cache mémoire + usage de calculs de moindre précision + overclocking de folie correspondent bien uniquement ensemble au x2 constaté).
 
Parce qu'on note aussi que pour qu'une Nvidia GTX 980 Ti (les Titan X semble pas pouvoir à cause des 12Go de ram) avec ces bidouilles logicielles, accroche une AMD Fury, il lui faut être overclockée à 1540Mhz (vitesse mémoire non documentée)
Pour qu'une GTX 980 puisse accrocher un R9 2/390X, être overclockée à plus de 1400Mhz et avec la RAM à 8Ghz.
 
On a donc affaire effectivement à une véritable optimisation de l'usage mémoire (semble-t-il), relativement minime finalement, plus un contournement des règles de calcul (passons au 16bits... tant qu'on y est), plus un overclock indécent pour un usage pro normal (les cartes pro que ce soit chez Nivida ou AMD sont pour info underclcokées par rapport à leur variante domestique).
 
Quand on sait que Luxrender et à peu près tout ce qui tourne sous OpenCl n'a un intérêt que si les calculs sont justes et si la carte est fiable (donc non overclockée voire underclockée pour garantir la fiabilité à pleine charge), autant dire qu'on a affaire au même combat qu'entre un AMD FX 9590 contre un i7 4790k où une AMD FX ferait soi-disant jeu égal.
Le problème c'est que les fans Nvidia, à l'image des fans Apple sont toujours là et n'en ont que faire, tout argument même totalement biasé leur suffit. Et Nvidia compte beaucoup sur eux ! C'est cet esprit qui m'incommode. Je m'en fous que ce soit AMD ou un autre MS etc

Donc si je te lis bien (enfin tes liens parce que toi, c'est imbitable), c'est des améliorations qui bénéficie au 2, mais on doit les recaller parce que l'un des deux en bénéficie plus ?

A part l'usage des pointeurs qui bénéficie à l'usage du cache chez Nvidia (probablement AMD doit pouvoir trouver des trucs équivalents), le reste c'est de la truande.
On a affaire à exactement la même affaire que lors des petites tricheries sur les gammes Nvidia FX. D'ailleurs on ne sait toujours pas si c'est pas ce qu'il se passe dans les jeux sous DirectX11 avec les cartes Nvidia. Avec la HD et plus, c'est très difficile d'aller voir et analyser les images, les vrais FPS complets affichés etc. alors que des APIS fermées purement Nvidia trainent dans ces jeux.
 
Quand un GPGPU calcule avec des résultats pas clairs où s'arrête l'optimisation. Dans ces conditions, comme je l'ai dit pourquoi pas faire du calcul flottant 32 bits en n'utilisant le GPU que sur 16 bits ?
Parce que je vois mal les dev Luxmark vérifier les phénomènes des erreurs de calcul des cartes Nvidia ou autre.
 
Comme je le disais, ces dégradations des résultats des calculs coûtent au rendu final. Pour compenser et obtenir un résultat similaire sous Luxrender, il faudrait augmenter d'autres valeurs (donc le temps de rendu). Quand vous avez des photons qui traversent des angles de mur, je vous garanti que parfois il faut multiplier par 10 le temps de calcul pour s'en débarrasser.
Et hors du standard iEEE il n'y a plus de règle. Donc quand on s'en prive, ça peut aller jusqu'où on veut dans l’imprécision pour gagner en vitesse.
 
Donc la mesure des performances devient biaisée.
 
Donc Luxmark 3.1 avec de tels règlages, hérités des possibilités de Luxrender 1.5 (qui permet de faire donc du rendu biaisé) n'est plus une référence.
Il faudrait qu'il puisse imposer des règlages IEEE pour les calculs, donc probablement fonctionner exclusivement à partir d'un binaire précompilé identifié dans ce sens.
C'est un peu comme si on faisait une course de F1 entre deux équipes, l'une qui n'a le droit que de rouler en voiture de F1 sur la piste, et l'autre, si elle n'arrive pas à fabriquer de F1, a droit au 4x4 avec le passe-droit de couper piste. On a l'impression que Nvidia fait toujours partie des seconds, quand elle est incapable de produire la première.

Tu ne l'as pas démontré et aucune de tes sources ne le fait d'ailleurs. Elles disent qu'il y a un risque que cela dégrade le résultat. Mais que ce risque est le même pour les deux constructeurs. Donc on reste avec un résultat qui est utilisable pour comparer deux cartes.
 
Navré mais quand je te lit, j'ai vraiment l'impression que ce qui te gène, c'est le fait que Nvidia a une meilleur augmentation de ces scores que AMD. (tout en restant derrière).
 
Tu te gardes bien d'ailleurs de dire qu'une de ces optimisations est aussi suggéré par Intel.
 
Et au passage, les options compilateurs peuvent etre desactivé dans la derniere version du bench.

Merci mais sur le second lien, il est indiqué "This is also the reason why "overclocking" is not enabled by default."

De plus rien de tout ça n'indique que "les gens de Luxmark demandent de prendre tout avec des pincettes"

@cocto81:
J'aime bien ton analogie entre la F1 et le 4x4 mais faut y rajouter un élément primordiale, cet course se passe dans une immense tunnel ou seul le départ et l'arrivée sont visible.
L'utilisateur s'en fout royalement de qui a tricher ou pas, il veut voir celui qui gagne, qu'importe la manière ça c'est transparent.
Un peu comme un proprio de VW ça a passionner les foules 2 semaines est basta pour rester dans l'analogie automobile
 

Faudrait surtout y rajouter que les deux équipes ont droit au 4x4 et au tout terrain et que les deux utilisent ces deux droits. Sauf qu'il y en a une qui a l'air plus efficace que l'autres en tout terrain.

Aussi, donc au deux à se demerder à améliorer leur point faible respectif en fait au lieu de se plaindre sur les règles  

cocto81 a quand même raison sur le côté fiabilité des cartes et les unsafe optimizations, pour un usage pro. Un vrai test serait avec des cartes pro @stock et sans ce flag, mais pour la grande majorité des gens Luxmark c'est comme 3DMark...

Dans le lien qu'il donne, la carte est aux paramètres d'usine et cela empêche pas le +16% chez Nvidia 980 et le +3% sur amd 290x. C'est un peu un faux débat les résultats des cartes overclockés. Ce n'est pas ce résultat qui est repris dans les tests de matos.
 
Pour le flag, il est activé des deux cotés donc c'est encore un faux débat. Si il était activé que pour 1 coté : OK le test voudrait rien dire. Mais la, il l'est pour les deux si on coche la case (et pour aucun si elle est pas cochée). On compare donc bien des situations équivalentes.

 
Quelques remarques;
 
- Le cache c'est le nerd de la guerre, toute optimisation ALU ne ressort que si on est dans une zone de code dcache-friendly.
 
- C'est exactement pareil pour les cpu, on compile souvent avec plus ou moins de degrés de consistance sur les calculs fpu.
  => suivant ce que l'on cible on autorise le compilateur à se permettre des optimis qui l'arrange quand on cherche à aller vite.
       quitte à remanier le code pour être encore plus optimisation-friendly, que ce soit en perfs ou en consistance.
       (le SSE peut s'avérer inférieur en précision au fpu x87 historique en passant)
       (a savoir qu'en général, c'est optimisations à fond, et que enforcer du IEEE-strict peut faire baisser la précision ^^)
 
Moi ce que j'en comprends c'est que nV a un optimiseur de code (en mode agressif) "peut-être" supérieur à AMD, et qu'ils poussent les gens à s'en servir.
 
Ensuite faut pas oublier que Luxmark c'est du rendu en virgule flottante, et par design oui la virgule flottante est piégeuse, et qu'un rendu c'est approximatif.
 
Donc la question est : est-ce que l'activation de l’émission de code flottant en mode relaxed a un impact négatif sur le rendu ? (il peut avoir un impact positif, drôleries des calculs flottants)

Justement, rien ne garanti que ça soit le cas. Par exemple, en DX/OGL, la gestion des flottants dé-normalisés est différente entre AMD/Intel qui respectent le standard IEEE et nVidia qui arrondi à zéro. C'est pas très important pour du jeu vidéo mais dans un contexte où la précision compte plus, nVidia est peut-être plus pénalisé que les autres à faire le calcul correct. Et l'avantage de forcer le standard IEEE est qu'au moins les erreurs sont les mêmes sur toutes les cartes. Dans un contexte où on utilise Luxrender, ce sont des détails qui comptent. Après, peut-être que les compilos ne sont pas si aggressifs et les optimisations n'impactent pas le rendu, mais on n'en sait rien (et comme dit bjorne, rien n'empêche qu'un code optimisé soit plus précis et plus rapide à la fois...).
 
Bref, c'est une bonne chose que ce flag soit activable par l'utilisateur, c'est à lui de choisir le compromis qu'il veut.

Mon premier post sur la question était pour saluer le "retour" de Nvidia... avec de regarder dans le détail du comment.
Une partie des optimisations sur plateforme Intel font planter le moteur...
Les options peuvent être désactivées mais tout l'intérêt de Luxmark c'est de montrer un résultat clair, or on ne sait pas puisqu'il n'y a pas de filtre selon l'option de compilation utilisée, et en regardant les gains obtenus par les testeurs sur le forum avec les cartes Nvidia, ça correspond parfaitement à l'utilisation de "l'optimisation".
 
Je souligne que le moteur Luxrender est très sensible à la précision de calcul. Certains estiment même qu'il devrait tourner en double-flottants, mais bien sûr ça serait overkill. L'un des éléments étant par exemple le passage de photons au travers des limites de surfaces accolées ou de surfaces fines, par légère erreur de calcul.
Il me semble d'ailleurs qu'on peut activer les double-flottants à la compilation.
 
Je peux pas tester actuellement les gains sur Nvidia (maxwell), car ces cartes étant installées soit sur Vista, soit sur Windows 7 que je ne veux pas updater (avant de savoir filtrer le passage forcé en W10 en janvier), il me semble que le moteur Luxrender 1.5 (qui plante donc) demande une installation de certaines API non compatibles Vista et demandant un update de W7... donc je me fie à tout ce que j'ai lu sur les forums Luxrender et Luxmark.
C'est d'ailleurs le but normalement de Luxmark, de permettre de décider quelle carte graphique on doit utiliser pour Luxrender selon ses besoins, porte-monnaie, et d'autres facteurs (taille slim, conso...), donc à priori regarder les résultats sur leur site avant d'acheter la carte.

Excepté que tu vas devoir revendre ta 980 dans un futur lointain, telle une vulgaire 3dfx aujourd'hui, avant que les quelques Watts en plus d'une 290x t'aient coutés en électricité la différence de prix à l'achat. Achat basé sur des graphiques impliquant un taux de frames per secondes, dans un cas comme dans l'autre, imperceptible par ton cerveau. Bref non à rage

Lointain, lointain, l'année prochaine tout sera revendu à pas cher ^^

Je voulais être sympa