Reprise du message précédent :

Sauf que comme rappelé dans l'article, ils ont été incapables de faire du volume sur les SKU GT4e avec Skylake, qui sont apparus uniquement en quantité infinitésimales dans un NUC pour dire "mais si le produit existe", et même les GT3e se sont fait attendre. Donc non, c'est parce qu'ils n'ont pas pu le faire qu'ils en sont là (pour ce segment particulier).
 

A quoi bon être généreux, c'est jamais assez
 

Il y a plutôt des lois pour interdire les clauses qui interdisent ça. Ca s'appelle des Non compete clause. En Californie c'est illégal (pour protéger le droit des employés) : https://en.wikipedia.org/wiki/Non-c [...] California  
 
La mise à pied de quelques mois de Raja peut être vue comme une sorte d'alternative légale aux NCC, je n'ai pas de détails sur son cas, mais on a vu ca chez d'autres sociétés californiennes (on reste payé a un poste de "consultant" pendant X mois pour ne pas aller ailleurs).

Perso, je pense que pour qu'un split de la division Radeon soit une possibilité crédible, il aurait fallu que cette idée soit soutenue par un gros actionnaire voulant faire des profits à court terme, et non pas par un exec trop ambitieux.

Au hasard, plein de petit coeurs à la Zen sur interposer

Je me demande comment se passera les mises a jour pour ce gpu ?
Directement téléchargeable chez AMD ? ou bien il faudra passer par Intel...
Je préfère perso le premier cas vu le sérieux d'Intel dans le support absolument dégueulasse de ses solutions graphique

Bon finalement, selon Anadtech, ils n'ont pas racheter RTG. Seulement Raja
 
Du coup, il a le droit a une photo de nappe SATA ?

Un manque d'expérience pour fabriquer des GPU un peu plus gros que d'habitude? Quand je dis qu'ils pouvaient le faire en interne, c'est parce-qu'il me semble que leur architecture n'a pas grand chose à envier à Polaris côté efficacité. ( ) Avec l'edram bien sûr.
 
Soit dit en passant, on sait combien d'ingénieurs du RTG RK a embarqué chez Intel?

Pas viable.
 
Une archi "multi-GPU" est envisageable, sauf qu'il faudrait non seulement corriger les défauts de GCN mais aussi ceux posés par cette solution : tout communication inter-dies est plus énergivore qu'une communication intra-die, or, chaque die devrait disposer de seulement sa part de RAM, donc beaucoup de communications avec l'extérieur, donc beaucoup de surconsommation, avec en prime des latences importantes.

Et dédicacée la photo svp  

Bonjour
et bien Raja est déjà chez Intel
https://www.anandtech.com/show/1201 [...] tification

Presque  
 

Moins facile de toucher une cible mouvante qu'une cible immobile

C'est moi qui vais réclamer une compensation oui

J'aime bien lire les gens qui inventent pleins de défauts au GCN...

Genre? J'en vois toujours qu'un de défaut, mais un suffisamment grave pour qu'il devienne la priorité dès 2014... on attend toujours

La sauce a bien pris pour les cpu. Petits coeurs, bonnes perfs, conso maîtrisée.  
La latence GPU est compensée par le parallélisme et les caches. On n'est pas a l'abri d'une bonne surprise.
Pour ce qui est des défauts GCN, on en parle sur beaucoup de forum, mais sans exemple.
Il faut bien garder en tête que se mon point de vue c'est une archi souple.Elle n'est pas uniquement dédiée jeu, et n'est pas optimisée conso (faute de moyens, on connaît tous l'historique)

 
impossible, Intel a besoin de AMD comme "concurrent" sur les CPU x86 pour pas se manger des amendes colossales sur la loi anti-trust.

 
Puissance géométrique et Tesselation ne sont pas exemples concrets ?
 
http://www.hardware.fr/articles/95 [...] etrie.html
 


 
Tare qui existe depuis G.C.N. 1.0, qui avait été en parti amélioré avec le passage à 4 Shader Engine / Geometry Engine, et qui stagne depuis Hawaï ... Vega ne faisant que contourner en parti le problème avec ses primitives Shaders qui demandent l'investissement des développeurs pour être utilisé.
 
Et le scalling assez mauvais depuis Hawaï ... montre bien les goulets d'étranglements.

NVidia a déjà fait des papiers sur le sujet : ça marche pas sans changement sensible de la hiérarchie mémoire.

Maintenant c'est pas totalement impossible, mais avant d'en arriver là il faut corriger les défauts de ce type dans l'archi elle-même et limiter les accès à la RAM qui par définition iront piocher 3 fois sur 4 dans l'espace d'un autre GPU (en considérant qu'il y en a 4). Polaris n'a pas corrigé le souci, Vega non plus : est-ce que chez AMD on a au moins commencé à bosser sérieusement sur ce problème?

