Archiv verlassen und diese Seite im Standarddesign anzeigen : Diskussion zu: News des 22. September 2022
Leonidas
2022-09-23, 09:14:08
Link zur News:
https://www.3dcenter.org/news/news-des-22-september-2022
Statt +100% Performance und +50% Preis haben wir jetzt +50% Performance und +100% Preis.
Die Zahlen sind ja immerhin gleich geblieben^^
Kleebl00d
2022-09-23, 10:50:32
Welchen Zweck erfüllt ein im BIOS hinterlegter Maximaltakt?
Gerade, wenn er wie beschrieben teils in faktisch nicht erreichbaren Höhen angesetzt ist?
Cubitus
2022-09-23, 10:54:51
https://www.gebraucht-kaufen.de/sh-img/2403148199_d296d26fb2_papiertiger.jpg
Kein Karten wird es zu kaufen geben..
Welchen Zweck erfüllt ein im BIOS hinterlegter Maximaltakt?
Ein Limit für Übertaktungen festzulegen.
Gerade, wenn er wie beschrieben teils in faktisch nicht erreichbaren Höhen angesetzt ist?
Mit Trockeneis sollte dieser durchaus erreichbar sein, evtl. sogar mit Sub-Ambient Flüssigkeitskühlungen.
aceCrasher
2022-09-23, 11:53:30
Welchen Zweck erfüllt ein im BIOS hinterlegter Maximaltakt?
Gerade, wenn er wie beschrieben teils in faktisch nicht erreichbaren Höhen angesetzt ist?
Damit der Boostalgorithmus Spielraum für niedrige Temperaturen hat.
Die Nichtexistenz jener Shader-Cluster-Verbesserung drückt die Rohleistungs-Verbesserung (in diesem konkreten Beispiel) auf +120%.
Auf den ersten Blick.
Mit Shader Execution Reorder gibt es durchaus eine Verbesserung welche die Auslastung der vorhanden Rohleistung verbessern soll. Auch wenn das natürlich hauptsächlich auf Raytracing abzielt und dort die meiste Performance bringen wird könnte auch beim Rastern der eine oder andere Prozentpunkt übrig bleiben, bzw. könnte den Entwicklern mehr Freiraum geben indem das Performance-Penalty von divergenten Shadern reduziert wird.
Leonidas
2022-09-23, 12:59:16
Logisch. SER scheint was zu können. Aber es beeinflußt nicht die nominelle Rohleistung und ist zudem ein Feature primär für RayTracing, nicht für die normale Grund-Performance.
Für einige Customs liegt der Boostclock bei 2525MHz. Bei gleicher TDP Angabe wohlgemerkt, aber besserer Kühllösung. Die Referenz 6900xt wird über ihren Kühler beschränkt weil dieser um 2 Slots hoch blieben sollte. Das schränkt bei der Diegrösse und damit der nutzbaren Fläche nicht nur den Wärmefluss. Im OC und höherer Leistungsaufnahme werden bei absoluten Limit auch 2,8 GHz erreicht. Dann wird der Takt per BIOS hart limitiert. Meine Asicquali ist beispielsweise 87,5.
Diese Clocks erreicht nVidia nicht mit 300w-350w TDP. Das geht mit Lovelace munter so weiter. Die Customs 4090 haben bis 660w real. Genau deshalb sind sie so riesig und brauchen 12pin 4-fach Adapter und liegen dann bei 675w. Das ist alles was an Lovelace "4 fach" ist.
Es ist durch das MCM Design klar davon auszugehen, dass das GDC von RDNA3 höher takten kann und wird als bei RDNA2. Sie werden vermutlich an die 3GHz heranreichen,Topmodelle darüber liegen.
NVidia hat es mal wieder verkackt und sich in Tensor und RT verrannt. Diese Cores takten deutlich niedriger und man kann damit nur in die Breite gehen, während die Hardwareshader intern viel höher takten könnten. Das ist aber ein designtechnisches Problem von NVidia selbst. Breite und Ausbau kostet deutlich mehr Energie. Das war ein Ampereproblem und bleibt somit ein Lovelaceproblem, die Architektur ist nicht unbedinbt für Effizienz ausgelegt, sondern war für Miner gedacht.
Ob man nun die dedizierte Codebasis von Tensor und DXR verschlankt, damit beschleunigt und auf dessen Basis dann so tut das v4 schneller wäre, ändert daran nichts. Das ist nur nutzbar wenn es die Entwickler auch einpflegen, dazu muss es zur eigenen Engine passen, was es in vielen Fällen nicht tut. Nvidia versucht also mit DLSS3 und mehr Treibercheats das eigene Feature durchzusetzen, weil AMD mit FSR einen dicken Brocken am Start hat, der aufzeigt das man weder Tensor noch RT Core dazu wirklich braucht, um vergleichbare Qualität und Beschleunigung zu erreichen. Zudem noch abwärtskompatibel und hardwareübergreifend einsetzbar.
Was man an der Preisgestaltung von nVidia erkennt ist, daß sie AMD zwingen die Preise bei ähnlicher Leistung höher anzusetzen, was immer deren Vorteil war. Ich hoffe sie gehen da nicht mit. NVidia geht es nur darum Ampere abverkaufen zu können, dieses Problem hat AMD nicht. Damit könnte AMD für nVidia Ampere das Zünglein an der Waage sein und nVidias Nachfolgequartale in denen man Ampere weiter anbschreiben muss, zum Absturz bringen. Ich hoffe sie tun es und verpassen diesem Verein eine Denkzettel. Genau deshalb ist es so still, da kommt eine riesige Welle auf nVidia zu, das ist so zitterig wie noch nie von denen.
SER haben sie aus Vulkan geklaut. Keine Errungenschaft von NVidia, sondern von AMD.
SER haben sie aus Vulkan geklaut. Keine Errungenschaft von NVidia, sondern von AMD.
Vulkan wird nicht von AMD gebastelt, sondern von AMD und Nvidia und vielen Anderen.
SER haben sie aus Vulkan geklaut. Keine Errungenschaft von NVidia, sondern von AMD.
Gleiches lässt sich übrigens auch von FreeSync und SAM sagen ...
Kleebl00d
2022-09-23, 14:59:54
Ein Limit für Übertaktungen festzulegen.
Mit Trockeneis sollte dieser durchaus erreichbar sein, evtl. sogar mit Sub-Ambient Flüssigkeitskühlungen.
Gut, da hätte ich wohl konkreter fragen sollen. Warum genau sollte man Übertaktung limitieren? Damit geht ja auch immer eine immense thermische Leistung einher, das zaubert man ja nicht einfach weg und limitert somit sowieso.
Warum also solche Spielchen wie N2-Kühlung damit limitieren? So was sieht doch immer gut aus, wenn Extremübertakter aus Chip X mit Takt Y Benchmarkergebnis Z erreicht. Schlagzeilen und Prestigue und so.
Und wenn man sie damit nicht limitieren sollte weil das Limit noch deutlich höher angesetzt ist wiederhole ich meine Frage: Warum gibt es dann überhaupt ein Limit?
Damit der Boostalgorithmus Spielraum für niedrige Temperaturen hat.
Wie erreicht man das denn durch das limitieren auf Taktraten wo der Chip unter Stock-Kühlung schon das Handtuch wirft? Leuchtet mir auf den ersten Gedanken nicht ein.
SER haben sie aus Vulkan geklaut. Keine Errungenschaft von NVidia, sondern von AMD.
Das ich nicht lache, schau mal wer der größte Kontributor bei Vulkan ist
Kleebl00d
2022-09-23, 15:19:31
Das ich nicht lache, schau mal wer der größte Kontributor bei Vulkan ist
Zitat aus Wikipedia:
"Vulkan ist abgeleitet von AMD Mantle"
...also AMD?
Das ich nicht lache, schau mal wer der größte Kontributor bei Vulkan ist
Ja um ihren ganzen dedizierten Quatsch so auszulegen das es ja nicht kompatibel ist und dann abzumelken was man selbst auf Cudabasis umsetzen kann und anders zu nennen.
AMD=>Mantle=>Vulkan<-Khronos Group<-Nvidia als Teil der Khronosgroup.
Das ICH nicht lache, was hier manchmal für ein Blödsinn von dir kommt! Ever the Self_Gast.
Zitat aus Wikipedia:
"Vulkan ist abgeleitet von AMD Mantle"
...also AMD?
Ach danke für die Erklärung hatte wohl einen fundamentalen fehlerfehler, jetzt check ich, natürlich sind ist Linus Torvalds der größte Kontributor an allen Linux Distributionen immerhin basieren die ja auf seiner initalen Schöpfung......
Ja um ihren ganzen dedizierten Quatsch so auszulegen das es ja nicht kompatibel ist und dann abzumelken was man selbst auf Cudabasis umsetzen kann und anders zu nennen.
AMD=>Mantle=>Vulkan<-Khronos Group<-Nvidia als Teil der Khronosgroup.
Das ICH nicht lache, was hier manchmal für ein Blödsinn von dir kommt! Ever the Self_Gast.
Okay, wenn Nvidia den dedizierten Quatsch einbaut, dann ist es schlecht, aber wenn AMD Mantle für GCN entwickelt ist das okay.
Bisschen weniger heucheln bitte.
Logisch. SER scheint was zu können.
Aber es beeinflußt nicht die nominelle Rohleistung
Aber potentiell die erreichbare Performance/TFLOP
und ist zudem ein Feature primär für RayTracing, nicht für die normale Grund-Performance.
SER kann offenbar die Threads neu zusammenstellen.
Damit ein massiver Parallelbeschleuiniger wie eine GPU so schnell ist wie er ist, braucht er eine große Anzahl an Threads die den selben Programmablauf haben.
Bei Nvidia sind es 32 Threads in einem Warp die alle den selben Shader und die selben Befehle abarbeiten müssen um den maximalen Durchsatz zu erreichen.
Beim Rasterizing ist der Ausgangspunkt immer ein Dreieck und die davon abgedeckten Pixel. Da es sehr wahrscheinlich ist, dass diese den selben Shader durchlaufen und damit ist es recht einfach Pakete aus 32 Threads zu finden.
Beim Raytracing könnten dagegen die Rays kreuz und quer schießen und alle möglichen Threads starten, weshalb hier das potential natürlich bedeutend höher ist.
Es sind in der Realität eigentlich sogar die primary rays die sehr wahrscheinlich aufs selbe Dreieck treffen und damit auch den selben Shader starten und am effizientesten wären, aber in den meisten Fällen gar nicht verwendet werden, da das Rasterizing immer noch diese Aufgabe übernimmt.
Das heißt jetzt aber nicht, dass es nicht auch beim Rasterizing Fälle geben kann die von einem Reordering der Threads profitieren würden.
Beispielsweise könnte man damit bei einem Shader der eine Verzweigung enthält diejenigen Threads die Pfad A und die die Pfad B nehmen neu in einem Warp anordnen und damit die Auslastung und Performance erhöhen.
Bisher bleiben alle Threads eines Warps von Anfang bis zum Ende immer zusammen, und wenn es Verzweigungen gibt werden für die Threads die den aktuellen Pfad nicht Ausführen einfach NOPs eingeschoben.
Leonidas
2022-09-24, 05:12:25
Deswegen ist SER auch sehr willkommen. Weil es RayTracing beschleunigt, ohne dafür massiv an Rechenwerken zulegen zu müssen. RayTracing einfach nur mit Rohleistung erschlagen zu wollen, wird wohl noch einige GPU-Generationen nicht gelingen.
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.