Reprise du message précédent :

En revanche, va falloir qu'ils désactivent le core parking .

il semblerai qu'il y ait vraiment un bug lié à windows 8/8.1/10,mais pas windows 7
sources : CDH

Il semblerait que se fier a un community manager de Microsoft ne soit pas une bonne idée.

 
Entre un community manager qui fait du zèle sur twitter et un message officiel sur le blog d'AMD qui dit qu'il n'y a pas vraiment de problèmes j'aurais plus tendance à croire le dernier.
 
edit: burned  

Ils citent aumoins clairement le Core Parking comme un problème, même si ils continuent de parler du "fast frequency change" qui ne semble avoir aucun impact, si il existe, en mode High Perf d'après nos tests.

Il ne serait pas possible que cet impact soit compensé par la capacité du scheduler à mieux gérer les threads si les P-states sont gérés logiciellement?

Si j'ai bien suivi, contrairement à mon A4-5000, même en Performance il est possible d'avoir une gestion des P-states, mais du coup matérielle...

Le truc c'est qu'on ne voit pas de diff ou à la marge d'erreur entre "Balanced + core parking OFF", et "Performance" (le graph en bas de la page 8, barres orange et grise). Donc même si il y a une différence sur les changements de P-State, en pratique, il n'y a pas d'impact concret sur les performances que l'on ait pu mesurer. Le mettre au même plan que le core parking (qui a lui un impact massif) est bizarre.

"By the first week of April, AMD intends to provide an update for AMD Ryzen™ processors that optimizes the power policy parameters of the Balanced plan to favor performance more consistent with the typical usage models of a desktop PC."

On peut espérer que le policy parameter est bien le CPMINCORES du Core Parking

 
Donc en gros, le patch magique que beaucoup attendaient n'arrivera pas, juste un patch permettant de régler les quelques problèmes qui ont été fait à la main dans le test.
 
On peut donc prendre comme définitifs les résultats du test avec core packing off.

En attendant éventuellement des patchs dans les applications (on pense à F1 2016), mais oui c'est la meilleure approximation que l'on peut faire aujourd'hui des performances de Ryzen.

A noter enfin que l'on a aussi vérifié rapidement hier la question du HPET, AMD avait indiqué que HPET réglé sur OFF (le mode par défaut sous W10 sur notre carte mère) était possiblement légèrement plus rapide que si HPET est activé. Comme il est nécéssaire d'activer HPET pour utiliser Ryzen Master, nous avons retesté avec le HPET activé quelques benchs (7-Zip, WinRAR, Lightroom, BF1 et Civ 6), nous n'avons pas vu d'écart significatif par rapport aux scores présentés dans nos tests.

De toutes façons, je pense que les éditeurs de jeux vont rapidement patcher leur détection de CPU si elle est un peu merdique, et ça va rouler .

 
Patcher des jeux passés, pas gagné, sauf jeux pas trop anciens et suivant les moyens de l'équipe.
 
Pour les jeux futurs, il faut espérer que le lobbying d'AMD soit efficace.

Bonjour
AMD est toujours sur le terrain (miné) d'Intel
la progression de Ryzen est énorme mais aucun éditeur ni Microsoft ni quiconque fera un effort pour faire passer AMD devant

 
Je sais que ces tests doivent être harassants, mais vous rejouez à chaque fois l'intégralité pour chaque CPU si modification protocole? Si oui, chapeau
 

Si modification d'un bench, on ne repasse que le bench en question. C'est ce que l'on a fait pour F1 2016 ou l'on a repassé tous les CPU pour refaire le test. Ca prend déjà beaucoup de temps

Pas de bug sous Windows 7 et Linux ?
Et bien, Windows 10 n'a pas fini de nous embêter  

Ryzen ne devait pas supporter les instructions TSX ?
 
Le dump de coreinfo me donne :

 
Il n'y a pas de bug   Juste une nouvelle architecture à prendre en compte, et à priori ça été fait sous W10 comme sous Linux. Peut-être des optimisations à venir (tant Linux que W10), mais il ne faut pas attendre +10% pour Ryzen en jeu (vu que tout le monde semble focalisé là-dessus).

Sous Linux avec une distribution en base Ubuntu, il y a des soucis de démarrage en kernel 4.9 et 4.10. En 4.4, bien qu'il y ait un message de matériel non reconnu, cela démarre.
 
voir ici
 
Sous manjaro, pas de souci pour l'instant.

 
euh ben si justement, le core packaging off fait bien gagner 10% sur certain de jeux. De plus les optimisations spécifiques sous win10, pour les compilateurs, au niveau des pilotes ou même du code des appli peuvent potentiellement faire gagner chacune quelques pourcents. Faudrait refaire le test dans quelques mois pour se rendre compte de l'impact de ces optimisations.

C'est sur que si tu laisses ton processeur dans son packaging, ça doit moins bien fonctionner. Le sortir de sa boîte c'est bien aussi    
 

Une fois déballé il perd au moins 50% de sa valeur

Bon je crois qu'on peut dire après ces quelques semaines que Ryzen c'est un peu comme le soufflé au fromage qui retombe à la sortie du four. Tout le monde etait excité jusqu'à sa sortie, mais l'espoir est vite retombé. On esperait qu'il allait mettre la fessée a Intel, mais on aura beau faire tous les tests possibles, modifier les paramètres, espérer que un patch aidera, mais il faut bien se rendre a l'évidence. Il est loin d'égaler et de surpasser Intel.  
Je parle en usage classique et jeux car en applicatif pur je pense que ca interesse très très peu de personnes.
Maintenant oui c'est un grand pas pour AMD, oui ca permet de retrouver de la concurrence sur le marché du CPU, oui il permettra de retrouver des prix raisonnables, mais j'ai l'impression que on est un peu revenu a l'epoque du K6 face au Pentium. Peut être avant la sortie du "nouveau K7" dans quelques années

 
Sous manjaro (donc rolling release) tu as tout qui est correctement détecté  ? et pas de messages d'erreur qui plombent les logs?
 