Du tout... Si AMD venait à couler, c'est Micro$oft qui serait bien enquiquiné car il faudrait à nouveau compiler NT pour d'autres cibles que le x86/x64 (historiquement, on a quasiment tout eu, donc bon... c'est bien une limitation commerciale) sauf que quelque part Micro$oft cherche depuis un moment à se défaire du x86/x64, d'où .net, donc ça n'enquiquinerait vraiment personne... à part Intel.

le gros problème d'amd est que les devs pc développement en priorité sur nvidia et c'est la berezina quand ils utilisent gameworks
quand un bethesda fait du code vulkan, ça fonctionne très bien sur nvidia et amd, avec un avantage à amd à gamme équivalente avec même une vega lc qui dépasse la 1080ti (certes une fois n'est pas coutume ), donc point de vue matériel c'est pas évident que ce soit moins performant, car gcn a aussi des avantages et quand ils sont utilisés ça passe assez bien
alors qu'un assassin creed origin ça fonctionne très bien sur nvidia et mal sur amd
ensuite, ce n'est que depuis peu qu'ils investissent sur le soft avec rocm car ils ont un gros retard sur la stack compute notamment IA

C'est le même problème cité 2x en fait : les "studios" emploient des devs qui tiennent souvent plus d'artistes et utilisent des SDK (quand tu prends une licence d'un moteur genre UE ou CryEngine, c'est bien un SDK complet que tu prends), au final il n'y a plus grand chose d'optimisable à ce stade, il faut remonter jusqu'au développeur dudit SDK de façon à ce qu'il implémente des routines efficaces (moteur, bibliothèques "de base" ) et documente les soucis constatés (plutôt SDK), ce qui n'est pas forcément possible à cause de partenariats avec le concurrent (tu me fous du GameWorks dans ton TruedukiouEngine et en échange je te file des ressources matérielles, humaines et pourquoi pas financières).

 
Ca fonctionne mal ?
 
http://gamegpu.com/action-/-fps-/- [...] st-gpu-cpu
 
Je vois ici des perfs au contraire proche ou identique a carte équivalente    

pas la peine de prendre ce ton, on peut tous se tromper
bon j'aurais du dire très mal avec un ryzen et une radeon
comme chez moi

et si tu regardes mieux, à part le cas 5960x@4.5, même avec un 6700, la vega64 fait moins bien qu'une 980ti
donc je pense que j'ai raison

Désolé pas vu le type de cpu  Curieux ces résultat selon le cpu
 A voir si les derniers drivers ou une mise a jour du jeu ont corriger ces écarts
Après la carte est normalement pour du 1440p, les écarts avec les 1080/1070 sont un peu plus réduit

la carte fonctionne très bien sinon
d'ailleurs si on veut juste les perfs à 98% d'une 1080, une vega @200W suffit selon techpowerup
amd a trop poussé sa carte de base j'ai l'impression pour grapiller 5% de perf

 
Sur nVidia ça marche plutôt bien mais le jeu se comporte de façon très particulière.
Il pousse énormément côté CPU avec une utilisation assez folle (entre 60 et 95% CPU sur un 7700K@4.9) et côté GPU ça tire peu.
Je suis à 75% d'utilisation PT en jeu (~90% lors des phases de chargement ?!?), pour ~98% d'utilisation GPU et des températures plus faibles que d'habitude en 1440p TAF (1080Ti@2GHz).
Autant dire que c'est plutôt surprenant de voir une charge CPU supérieure au PT du GPU, je crois même que c'est la première fois que je vois ça.
A l’utilisation je suis autour de 85fps en moyenne et le jeu est plutôt fort joli, la DA est au poil, malgré des textures pas toujours au top mais techniquement y'a encore pas mal d'optimisations à faire AMHA, même sous carte nVidiou.
Par exemple, ça m'est arrivé de voir chuter vers 30-40fps sans raison apparente, même si c'est rare (1 fois en 5H de jeu tout à l'heure).

NT a en effet existé sur un paquet de plateformes (Alpha, Mips, IA64 parmi les défuntes), mais aujourd'hui encore sous 2 : x86/x64 ET ARM: Windows Phone inclus déjà un noyau NT en ARM depuis WP8, et le Windows complet en ARM est annoncé depuis février, donc ne devrait pas tarder à sortir. L objectif étant de proposer des tablettes et ordi portables avec une batterie qui tient plusieurs jours.
Mais pour le computing de performances, on reste encore en x64 pour un moment. Que valent les solutions massivement multi cores en ARM?  AMD est d'ailleurs aussi ds cette course.

Outre le fait que celui qui utilise Windows pour ça est pas bien dans sa tête, la partie la plus importante est le grand public, précisément ce que .net ciblait dès son introduction : c'est une VM destiné à faire abstraction de la plateforme matérielle, ce qu'elle apporte en dehors de ça est carrément négligeable... bon, faut dire que pour moi la collecte des déchets ça ne fait pas partie des points importants, surtout que ça déconne toujours (et implique du coup de forcer l'invalidation des données obsolètes, donc de faire autant de boulot que sans GC).

Je parlais du computing de performances au sens large, pas vraiment celui de longs calculs scientifiques, mais plutot le quotidien des PC: des jeux aux logiciels de traitement divers et variés...
 
Quant à .NET, Microsoft a fait depuis qques années un vrai effort vers l open source et le multi plateforme, si bien que .NET Core 2.0 est pensé pour tourner aussi bien sous Windows que Mac ou Linux.
 
L'intéret de .NET, c est d avoir un framework de base homogène (l homogéneité y est meilleure que sous Java) qui gère le code et évite les crashs type 'segmentation fault'.  
Certes, on a encore des NullReferenceException, mais cela touche malheureusement la majorité des language qui ont hérité des objets 'null' par défaut ( https://www.infoq.com/presentations [...] Tony-Hoare )