mjoe87
Komplett-PC-Aufrüster(in)
Und wieso erzählst du mir das?
AMD Sienna Cichlid: "Big Navi" mit 80 CUs und 5.120 Shadern?
- Ersteller PCGH-Redaktion
- Erstellt am
Und wieso erzählst du mir das?
Er ist jetzt im schnitt bei 1/10 (grob!)und er MUSS kleiner werden, niemand ist wirklich mit dem jetzigem FPS drop zufrieden.
Bei AMDs DXR ansatz kann er aber durchaus auch 2/10 sein, wenn sie die Zeit bei den 8/10 wieder reinholen.
E
eclipso
Guest
Ignorier ihn einfach: DirectX Raytracing (DXR) Functional Spec | DirectX-Specs
Um eine Invokation zu vermeiden, werden eben nicht zig Durchläufe ausgeführt. Es redet gerne von der Performance ohne Intersectionsshader, aber Microsoft gibt in dem Fall überhaupt keine Raytracingpipeline vor, um DXR auszuführen. Man kann sich beider Modelle bedienen. Es braucht dafür keine fixed Funktionseinheit, sie wird aber auch nicht ausgeschlossen (das habe ich auch schon zig mal hier wiederholt).
Man hat dabei beide Ansätze berücksichtigt, was ich sehr positiv finde.
Zuletzt bearbeitet von einem Moderator:
Algo
Freizeitschrauber(in)
*Seufz* ... na gut ich seh schon ... hat wenig Sinn mit dir zu diskutieren, aber ein letzter Kommentar von mir:
Im Video von AdoredTV ging es nicht nur um fehlerhafte Nvidia-Treiber, sondern auch um Hardwaredefekte wie sich selbst auslötende Grafikchips. Stichwort Bumpgate. Schon mal überlegt/gewundert warum Apple keinerlei Nvidia-Hardware mehr verbaut? ... Bingo wegen Bumpgate.
Und deshalb ist auch das Artefakt Problem der RTX Karten durchaus relevant. Aber gut ... glaub du was du willst ... mehr wie auf solche Sachen hinweisen kann ich nicht. Kann ja dann jeder seine Schlüsse daraus ziehen.
E
eclipso
Guest
Frei nach dem Motto, "was mich selbst nicht betrifft, existiert nicht", lesenswert schon vor zig Monaten: NVidia - Kalt erwischt: Fuehren SMT-Probleme und kalte Loetstellen zu den Ausfaellen bei Nvidias GeForce RTX 2080 Ti FE?
Seite 9
| igor sLAB Community
Ich weiß schon, nun bin ich gastello.
E
eclipso
Guest
Ich kenne keine einzige Nachricht, dazu das sich eine 400 Watt AMD Karte selbst "entlötet", warum? Die GPU wurde mit einem Interposer vom PCB entkoppelt. Damit machen die Lagen der Energieversorgung kaum Probleme, dafür ist der Aufbau instabiler, bzw. lässt sich nicht ein so hoher Anpressdruck generieren, was die Hardware im Taktverhalten bei hoher Energiedichte limitieren kann.
Ich hatte übrigens ein Laptop mit der GT840m, war öfter kaputt. GPU wurde mehrfach getauscht. Warum? Lotproblem?
Mal damit beschäftigen: Unified shader model - Wikipedia
Wenn man in der Instructionspipeline ein fixes Processing spart, spart man auch gleichzeitig Strom oder kann die freigewordene Rechenleistung bei gleichem Energieverbrauch für anderes einsetzen. Es wird dort übrigens super beschrieben. Es geht vor allem um ein effizientes Balancing, bei höherem Workload (auch im Worstcase) und das ist davon abhängig, was eine GPU in einem bestimmten Softwareumfeld leistet. Das tut sie nur, wenn man ihr die nötige Energie zuführt, wobei sie davon alles in Abwärme umwandelt.
Nvidia hatte zuletzt und mit TSMC immer den Vorteil, dabei weiter in die Fläche (mehr Waferfläche) gehen zu können (bei expliziet angepasstem Verfahren FFN), um höhere Leckströme zu vermeiden. Das Negative an diesem Modell ist, dass es kostenintensiv ist. Denn irgend jemand muss den Wafer bezahlen.
Es ist auch falsch zu behaupten, AMD wolle mit Bignavi seine Marge weiter steigern, sie wollen vor allem die derzeitige Marge von 50% halten (mehr teilte man den Investoren nicht mit, soweit bekannt waren die zufrieden, weil man den Anteil steigern will, Highend haben sie ja bisher nichts und vermutlich wird das auch gekauft wenn der Preis passt). Ich glaube das man daher mehr Spielraum hat als Nvidia, was die Einführungspreise angeht. GA102 ist deutlich größer als Bignavi (+100-200mm²). Du meinst Nvidia schenkt dir das?
Sie haben also 100-200mm² Spielraum bei der Waferfläche und 10% Spielraum bei der Bruttomarge. Letztlich bedeutet ein kleineres GPU-Die auch eine höhere Yieldrate, wobei sie schon mit Vega20 ausreichend Erfahrungen gesammelt haben dürften. Wie man am GA100 sieht, ist der Vollausbau bei Nvidia derzeit kaum zu bekommen. Alle bisherigen A100 sind teildeaktiviert.
Ich hatte übrigens ein Laptop mit der GT840m, war öfter kaputt. GPU wurde mehrfach getauscht. Warum? Lotproblem?
Die Antwort ist, dass du und einige wenige mehr, legen "in Hardware beschleunigt" als fixed Function aus, um es mit Nvidia gleich zu stellen. Die tun ja genau das Gleiche...um mehr geht es dir/euch nicht. Ob das so ist, wissen wir aber nicht.
Mal damit beschäftigen: Unified shader model - Wikipedia
Wenn man in der Instructionspipeline ein fixes Processing spart, spart man auch gleichzeitig Strom oder kann die freigewordene Rechenleistung bei gleichem Energieverbrauch für anderes einsetzen. Es wird dort übrigens super beschrieben. Es geht vor allem um ein effizientes Balancing, bei höherem Workload (auch im Worstcase) und das ist davon abhängig, was eine GPU in einem bestimmten Softwareumfeld leistet. Das tut sie nur, wenn man ihr die nötige Energie zuführt, wobei sie davon alles in Abwärme umwandelt.
Nvidia hatte zuletzt und mit TSMC immer den Vorteil, dabei weiter in die Fläche (mehr Waferfläche) gehen zu können (bei expliziet angepasstem Verfahren FFN), um höhere Leckströme zu vermeiden. Das Negative an diesem Modell ist, dass es kostenintensiv ist. Denn irgend jemand muss den Wafer bezahlen.
Es ist auch falsch zu behaupten, AMD wolle mit Bignavi seine Marge weiter steigern, sie wollen vor allem die derzeitige Marge von 50% halten (mehr teilte man den Investoren nicht mit, soweit bekannt waren die zufrieden, weil man den Anteil steigern will, Highend haben sie ja bisher nichts und vermutlich wird das auch gekauft wenn der Preis passt). Ich glaube das man daher mehr Spielraum hat als Nvidia, was die Einführungspreise angeht. GA102 ist deutlich größer als Bignavi (+100-200mm²). Du meinst Nvidia schenkt dir das?
Sie haben also 100-200mm² Spielraum bei der Waferfläche und 10% Spielraum bei der Bruttomarge. Letztlich bedeutet ein kleineres GPU-Die auch eine höhere Yieldrate, wobei sie schon mit Vega20 ausreichend Erfahrungen gesammelt haben dürften. Wie man am GA100 sieht, ist der Vollausbau bei Nvidia derzeit kaum zu bekommen. Alle bisherigen A100 sind teildeaktiviert.
Zuletzt bearbeitet von einem Moderator:
G
Grestorn
Guest
Kindergarten. Jedesmal wieder.
Seufz.
Seufz.
GEChun
Volt-Modder(in)
Ich bekomme je mehr News ich lese immer mehr den Eindruck das da ein ebenbürtiger RTX 3080 bzw 3090 oder 3080TI Konkurrent kommt, allerdings nur ohne Raytracing..
Mit Raytracing ist dann nur die 2080TI ebenbürtig! xD
Aber mir solls recht sein, ohne RTX mal wieder auf Augenhöhe sein, das ist auch schon ordentlich finde ich!
Zu mal die neuen Nvidia Karten ja wohl an der termischen Kotzgrenze laufen...
Mit Raytracing ist dann nur die 2080TI ebenbürtig! xD
Aber mir solls recht sein, ohne RTX mal wieder auf Augenhöhe sein, das ist auch schon ordentlich finde ich!
Zu mal die neuen Nvidia Karten ja wohl an der termischen Kotzgrenze laufen...
Lass sie doch einfach diskutieren... Denn was zumindest 100% sicher ist, dass hier auch über Themen diskutiert wird, von denen keine offiziellen Informationen da sind. Wie immer wird aber hier Spekulation in Faktform verkleidet.
Abgerechnet wird, wenn Big Navi tatsächlich gegen die neue RTX Reihe antritt.
Dann ist erstens sicher, welche Technik denn AMD nun tatsächlich in ihren Chips/Treibern für RTRT einsetzt (kann nämlich auch sein, dass es überhaupts nichts mit den Techniken im Patentantrag zu tun hat) und zweitens zeigt sich dann auch, welche Technik die überlegenere bzw. praxistauglichere ist.
Womit hier schonmal einige falsch liegen ist, dass die RT Cores die anderen Cores blockieren oder lahmlegen würden. Das läuft alles asynchron/parallel.
Auch ist espackos Schaubild ziemlich eindeutig und mittels nsight auch nachprüfbar:
https://www.hardwareluxx.de/images/...pdate-09_3B38525933DF4A76866ACA7122331010.jpg
Interessant aber zu sehen, was dann aus einer recht durchschaubaren Messung teils für Schlüsse gezogen werden...
Es ist eindeutig zu erkennen, wie stark die RT- Cores die Int/FP32 Cores- Schlacht für die Intersection- Berechnungen abkürzen.
Ansonsten hat abgesehen davon nvidia nie behauptet, dass es für RTRT zwingend RT- Cores braucht. Ansonsten bitte verlinken.
Sie haben immer nur gesagt, dass sie mit der RTX- Reihe das ganze auch in spielbare Regionen hieven konnten.
So haben sie selbst die ersten RTRT- Szenen inkl. Fallback geliefert.... und Treiber für die non RTX Karten (Pascal) geliefert, die mittels DXR RTRT nutzbar gemacht haben.
Was man aber nicht alles tut, um seinen persönlichen Klassenfeind in schlechte Licht zu rücken...
Zuletzt bearbeitet:
Das "blockieren oder lahmlegen" liegt alleine schon durch die 3D Pilpline begründet, du kannst irgendwann nicht mehr weitermachen, du brauchst die Ergebnisse der "RT" Cores.
Alleine schon deswegen halten einige extra FF Funktionen für unsinnig, man wird sie nur durch Tricks WIRKLICH paralel rechenen lassen können (1 frame ahead und solche späße).
Aber schau dir die "Auslastung" doch mal an, die Schader sind bei RT Last mal gearde 5-10% ausgelastet und das auch nur, weil man eh warten müsste.
Die RT Cores machen die Schader in der Zeit einfach Arbeits-/Nutz-los ~80% der Fläsche sind bei RT "Arbeit" schlicht nutzlos.
Es ist bezeichnend, dass sowas hier dann als "besonders" herausgestellt wird. Und im Übrigen hat man in der Renderpipeline keine Interdependenzen?
Die Frage ist doch nur, ob es technisch möglich ist, ob man komplett async/parallel fahren kann.
Die Auslastung der Einheiten hängt von vielfältigen Parametern ab und ist überhaupt eine der Hauptherausforderungen sowohl beim GPU Design, als auch beim Programmieren einer Engine.
Deswegen sitzt ein großer Teil eines Programmierteams Tage und Nächte über den Auswertungen der Profiler, um da noch die einen oder anderen Prozentpunkte an Effizienz herauszuholen.
Alles eine Frage des Handlings und vor allem der Priorisierung, aber keine Einschränkung durch die Hardware per se.
FF schafft einem ja gerade einen Haufen Flexibilität allein dadurch, dass es eben feststehende Berechnungen so schnell durchprügelt, dass die anderen Einheiten überhaupt erst genügend Luft haben, um den Folgejobs nachgehen zu können.
Außerdem muss man immer ein Auge auf der Power- Budget haben, da sich allein dadurch schon Wechselwirkungen innerhalb der Funktionseinheiten ergeben.
Wenn Du Dir den Auslastungsschrieb ansiehst, siehst Du auch außerhalb der Phase des BVH- Traversals teils niedrige Auslastung an FP32. Das liegt eben daran, dass eine Grafikkarte noch einen Haufen anderer Ausführungseinheiten besitzt, die beliefert werden müssen.
So wird durch das Schaubild nur ein Bruchteil dessen erfasst, was die Grafikkarte gerade macht.
Schau Dir mal einen nsight Schrieb in allen Einzelheiten an - Dann weisst Du, was Sache ist.
Zuletzt bearbeitet:
Das Schaubild zeigt, das auch ohne RT Cores Truning schon deutlich schneller ist als Pascal, wie viel schneller wird RDNA2 sein?
Dann versuche hier nicht darzustellen als würden RT Cores UND Schader WIRKLICH 100% Parallel betrieben, das ist nämlich stuss.
R
Rotkaeppchen
Guest
15% Mehrleistung zur RTX 2080TI und dann mit 16GB? Haben wollen!
Was soll man mehr erwarten? Alles eine Frage des Preises und des Treibersupports.
Lies Dir meinen Text durch und versuche nochmal ihn zu verstehen.
Allein das Schaubild beweist, dass sie parallel betrieben werden, somit muss ich das mit dem "Stuss" leider zurückgeben, oder liegt eine Sehschwäche vor?
Zudem wird etwas parallel ausgeführt oder nicht bzw. die technischen Gegebenheiten/Möglichkeiten sind vorhanden. Keine Ahnung, was bei Dir eine 100% Parallelausführung bedeuten soll?
100% wovon?
Welche Einheit aber wann aufgerufen wird und mit welcher prozentualen Auslastung am Gesamtrechenbudget, bestimmt der Programmierer der Engine.
Und es gibt einige Vorgänge im Rendering, bei denen es sich eben schlichtweg nicht lohnt, mehrere Worker zu eröffnen, da der Verwaltungsaufwand bzw. das Timing bis zum Ziel- oder Zwischenergebnis effizienztechnisch keinen Nutzen hat.
Manche Berechnungen müssen trotz eines Parallelanstoßes zu einem Zeitpunkt XY beendet sein.
In der Praxis gibt es den Workload (bis auf ein par ns) schlichtweg nicht, in dem alle Funktionseinheiten zu gleichen Anteilen ausgelastet sind.
Du hast als Endergebnis nunmal immer das Ziel alle Framebuffer gefüllt zu haben und diese dann für das Zielframe zu "mergen". Insofern sind einer Asynchronität dort z.B. auch sehr enge Grenzen gesetzt.
Man programmiert nunmal Spiele nicht so, dass Messschriebe "schön" aussehen.
Zuletzt bearbeitet:
Eben, das Problem ist inhärent du bekommt mit Turing KEINE wesentlich besser Ausalstung als das gesehen hin. Der Programmiere, wenn er bei klarem Verstand ist, bestimmt hier schlicht nichts. Was soll er denn machen? Die RT Core Arbeiten stückeln? Geht schlicht nicht. wenn du die RT Cores nutzt, dann in einem rutsch sonnst stimmt mit deinem Algorithmus etwas nicht und es wird zu teuer.
Mit asynchronous compute versuchst du die Hardware so gut auslasten wie's geht, mit Turing und RT Cores geht dies aber nicht. 1/10 Framtime machen ~90% der Shader schlicht nichts oder anderst rum, 9/10 FrameTime machen die RT Cores schlicht nichts.
Und das man DXR auch ohne dezidierte FF beschleunigen kann sieht man ja selbst an Pascal VS Turing (ohne RT). Selbst das geschönte DLSS+RT Farme hilft da nicht.
seahawk
Lötkolbengott/-göttin
Guckst du in meine Tabelle. Und die 430 mm waren Hochrechnungen von Nvidia anhand des Xbox Dies mit 4608 Shadern und 384 Bit.
12Gb Speicher und 2,2Ghz
Die 505mm die tatsächlich schon jemand gesehen hat sind deutlich sicherer als irgendwelche Hochrechnungen von Nvidea
Dann ist das ein doppelter Navi 10 und für den I/O Video Part kann man noch etwas beifügen. Das ist realistischer,
sandworm
Software-Overclocker(in)
Was "Hochrechnungen von Nvidea" hab ich irgendetwas verpasst?Guckst du in meine Tabelle. Und die 430 mm waren Hochrechnungen von Nvidia anhand des Xbox Dies mit 4608 Shadern und 384 Bit.
12Gb Speicher und 2,2Ghz
Die 505mm die tatsächlich schon jemand gesehen hat sind deutlich sicherer als irgendwelche Hochrechnungen von Nvidea
Zuletzt bearbeitet:
*Kopfschüttel*
Niemand möchte Pascal "Shader" für DXR und wie sich RDNA2 Shader schlagen, wird sich zeigen.
Und wetten dein "Monster Pascal" ist gerechnet mit DLSS, was die RT "Leistung" zu gunsten von Truing schönt.
Ansonsten ist das mit dir schlicht Zeitverschwendung, lass es.
Niemand möchte Pascal "Shader" für DXR und wie sich RDNA2 Shader schlagen, wird sich zeigen.
Und wetten dein "Monster Pascal" ist gerechnet mit DLSS, was die RT "Leistung" zu gunsten von Truing schönt.
Ansonsten ist das mit dir schlicht Zeitverschwendung, lass es.
Ähnliche Themen
