C'est un peu Big Fish.

Asta a écrit :

Petite question générale et hors sujet du coup :

J'avais cru comprendre que les Tflops c'était juste les opérations en virgule flottante par seconde. Donc je suppose que oui si tu compares que ça ce sont les mêmes opérations mais comparer des Tflops de deux intégrations d'archi différentes (en terme de résultat à l'écran) c'est une autre histoire non ?

Peu importe le Tflops est une unité de mesure pour une puissance brute.
La différence se fait sur les features intégrés en natif ou pas.
Sachant que l'APU de la switch est X1, qui est de base un APU tablette modifié cette dernière et sans doute plus récent que les APU AMD de la One et la PS4 standard (la pro est à part).
Donc elle aura des capacités graphiques que n'ont pas en natif la PS4 et la One mais au final la puissance brut sortable de la Switch reste inférieure aux deux consoles précitées. Après je peux me tromper et si il y a des gars calés techniques, ils pourraient infirmer ou confirmer.

papysoupape a écrit :
"Le pire dans tout ça c'est que ce même Nico Augusto a engendrer des trucs moins bien fun :("

Oui c est sur. Ce qui me parait quand même un peu fou dans l histoire c est la solitude du gars. Je n ai pas encore vu de soutiens francs et massifs de gens du "milieu", de développeurs, de studios ou de gros sites. Une grande partie du net vidéoludique galactique émet d énormes doute sur son projet et personne ne monte au créneau.

Le gars s expose tout seul sur une énorme annonce.

Alors ok d autres l on fait avant façon peter molyneux mais on parle de qui la? Qu est ce que le mec a pondu de jouable pour le commun des mortels et avec qui?
Soyons patient car je suis certain que d ici peu de temps, quand tout ça aura fait pschiit et sera retombé certains anciens collaborateurs viendront expliquer pourquoi ils l ont laissé aller au charbon tout seul. --->viendez le faire sur factor

En même temps tu serais un développeur reconnu dans le JV t'irais défendre le gars toi?
Il n'y a que Laura Kate Dale qui a de suite déminé le terrain, en disant qu'il n'avait pas de kit de développement Switch et que le truc tourne sur PC.

Asta a écrit :

katsumotosama a écrit :

Genre les leaks des specs de la Switch, qui d’après Augusto se situerait entre une PS4 et une PS4 pro (si si je vous jure). Seulement depuis les affirmations de Digital Foundry qui situe la switch entre 0.350Tflops en mode portable et 0.700 au max en mode dock, ben certains Fanboys N (pour être gentil) affirment maintenant que 1Tflops chez Nvidia (puisque APU équipant la Switch) et 1Tflops chez AMD (PS4/One) ben c'est pas les mêmes Tflops.

.

Petite question générale et hors sujet du coup :

J'avais cru comprendre que les Tflops c'était juste les opérations en virgule flottante par seconde. Donc je suppose que oui si tu compares que ça ce sont les mêmes opérations mais comparer des Tflops de deux intégrations d'archi différentes (en terme de résultat à l'écran) c'est une autre histoire non ?

Je vais faire plus simple que katsumotosama :
C'est aussi con que de comparer 1 kilo de patates et 1 kilo de carottes : 1 kilo reste 1 kilo.

Oui MrPapillon, c'est exactement ça.

Nico est censé par moment dans l'interview original. Mais c'est le genre de personnage que tout le monde a croisé dans une soirée au moins une fois dans sa vie. Une remarque ci et là intelligible, un gars qui se bouge clairement par moment ; qui indéniablement a concrétisé des trucs...

Mais malheureusement un peu trop extraverti, se sent obligé d'en faire des caisses de tout alors que bien d'autres personnes dans la salle ont des parcours similaire et savent rester humbles et reservés. Que tu parles de la technique de semi des graines de Papaye, de micro-chirurgie de la main droite ou de l'attraction gravitationnelle du 162ème particule de glace des anneaux de Saturne... ce mec là il a son avis, parce que lui il a planté ses papayes en même temps qu'il opérait une main droite en équilibre sur une particule de glace de l'anneau de Saturne.

