AW: AMD Radeon RX Vega: Unmut über fehlende Primitive Shader und mehr häuft sich
Unten Getrolle mit Smilies, in der Mitte irgendwas - wie: könnte - würde - sollte und entspricht dabei nicht dem Versprochenem (Frage worauf das basiert das) und oben offtopic. Was erwartest du für Antworten?
Eine Antwort die logisch auf einen vorherigen Beitrag eingeht oder überhaupt noch einmal an den Kontext anknüpft.
- Z.B., woher kam dein Einwand bezüglich RPM was Wolfenstein 2 anging? Es gab keine Grundlage dazu ausgehend von meinen Beiträgen, richtig?
- Woher kam dein Einwand bezüglich der LL APIs und der Treibereffizienz, die ich angeblich als unsinnig dargestellt habe? Ich habe nichts davon in dem Aspekt zur Diskussion gebracht.
- Die Darstellung das es mir angeblich nicht passt, dass Vega das fortschrittlichste DX-Modell umsetzt, was auch nirgendwo Gegenstand der Debatte war und mein "Weltbild" welches sich gefrönt hat, wie toll sich alles bei Nvidia weiter entwickelt hat.
Das Nvidia mit Maxwell eine Menge verbessert hat im Vergleich zu Kepler ist praktisch erwiesen und wurde auf eine Frage von Schaffe89 ein wenig ausgeführt, ebenso ist es offensichtlich das Nvidia deutliche Fortschritte bei der Entwicklung ihrer IP erzielt, was kein Fanboy-Gelaber darstellt.
Das der Perf/Watt Abstand schlecht für AMD aussieht und ich dank AMDs geringen R&D-Budget für Navi und die Zukunft keine überdurchschnittlichen Zuwächse erwarte und damit weiterhin nur beschränkte Konkurrenzfähigkeit, ist auch keine grundlose Befürchtung und stellt kein AMD flame/bash dar.
- Der Abschnitt bezüglich des Warpschedulers/Load/Store-Unit und der Shader-Architektur hat sich auf Nachfrage hin (Es kam zu meiner eigenen Überraschung tatsächlich mal vor, dass du den Bezug genannt hast) angeblich auf die Sprachen und die Unterstützung der APIs bezogen, dann gab es ein Ausflug was Cg angeht, was offiziell nicht mehr von Nvidia unterstützt wird und auch keine Bedeutung bezüglich AMDs Technologie besitzt.
Es gibt keine Sorgen die man sich bezüglich Patentklagen machen muss und der ganze Ausflug von Schedulern/Load/Store auf Shading-Languages usw. kann von mir in kein logisches Gebilde eingefügt werden.
Eine Menge Offtopic, ja, aber alles Punkte die von dir aus dem Boden gehievt worden sind, von mir auch eingegangen, nur um mehrheitlich ignoriert zu werden.
Öffentlich musst du auch nicht darauf antworten, da Offtopic, aber fühl dich frei mir eine PN zu schreiben.
Mesa ist Linuxgerödel, was AMD unter Linux abliefert ist doch wieder was völlig anderes. Selbst wenn es in einer Art Virtuallisierung läuft kannst du das doch nicht allgemein einfach auf Windows oder directX übertrage, wenn der Treiber etwas nicht tut, kann es nur sein das ist so gewollt oder nicht gewollt. Die Absicht bleibt unerklärt. Lösen tut es AMD selbst. Und was PR Abteilungen von sich geben, dass ist so wie bei Politikern - "Was interessiert mich der Scheiß den ich gestern gesagt habe".
Der Beitrag hat sich auf kiffmets Fragestellung bezogen, in wie fern sich die Linux-Erkenntnisse auf Windows übertragen werden können.
Der Zusammenhang wurde von mir nicht schön verlinkt, aber ich habe es teils allgemein eingeworfen, was Bridgman bezüglich der Linux-Pläne gesagt hat und in wie fern sich die Pläne an die Arbeiten vom Windows-Team halten.
Du spekulierst hier wild umher indem du einfach Forenlinks und Twitterlinks kopierts, sie als Datenbasis hernimmst, diese hier rein stellst und einfach deine Knowhowgeschichte drumherum zimmerst. Das ist doch wie ein Gummiband, dass man in alle Richtungen ziehen kann.
Sorry das ich nicht wie die meist anderen direkt beim Unternehmen arbeite oder Insider-Quellen zum nachfragen besitze, welche 100% korrekte Antworten liefern.
Oh Moment, dass ist glaube ich nur bei den wenigsten der Fall und trifft auch auf dich zu.
Am Besten ist, Du fragst bei den Autoren nach, dann hast du 100% Geweissheit was sie meinen/gemeint haben. Die hauen Dir immer nur kurze Sätze an Kopf, so wieder jeder andere Entwickler auch und sieh zu was du daraus machst.
Was Rys Tweets, Ryan Smiths Nachfrage und den Absatz von Computerbase angeht, muss man nicht nachfragen, die Sätze stehen verständlich da.
Was suchst du? Etwas womit du AMD angehen kannst, beweisen das ihre Hardware fehlerhaft ist, kaputt, nicht wie versprochen? Darauf erhälst du von mir keinen Antworten, ich kann sie dir nicht liefern. Ich kann nur spekulieren so wie du, was die Sache aber nicht wahr macht.
Ich habe es schon mindestens zwei mal in diesem Thread erwähnt, dass ich persönlich nicht davon ausgehe, dass etwas kaputt ist.
Das die Primitive-Shader bzw. der NGG-Pfad noch nicht transparent implementiert ist, stellt für mich aufgrund der Informationslage einen Ist-Zustand dar.
Was AMD aufhält weiß ich nicht und lasse ich offen, dass es schon wie geplant funktioniert oder zwingend direkte Entwicklerkontrolle benötigt, sehe aufgrund der Informationslage nicht ein.
Ich kann mir nicht vorstellen das so viele Seiten oder TPU daneben liegen bei ihrer Berichterstattung. Das heißt man muss einfach warten. Das mag nicht jedermanns/frau Ding sein aber man wird auch nicht gezwungen.
Aber Anandtech und Computerbase liegen schon daneben und ein technischer AMD Mitarbeiter tweetet Unsinn, denn sonst muss man alles offen lassen bei den Widersprüchen.
Ich wiege die Aussagen von Rys und die Bestätigung einer direkten Nachfrage an AMDs PR von Ryan Smith schwerer, als die Berichterstattung anderer Webseiten.
Die Darstellung von TPU gefällt mir persönlich schon zu Beginn nicht.
Primitive-Shader sollen angeblich dabei helfen den Durchsatz von der Native-Pipeline um 100% im Vergleich zu Fiji zu erhöhen und später bezieht man sich erneut darauf mit Faktor 2 und dem NGG-Fast-Path, worunter vom Text her das den direkten Entwicklersupport darstellen sollte.
Nur erhöhen die Primitive-Shader im Fall der Native-Pipeline überhaupt nicht den Durchsatz, denn der liegt weiterhin bei einem Primitive pro Takt pro Engine.
Die höhere Discard-Rate kommt einzig und alleine von Vegas ~60% höheren Takt und damit Faktor ~1.6, welche TPU großzügig auf 2 aufrundet.
Was DX angeht haben wir jetzt über zig Seiten das Forum offtopic zugespammt. Der Konsens war, es gibt unterschiedliche APIs, deren Level und es ist ein "Mischbetrieb" bei Parametern möglich, der zuweilen komplexe 3dGrafik ausschließt sich aber anderweitig anwenden lässt, wobei man auch Ports ausführen kann (wieviel Aufwand das macht ist doch egal, es ist möglich - ob sinnvoll ist wieder ein anderes Thema)
Meine Aussage war, dass kein Spiel DX11.3 unterstützt, dein Einwand meinte jedes nach DX12 portierte Spiel tut es.
Das kann es aber nicht, wenn es nicht automatisch abläuft und entsprechend ist der Aufwand relevant.
Ich habe schon davor gesagt, wenn du von Anfang an gesagt hättest, du meinst es eig. nicht so streng bzw. die Vereinfachung was die Portabilität angeht, dann wäre das Thema sofort abgehackt gewesen.
. Das man wenn man in bestimmten Leveln unterwegs doch schon für höhere Feature entwickeln kann (HL vs LL aber berücksichtigen muss). Die üblichen DX12 Ports einiger AAA Titel in 2016 wurden durch Nixxes ausgeführt und damit auf nV Hardware (die haben und verwenden nichts anderes), wobei AMD dort mit Treiberupdates gegensteuern musste und Entwickler Patches liefern, wie auch W10 seitens M$ gepacht werden musste (Gamingmode usw.) und AMD immer noch an Treiberanpassungen arbeitet (siehe aktuelle Issuses), neue Hardware macht es nicht besser. Aber auch deren Treiberteams ist auf die Zuarbeit/Input/Output anderer Entwicklerteams angewiesen, was manchmal schleppend vorangeht und man Lösungen nicht zeitnah anbieten kann. Jeder arbeitet erstmal sein ab und guckt dann was man noch liefern kann.
Nixxes war auch drei mal Kooperationspartner von AMD, einmal bei Deus Ex: Human Revolution, dann bei ersten Neuauflage von Tomb Raider (2013) und zuletzt von Deus Ex: Mankind Divided (2016).
Unwahrscheinlich das die keine AMD-GPUs besitzen.
Übrigens lief DX12 bei Deus EX: MD zu Beginn auch miserabel und im CPU-Limit weiterhin ein wenig schlechter bei AMD:
Deus Ex Benchmark: DirectX 12 legt in Mankind Divided massiv zu - ComputerBase
Der Gaming-Modus ist völlig allgemein, indem das Verhalten vom Thread-Scheduler verändert wird und es funktioniert sowohl unter DX11, als auch DX12.
Ob es bessere Performance gibt hängt auch von der Hintergrundlast und der CPU und der Anzahl der Threads ab.
Schlechte DX12-Umsetzungen werden dadurch nicht gefixt.
[/FONT][FONT="][/FONT]