Dans son test Phoronix dit que Ubuntu 17.04 fonctionne parfaitement sur une MSI X370 Xpower (minus le chipset son et les sensors non détectés)
http://www.phoronix.com/scan.php?p [...] inux&num=2
 
En tout cas, avant de passer sur Ryzen, je vais attendre que ça se décante: Bios matures, support Linux des nouveaux composants CM, etc.
 
... et choisir soigneusement la CM (pas question d'en prendre une dont le constructeur se moque du support Linux pour les drivers, cf Gygabyte dans ton lien)

Effectivement ubuntu et ses variantes ne fonctionnent pas chez moi.
Par contre j'ai mis une fedora 25 (noyau 4.9) et ça marche super bien

Mais chipset ALC1220 et  sensors non détectés, je suppose ? Je ne pense pas que Fedora ait inclus des drivers beta dans une version stable ?

Aucune idée c'est quoi ALC1220 ?
Si c'est le son ça marche en 5.1.
Ensuite les sensors, tu veux dire les sondes de température ?
J'ai pas de logiciel pour les lire mais y'a pas de raisons que ça ne marche pas.

Oui, c'est le son. Tu peux regarder quel est le driver utilisé? (terminal -> commande lspci -v, rubrique Audio Device)
 
Pour les capteurs: installer les packages lm_sensors + gnome-shell-extension-common + gnome-tweak-tool. Puis terminal -> commande sensors-detect. Puis installer le plugin Freon via Application-> Divers -> Outil de personnalisation.

Pour le son ça a l'air d'être un pilote générique intel
 

 
Pour les sensors je regarde

ha oui dans freon j'ai pas grand chose.
 
43° c'est le cpu je crois, et puis les disques.
 

Si tu n'as qu'une température, oui c'est le capteur interne au cpu je pense.
 
Pour le driver son, j'avais oublié que c'est un driver universel maintenant. Pour avoir le codec utilisé, commande dmesg |grep codec.

Oui un seul capteur.
 
Pour le codec

 
Un machin générique donc !

Oui, j'ai ça sur mon laptop I5 :

 
Merci pour les infos.
Bon je crois que je ne vais trop tarder pour passer sous  Ryzen; A priori, tout est ok sous Linux, au moins sous la distrib que j'utilise  

Fedora aussi chez toi ?

Oui, laptop et desktop. Depuis que la mise à jour d'une version à l'autre est une simple formalité, on a presque les avantages d'une rollling release (dernières versions kernel et logiciels), sans les inconvénients.
 
Bien content que l'audio marche sur AM4, ça me retenait un peu pour migrer sur Ryzen.

J'en suis le premier étonné, mais avec la manjaro, pas de méchant bug dans les logs (journalctl, dmesg). Pour le son intégré à la carte mère, je peux pas dire, j'utilise toujours ma Xonar Essence STX. Comme on ne peut pas désactiver le son intégré dans le BIOS, les 2 pilotes se chargent. Je suis branché sur le port LAN Intel, pas eu encore l'occasion d'essayer le killer.
 
Sinon j'ai vu le message de Gigabyte sur le forum, et j'avoue que si je l'avais vu avant de commander la carte mère, je n'aurai peut être pas pris cette marque... Mais bon, pas sûr que les autres fassent mieux de ce côté là.
 
Les sensors pas contre ne sont pas détectés pour l'instant. (sensors-detect)

En même temps, j'ai été un peu vite en tapant sur Gigabyte    Dans un sens, ils ont raison puisque les problèmes évoqués semblent être des problèmes distrib (Debian et dérivées, versions LTS ?) et pas des problèmes Linux/Gnu (arch et dérivées, Fedora ok)
 
Remarque,  ça en dit long sur le support Linux des constructeurs pour le hardware grand public. Côté serveur, c'est différent, mais les acteurs ne sont pas les mêmes; IBM, HP et DELL: exit Asus, MSI, Gigabyte et Asrock.

Perso je ne jetterai pas la pierre à Gigabyte pour ça, ça doit être pareil pour tous les constructeurs.

+1  
 
Peut être que sur les sondes des cartes mères, une marque travaille mieux qu'une autre, mais globalement les problèmes à résoudre sont plutôt pour ceux qui gèrent la plateforme (donc AMD ou Intel en face). Parfois ils ont le temps de travailler en amont (le support dans les compilateurs se fait des mois à l'avance par exemple), parfois non.

[HS]
Au final, le problème sous linux avec ce genre de chipsets (audio, capteurs, ethernet, périphériques usb), ça n'est pas tant les fabriquants de CM qui suxent pour le support Linux, mais plutôt les fabriquants de ces composants qui développent des drivers microsoft, ferment le code, et freinent le support Linux (retro engineering obigatoire dans pas mal de cas).
 
Le pire de tout côté Linux, c'est bel et bien ces clés usb wifi ou bluetooth à pas cher qui ne fonctionnent que sous un OS microsoft (pas trop bien d'ailleurs)
[/HS]
 
Pas sûr que les fautifs se trouvent côté cpu (AMD/Intel), ou côté CM (Asrock, Asus, Gigabyte, MSI) sauf pour les CM bas de gamme qui embarquent des composants qui ne fonctionnent que sous Windows (et pas trop bien en général)

(100% d'accord sur les puces additionnelles oui c'est un vieux problème malheureusement, pour les problèmes a régler par AMD/Intel je pensais plus aux problèmes de boot/détection correcte du cpu etc)