Ce mec là dans la soirée, c'est celui dont tout le monde se souvient en haussant les épaules et en disant à demi-mot "il était un peu reloud non ?". Et c'est dommage, parce que dans le fond, il a des trucs intéressants à raconter et à apprendre... mais d'en faire des tas, ça rend le personnage vraiment agaçant mais aussi très peu crédible.

Et je suis vraiment désolé de dire ça, mais d'avoir creusé un peu tout ce qu'a fait Nico... c'est typiquement ce que je ressens quelque soit le contenu que je regarde. De la présentation de son studio à L.A. à son interview par Shareplayers.

Ca serait très bien que son projet réussisse pour lui, je serais bien le dernier des cons à vouloir qu'un mec dans le jv se mange. Mais ça ne changera pas le personnage pour autant.

sese_seko a écrit :
Je vais faire plus simple que katsumotosama :
C'est aussi con que de comparer 1 kilo de patates et 1 kilo de carottes : 1 kilo reste 1 kilo.

Aucune info sur la switch, ni sur la comparaison gpu ps4/gpu switch (don't quote me).. mais je vais mettre de l'eau dans ton vin.

En pratique les indications de flops sont surtout intéressante sur des longues tendances (progression en flops depuis l'invention du microprocesseur) et pour des comparaisons entre même architecture (les quirks d'une archi se retrouvent également dans la même famille). Dans la nature, les programmeurs ne se fient pas totalement aux flops surtout si ça demande des concessions diverses et variées (et/ou une programmation fondamentalement différente : cf multithreading sur un CPU et multithreading sur un GPU, et parallélisation sur un superordinateur distribué). Il y a des tentatives de benchmarks universels mais c'est évidemment très difficile à faire sans tomber dans des pièges liés aux spécificités d'un bench.

Exemple tout con :


Les gains entre le même CPU et le même GPU (donc le même nombre de flops de chaque côté) va de 6x à 30x (et il y a des benchs non présentés ici qui ne montreraient aucun gain voire une perte). Pourquoi une telle différence ? Parce que le bench à 30x joue avec un algo qui est particulièrement adapté au hardware du GPU et/ou le constructeur a intégré des instructions spécifiques pour accélérer cette charge (et vice versa si le constructeur CPU a ajouté les instructions nécessaires, cf sse/avx).

Un bon exemple côté CPU, c'est le Cell de la PS3 :
- un core/CPU principal avec des fonctionnalités manquantes qui défoncent les perfs.
- des cores/CPUs auxiliaires méga rapides mais hyper limités et avec des transferts mémoires manuels à faire entre eux.

Comparer ça avec un CPU PC n'avait aucun sens.

Il n'y a pas un repost pour cette video ?
Je l'ai raté.
Je suis tristesse

Fakir Bleu a écrit :
Il n'y a pas un repost pour cette video ?
Je l'ai raté.
Je suis tristesse

C'est très facile de la retrouver sur YT

Altavista marche beaucoup moins bien ces derniers mois

ok trouvay. Merci. A moi la sortie du marasme.

Tiens y'a des soldes sur le marketplace UE, on va peut être avoir un nouveau teaser bientôt ?

LeGreg a écrit :

sese_seko a écrit :
Je vais faire plus simple que katsumotosama :
C'est aussi con que de comparer 1 kilo de patates et 1 kilo de carottes : 1 kilo reste 1 kilo.

Aucune info sur la switch, ni sur la comparaison gpu ps4/gpu switch (don't quote me).. mais je vais mettre de l'eau dans ton vin.

En pratique les indications de flops sont surtout intéressante sur des longues tendances (progression en flops depuis l'invention du microprocesseur) et pour des comparaisons entre même architecture (les quirks d'une archi se retrouvent également dans la même famille). Dans la nature, les programmeurs ne se fient pas totalement aux flops surtout si ça demande des concessions diverses et variées (et/ou une programmation fondamentalement différente : cf multithreading sur un CPU et multithreading sur un GPU, et parallélisation sur un superordinateur distribué). Il y a des tentatives de benchmarks universels mais c'est évidemment très difficile à faire sans tomber dans des pièges liés aux spécificités d'un bench.

Exemple tout con :


Les gains entre le même CPU et le même GPU (donc le même nombre de flops de chaque côté) va de 6x à 30x (et il y a des benchs non présentés ici qui ne montreraient aucun gain voire une perte). Pourquoi une telle différence ? Parce que le bench à 30x joue avec un algo qui est particulièrement adapté au hardware du GPU et/ou le constructeur a intégré des instructions spécifiques pour accélérer cette charge (et vice versa si le constructeur CPU a ajouté les instructions nécessaires, cf sse/avx).

Alors soit chuis plus beurré que je le pense, soit t'es en train de me dire que 1kg de patate c'est mieux qu'1kg de carotte pour faire du hachi-parmentier. T'as sans doute raison, mais là on passe dans le domaine de la cuisine : untel peut faire un meilleur plat q'untel, mais la matiére de base reste la même.
Pour reprendre ton joli graphe, en partant du fait que ce sont des cpu/gpu différents mais de même puissance, je ne vois pas pourquoi tu dirais que le couple cpu/gpu 30x est meilleur que le 8X soit prétexte qu'il y a une appli optimisée, et une autre codée avec mon cul.

M'enfin, voila ce que j'ai pu comprendre, je vais me coucher, chuis crvé. Joeyeux noel.

Un exemple concret qui montre que les Tflops ne se valent pas et que les fans de Nintendo ont peut-être raison d'espérer : la GTX 1060 d'NVIDIA avec ses 4.4 Tflops bat la RX 480 d'AMD qui en a 5.8 dans pratiquement tous les jeux, tout simplement parce que l'architecture Pascal est plus efficace (en DirectX 11 du moins).

sese_seko a écrit :

LeGreg a écrit :

sese_seko a écrit :
Je vais faire plus simple que katsumotosama :
C'est aussi con que de comparer 1 kilo de patates et 1 kilo de carottes : 1 kilo reste 1 kilo.

Aucune info sur la switch, ni sur la comparaison gpu ps4/gpu switch (don't quote me).. mais je vais mettre de l'eau dans ton vin.

En pratique les indications de flops sont surtout intéressante sur des longues tendances (progression en flops depuis l'invention du microprocesseur) et pour des comparaisons entre même architecture (les quirks d'une archi se retrouvent également dans la même famille). Dans la nature, les programmeurs ne se fient pas totalement aux flops surtout si ça demande des concessions diverses et variées (et/ou une programmation fondamentalement différente : cf multithreading sur un CPU et multithreading sur un GPU, et parallélisation sur un superordinateur distribué). Il y a des tentatives de benchmarks universels mais c'est évidemment très difficile à faire sans tomber dans des pièges liés aux spécificités d'un bench.

Exemple tout con :


Les gains entre le même CPU et le même GPU (donc le même nombre de flops de chaque côté) va de 6x à 30x (et il y a des benchs non présentés ici qui ne montreraient aucun gain voire une perte). Pourquoi une telle différence ? Parce que le bench à 30x joue avec un algo qui est particulièrement adapté au hardware du GPU et/ou le constructeur a intégré des instructions spécifiques pour accélérer cette charge (et vice versa si le constructeur CPU a ajouté les instructions nécessaires, cf sse/avx).

Alors soit chuis plus beurré que je le pense, soit t'es en train de me dire que 1kg de patate c'est mieux qu'1kg de carotte pour faire du hachi-parmentier. T'as sans doute raison, mais là on passe dans le domaine de la cuisine : untel peut faire un meilleur plat q'untel, mais la matiére de base reste la même.
Pour reprendre ton joli graphe, en partant du fait que ce sont des cpu/gpu différents mais de même puissance, je ne vois pas pourquoi tu dirais que le couple cpu/gpu 30x est meilleur que le 8X soit prétexte qu'il y a une appli optimisée, et une autre codée avec mon cul.

M'enfin, voila ce que j'ai pu comprendre, je vais me coucher, chuis crvé. Joeyeux noel.

aeio a écrit :
Un exemple concret qui montre que les Tflops ne se valent pas et que les fans de Nintendo ont peut-être raison d'espérer : la GTX 1060 d'NVIDIA avec ses 4.4 Tflops bat la RX 480 d'AMD qui en a 5.8 dans pratiquement tous les jeux, tout simplement parce que l'architecture Pascal est plus efficace (en DirectX 11 du moins).

Oui mais si je ne me trompe pas, les Flops indiquent quand même ce que tu pourras faire en nombre de triangle calculés par le processeur et le GPU non?

jOYEUX NOEL !!!

https://www.facebook.com/Nico.Augus/photos/pb.125444710925888.-2207520000.1482502443./1314911998645814/?type=3&theater

katsumotosama a écrit :
Oui mais si je ne me trompe pas, les Flops indiquent quand même ce que tu pourras faire en nombre de triangle calculés par le processeur et le GPU non?

Comme je disais c'est parfois assez dur de comparer entre archis différentes et entre charges différentes. Par exemple si tu as des opérations vectorielles ou SIMD (single instruction multiple data), tu vas compter le nombre de mul+add (multiplication et addition) faisable si tu arrives à vectoriser assez bien. Une charge peut donc faire complète utilisation de la vectorisation et une autre arriver seulement à utiliser 1/10 des unités de calcul (est-ce que ton programme fait de nombreuses opérations similaires sur un grand nombre de données sans branchement ou avec prédication simple).

La charge graphique habituellement se prête assez bien à la vectorisation (ce qui donne une partie de l'avantage des GPUs sur les rasterizer software), mais si tu as des "bulles" dans ton pipeline ou des triangles mal embouchés ou si la charge dépend plus de la bande passante ou du nombre d'unités COLOR OUTPUT que de nombre d'unités SHADER ALU, tu peux te retrouver avec des problèmes d'utilisation.

Une distinction fréquente en architecture CPU et GPU c'est la notion de Very Long Instruction Word. L'idée que si tu rends la parallélisation explicite tu compliques la tâche du compilateur/assembleur mais tu facilites la tâche du hardware à l'exécution (qui est généralement le benchmark utilisé). Bien exploité ça peut augmenter le taux d'utilisation des unités, mal exploité ça a l'effet inverse (le compilateur n'arrive pas à détecter les dépendances parce que le langage utilisé est de trop haut niveau ou simplement la charge ne se prête pas aux options disponibles).

Chaque décision du design du hardware est une longue série de compromis, parallélisme d'instructions explicite ou sériel (à l'intérieur d'un même thread sachant qu'il peut y avoir un millier de threads en lock step) ou parallélisme automatique, quelle taille pour le fichier de registres, privilégier les ALU ou les TEX, gestion des threads à gros grain ou petit grain (sachant que ça a des effets positifs ou négatifs sur la latence mémoire et/ou la taille du fichier de registres, plus la taille du dispatcher d'instructions par unité de calcul qui coûte des transistors). Effet sur la programmabilité, sur la performance globale (sur un grand nombre d'applications), sur la performance par transistor, par watt dépensé, etc.

Personnellement je ne sais rien sur la Switch, (même si je pense que comme d'hab, certains fanboys Nintendo oublient qu'on parle de Nintendo).

Je réagissais juste à l'argument inverse que "1 flop c'est 1 flop" et que donc on pourrait aisément comparer des archis diverses sur un bout de nappe. (la situation xboxone/ps4 est un peu particulière parce que pour la première fois deux consoles sorties à peu près en même temps utilisent un combo CPU/GPU très comparable).

Sur le papier, un avantage d'une console c'est que le programmeur de jeu a une archi fixe dont il connaît les forces et les faiblesses et donc il peut s'il veut y consacrer du temps adapter la charge (donc le contenu, les algos de rendus, la complexité des modèles, des textures et des shaders) à une architecture particulière pour augmenter le ratio image qualité/cycle d'horloge. C'est un argument qui s'applique à toutes les consoles que ce soit la Xone, la PS4, la Switch etc. Dès que les outils sont adaptés pour exposer la complexité du hardware au programmeur sans le rendre fou. En théorie donc le programmeur peut plus facilement cibler le pic de flops (avec le caveat que pic de flops != pic de qualité d'image si il y a besoin de faire certains compromis à ce niveau).

En pratique ce n'est pas toujours aussi simple. Par exemple la PS2 avait une architecture exotique ce qui fait que le contenu développé en commun avec une autre plateforme aurait pu avoir du mal à atteindre la parité en terme de qualité d'image. Mais avec quelques efforts certains effets possibles sur PS2 n'étaient simplement pas imaginables sur PC ou autre plateforme concurrente (Gamecube, première xbox). Et vice et versa. En pratique tout ce que ça fait c'est que ça donne du grain à moudre aux fan boys des deux camps. Même si au final le grand public finit par choisir un "gagnant" en achetant une des plateformes en plus grand nombre et ce n'est pas toujours celle qui a reçu le plus de boutons cochés dans ce genre de discussion.

J'ai rarement entendu parler de flops chez des devs jeux. Je crois que tout le monde s'en fout. C'est plus pour les gens qui font du calcul scientifique et qui ont des besoins plus simples.
On veut savoir la puissance approximative, et surtout le reste des specs, les fonctionnalités, l'archi dans les consoles, etc... En fait, surtout s'il y a des gros points faibles et des gros points forts. En général pour le CPU, il faut pas qu'il y ait de gros points faibles, et pour les GPUs, c'est un ensemble de compromis (je suis pas programmeur graphique, et Le Greg explique mieux que moi). Par contre la mémoire c'est un poil plus important.

En fait, comme l'a dit je sais plus qui, le plus important c'est les algos. Les algos pas forcément en fonction des architectures en plus. La plupart des optims dans un jeu, c'est de choisir un algo à la place d'un autre. On a très peu le temps à mettre pour s'attarder sur des petits détails. Du coup, comme un algo ne maximise pas forcément chaque architecture, ça fait une couche de plus qui cache les perfs "métal" simplistes.

En plus, d'une manière générale, les perfs CPU sont très dépendantes du contexte. Ça dépend de ce qu'il y a déjà dans la cache, des calculs précédents, etc... Un CPU va exécuter plein d'opérations en parallèle (pipeline, vectoriel) et faire des prédictions (cache, branching, etc...). C'est extrêmement rare de tenir compte de tout ça.

LeGreg a écrit :

katsumotosama a écrit :
Oui mais si je ne me trompe pas, les Flops indiquent quand même ce que tu pourras faire en nombre de triangle calculés par le processeur et le GPU non?

Comme je disais c'est parfois assez dur de comparer entre archis différentes et entre charges différentes. Par exemple si tu as des opérations vectorielles ou SIMD (single instruction multiple data), tu vas compter le nombre de mul+add (multiplication et addition) faisable si tu arrives à vectoriser assez bien. Une charge peut donc faire complète utilisation de la vectorisation et une autre arriver seulement à utiliser 1/10 des unités de calcul (est-ce que ton programme fait de nombreuses opérations similaires sur un grand nombre de données sans branchement ou avec prédication simple).

La charge graphique habituellement se prête assez bien à la vectorisation (ce qui donne une partie de l'avantage des GPUs sur les rasterizer software), mais si tu as des "bulles" dans ton pipeline ou des triangles mal embouchés ou si la charge dépend plus de la bande passante ou du nombre d'unités COLOR OUTPUT que de nombre d'unités SHADER ALU, tu peux te retrouver avec des problèmes d'utilisation.

Une distinction fréquente en architecture CPU et GPU c'est la notion de Very Long Instruction Word. L'idée que si tu rends la parallélisation explicite tu compliques la tâche du compilateur/assembleur mais tu facilites la tâche du hardware à l'exécution (qui est généralement le benchmark utilisé). Bien exploité ça peut augmenter le taux d'utilisation des unités, mal exploité ça a l'effet inverse (le compilateur n'arrive pas à détecter les dépendances parce que le langage utilisé est de trop haut niveau ou simplement la charge ne se prête pas aux options disponibles).

Chaque décision du design du hardware est une longue série de compromis, parallélisme d'instructions explicite ou sériel (à l'intérieur d'un même thread sachant qu'il peut y avoir un millier de threads en lock step) ou parallélisme automatique, quelle taille pour le fichier de registres, privilégier les ALU ou les TEX, gestion des threads à gros grain ou petit grain (sachant que ça a des effets positifs ou négatifs sur la latence mémoire et/ou la taille du fichier de registres, plus la taille du dispatcher d'instructions par unité de calcul qui coûte des transistors). Effet sur la programmabilité, sur la performance globale (sur un grand nombre d'applications), sur la performance par transistor, par watt dépensé, etc.

Personnellement je ne sais rien sur la Switch, (même si je pense que comme d'hab, certains fanboys Nintendo oublient qu'on parle de Nintendo).

Je réagissais juste à l'argument inverse que "1 flop c'est 1 flop" et que donc on pourrait aisément comparer des archis diverses sur un bout de nappe. (la situation xboxone/ps4 est un peu particulière parce que pour la première fois deux consoles sorties à peu près en même temps utilisent un combo CPU/GPU très comparable).

Sur le papier, un avantage d'une console c'est que le programmeur de jeu a une archi fixe dont il connaît les forces et les faiblesses et donc il peut s'il veut y consacrer du temps adapter la charge (donc le contenu, les algos de rendus, la complexité des modèles, des textures et des shaders) à une architecture particulière pour augmenter le ratio image qualité/cycle d'horloge. C'est un argument qui s'applique à toutes les consoles que ce soit la Xone, la PS4, la Switch etc. Dès que les outils sont adaptés pour exposer la complexité du hardware au programmeur sans le rendre fou. En théorie donc le programmeur peut plus facilement cibler le pic de flops (avec le caveat que pic de flops != pic de qualité d'image si il y a besoin de faire certains compromis à ce niveau).

En pratique ce n'est pas toujours aussi simple. Par exemple la PS2 avait une architecture exotique ce qui fait que le contenu développé en commun avec une autre plateforme aurait pu avoir du mal à atteindre la parité en terme de qualité d'image. Mais avec quelques efforts certains effets possibles sur PS2 n'étaient simplement pas imaginables sur PC ou autre plateforme concurrente (Gamecube, première xbox). Et vice et versa. En pratique tout ce que ça fait c'est que ça donne du grain à moudre aux fan boys des deux camps. Même si au final le grand public finit par choisir un "gagnant" en achetant une des plateformes en plus grand nombre et ce n'est pas toujours celle qui a reçu le plus de boutons cochés dans ce genre de discussion.

Ok merci pour l'explication.
Tu as l'air vachement calé en technique.

C'est très intéressant a lire en tout cas, merci.

Et ce que c'est pour ça que sur la théorie la PS3 est plus puissante que la 360 mais que dans la pratique personne ne fait le nécessaire pour s'approprier correctement la machine et que du coup les version 360 soient toutes sortie mieux opti ? (sauf les exclus ps3)

Quand même celle qui est a l origine du buzz trouve qu elle s est fait prendre pour un jambon:




->https://www.reddit.com/r/NintendoSwitch/comments/5keire/im_laurakbuzz_nintendo_switch_leaker_and_full/