Diskussion zu: Hardware- und Nachrichten-Links des 18./19. Dezember 2021

[Leonidas]

Link zur News:
https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-1819-dezember-2021

[GerryB]

zu Navi33:
Vllt. gibts ja schon den Samsung 24Gbps Vram, dann ist "Weniger Mehr"
bzgl. Bandbreite

[Rabiata]

zu Navi33:
Vllt. gibts ja schon den Samsung 24Gbps Vram, dann ist "Weniger Mehr"
bzgl. Bandbreite
Das würde Navi33 auf RX 6700 Niveau heben was die Speicherbandbreite angeht. 64 GB Infinity Cache sollten auch für 1440p gut ausreichen. Wäre schon mal nicht schlecht.

Allerdings könnte es noch etwas dauern, 24Gbps wurde grade erst angekündigt. Und ob die GPU bei Navi 21 Rechenleistung nicht ein wenig am Speicherinterface verhungert, ist auch noch abzuwarten. Kaufen, untertakten und sich über sparsam abgelieferte RX 6700 XT Leistung freuen?

[Gast]

64 GB Infinity Cache sollten auch für 1440p gut ausreichen.



Ich glaub 64GB sind auch für 8k ausreichend.

[Legendenkiller]

bei "~60 / 40 / 16WGP" ....

fehlt eine Null oder wie ist das gemeint ?

[Gast]

Was ist ein "effektives Interface"?

[iamthebear]

Also wenn ich mir die Hardwaredaten von Navi33 ansehe so habe ich mittlerweile meine Zweifel, dass der vor Navi21 liegen wird:
.) Halber VRAM
.) Halbes Speicherinterface
.) Halber Infinity Cache
.) 20% weniger FP32 Einheiten

Also für mich sieht das eher nach ein bisschen mehr als Navi22 aus.

Also wenn ich raten müsste:
Navi33 = 6800 non XT = 400$ UVP
Navi32 = 1.7-1.8x 6900 XT = 1000$ UVP
Navi31 = 2.5x 6900 XT = 2000$ UVP

Dass AMD mit dem VRAM geiziger ist macht Sinn denn VRAM ist ja auch kräftig im Preis gestiegen während mit 5nm die Kosten/Transistor gefallen sind. Abgesehen davon muss man ja irgendwo eine Schwachstelle einbauen. Sonst hat AMD in 3-4 Jahren das Problem Nachfolgerkarten los zu werden. Abgesehen davon zeigt der Markt ganz klar, dass für 50% mehr Performance mehr gezahlt wird als für 50% mehr VRAM (siehe Vergleich RTX 3060 vs. 3070).

Dass sich die 2.5x nur auf die theoretische Leistung und nicht auf die fps beziehen sollte auch klar sein. 2.5x fps wird in 4K ohne starke RT Effekte kaum möglich sein da aktuelle CPUs gar nicht so schnell sind.

[konkretor]

Ich gehe von sehr hohen UVP aus, keine unter 500$Leute kaufen ja alles was nicht bei 3 beim Miner ist....

[Leonidas]

zu Navi33:
Vllt. gibts ja schon den Samsung 24Gbps Vram, dann ist "Weniger Mehr"
bzgl. Bandbreite

Das würde Navi33 auf RX 6700 Niveau heben was die Speicherbandbreite angeht.


24 zu 16/14 Gbps gibt einen dicken Bumms ... aber das reicht eigentlich nicht aus. Deswegen hatte ich ja die effektiven Interface-Breiten angegeben:
N22 WQHD: 619 Bit
N33 FullHD: 328 Bit.
Man bräuchte 89% Mehrtakt, um das auszugleichen. Natürlich kann es sein, dass man auch mit etwas weniger Speicherbandbreite auskommt. Aber schlagen - mit einer Lösung, die überall drunter liegt? Auf 8 GB sowieso nicht.




bei "~60 / 40 / 16WGP" ....
fehlt eine Null oder wie ist das gemeint ?

Nada. Ist nebenbei eine direkte Kopie der Aussage des Twitterers.




Was ist ein "effektives Interface"?

Effektives Interface = unter Einrechnung der Hitrate des Infinite Cache. Ein solch breites Interface bräuchte man, wenn man keinen IFC hätte.

[basix]

24 zu 16/14 Gbps gibt einen dicken Bumms ... aber das reicht eigentlich nicht aus. Deswegen hatte ich ja die effektiven Interface-Breiten angegeben:
N22 WQHD: 619 Bit
N33 FullHD: 328 Bit.
Man bräuchte 89% Mehrtakt, um das auszugleichen. Natürlich kann es sein, dass man auch mit etwas weniger Speicherbandbreite auskommt. Aber schlagen - mit einer Lösung, die überall drunter liegt? Auf 8 GB sowieso nicht.
Dazu hätte ich folgende Anmerkungen:
- RDNA2 ist bei N22 und N21 bezüglich Infinity Cache stark überdimensioniert. Macht auch Sinn so beim "ersten ihrer Art". N22 hat bei 1440p effektiv >1 TB/s Bandbreite. Die RTX 3070, welche schneller ist, gerade mal 448 GByte/s
- Die Speicherbreite in [bit] ist hier der falsche Werte, es müsste eher die Speicherbandbreite in [GByte/s] sein
- RDNA3 kann weitere Architekturverbesserungen einbringen, welche den Bandbreitenbedarf reduzieren könnten. Und man hat seit RDNA2 dazugelernt, man weiss eher was man vom IF$ erwarten kann und allenfalls neue / angepasste Caching-Paradigmen
- 64 MByte IF$ + 128 Bit SI @ 16 GT/s @ 1440p --> Effektiv ~550-600 GByte/s --> 1.2-1.3x mehr als eine RTX 3070. Das ist nicht mehr weit weg von einer 6900XT
- Geht man nun etwa gleich effizient wie Ampere mit Bandbreite um und setzt 18-21 GT/s GDDR6 ein, liegt eine 6900 XT definitiv drin. Nur nicht bei 4K.
- Ist man effizienter als Ampere unterwegs, geht es auch mit 16 GT/s Speicher (@1080p bis und mit 1440p; 4K wird knapp)


Edit:
Noch ein anderer Punkt. 8 GByte bei N33 wären viel zu wenig. 16 GByte sind für eine 1080-1440p Karte aber auch Overkill.

Folgender Vorschlag:
- 24GBit Speicher (wie im Artikel erwähnt) --> 12 GByte
- Neuartige Speicherkompression und/oder allgemeiner (immer eingeschaltet) und gut funktionierender High Bandwidth Cache? Vega lässt grüssen ;)

Besonders den zweiten Punkt fände ich interessant. GDDR6 ist schlussendlich ein grosser Kostenfaktor auf Seiten BOM der Karte. Kann man hier sagen wir mal +50% "Speichermengeneffizienz" herausholen und die Karte verhält sich eher wie ein ~12 GByte Karte, wäre das genial.

[WedgeAntilles]

Dass AMD mit dem VRAM geiziger ist macht Sinn denn VRAM ist ja auch kräftig im Preis gestiegen während mit 5nm die Kosten/Transistor gefallen sind.
Komisch, mir war so hätte man hier im Forum seit ca. 1 Jahr darüber geheult (oder gelacht), was für ein Müll die Nvidia Karten doch alle sind, da sie ja so wenig Vram haben.

Sollten die kolportierten Werte stimmen wäre das doch lächerlich.
12GB für ne Karte die 50% schneller sein soll als ne 6900XT?
Wie gesagt, bei Nvidia gilt eine 10GB 3080 als MÜll und eine 3080TI mit 12GB ebenfalls.

Aber gut, vermutlich ist der Vram-Bedarf halt variable.
Hat AMD mehr Vram: Vram Bedarf riesig, das absolut wichtigste.
Hat AMD weniger Vram: Vram braucht keiner, völlig überschätzt.


Oder aber man hält die genannten Werte für Unsinn (ich kann mir z.B. die genannte Ram-Bestückung nicht vorstellen) - aber dann braucht man ja auch über die anderen Werte nicht diskutieren.

[basix]

8-12 GByte halte ich bei den Leistungsklassen auch für nicht brauchbar. 16 GByte ist so viel, dass es bei 4K nirgends ein Problem gibt und bei der "Fury-Edition" kann man auch 32 GByte spendieren.

Aber wie in meinem vorherigen Post editiert: Gibt noch andere Möglichkeiten.

[Rabiata]

Folgender Vorschlag:
- 24GBit Speicher (wie im Artikel erwähnt) --> 12 GByte
- Neuartige Speicherkompression und/oder allgemeiner (immer eingeschaltet) und gut funktionierender High Bandwidth Cache? Vega lässt grüssen ;)

Besonders den zweiten Punkt fände ich interessant. GDDR6 ist schlussendlich ein grosser Kostenfaktor auf Seiten BOM der Karte. Kann man hier sagen wir mal +50% "Speichermengeneffizienz" herausholen und die Karte verhält sich eher wie ein ~12 GByte Karte, wäre das genial.
Bei den Preisen frage ich mich, was der Umstieg auf HBM kosten würde. Vor zwei Wochen war auf gpumag zu lesen (https://www.gpumag.com/gddr5-gddr5x-hbm-hbm2-gddr6/), daß HBM2 im Jahr 2017 deutlich teurer war als GDDR6 heute.

Back in 2017, the estimated cost for HBM2 was somewhere around $150 and $170. That’s a lot of money even when compared to the most expensive GDDR6 memory that costs around $90 for 8GB.
Was hier noch fehlt. ist die Preisentwicklung für HBM2 seit 2017.

[basix]

Ich hatte eher im Sinn, dass High Bandwidth Cache mit GDDR6 funktioniert und nicht mit HBM.

[Rabiata]

Ich hatte eher im Sinn, dass High Bandwidth Cache mit GDDR6 funktioniert und nicht mit HBM.
Ich hatte im Sinn, dass High Bandwidth Cache dazu gedacht ist, nicht den teuren HBM Speicher zu brauchen, so daß GDDR6 ausreicht.
Man könnte auch High Bandwidth Cache und HBM nehmen, wäre halt extra teuer und es ist fraglich, wie viel der High Bandwidth Cache da noch bringen würde.

[Leonidas]

- 24GBit Speicher (wie im Artikel erwähnt) --> 12 GByte

Würde wohl jeder gern sehen. Aber so lange das nicht existiert, bleibt nur die Wahl zwischen 8 GB und 16 GB.

[basix]

Ich hatte im Sinn, dass High Bandwidth Cache dazu gedacht ist, nicht den teuren HBM Speicher zu brauchen, so daß GDDR6 ausreicht.
Man könnte auch High Bandwidth Cache und HBM nehmen, wäre halt extra teuer und es ist fraglich, wie viel der High Bandwidth Cache da noch bringen würde.

Ich glaube wir missverstehen uns da ;)

High Bandwidth Cache aus Vega hat nichts mit dem Infinity Cache zu tun (welcher noch deutlich höhere Bandbreiten liefert).

High Bandwidth Cache = VRAM. Und der HBCC (HBC-Controller) überwacht das alles. VRAM wird so als Cache verwendet und wenig gebrauchte Daten (oder mit geringer Bandbreitenanforderung) werden in den System RAM ausgelagert. Ohne HBCC passiert das nicht in der selben Weise. VRAM wäre in diesem Modell dann L4-Cache und Infinity-Cache wäre der L3-Cache. Der System-RAM ist dann effektiv der "VRAM". High Bandwidth ist in diesem Kontext so zu verstehen, dass die GPU deutlich mehr Bandbreite zum lokalen VRAM hat als zum System-RAM via PCIe.

Hier entsprechende Infos zum HBCC:
https://www.computerbase.de/2017-07/radeon-rx-vega-vorgestellt/3/#abschnitt_der_high_bandwidth_cache_controller
Dies liegt daran, dass der HBCC so genanntes (flexibel großes) Page-Based Memory Management nutzt, das die Speicherdaten selbstständig in für die GPU optimale Pages aufteilt. Dadurch ist es zum Beispiel nicht nötig, immer einen kompletten Datensatz im Grafikspeicher zu haben. Dieser kann zum Teil im Grafikspeicher und zum anderen Teil im Systemspeicher liegen. Aktive Pages werden im High Bandwidth Cache (der HBM2-Speicher) gehalten, während inaktive in den Systemspeicher geschoben werden. Ohne HBCC würde auch inaktive Teile durchweg im Grafikspeicher gelassen oder müssten komplett in den Systemspeicher und bei erneuter Verwendung wieder zurück kopiert werden.
Dadurch verhält sich die Grafikkarte als hätte man effektiv mehr VRAM. Und wenn das mit den 8 GByte wirklich stimmt, wäre sowas sehr hilfreich. Und vom Prinzip her funktioniert das mit GDDR6 genau gleich gut wie mit HBM.

Bei Vega habe ich es aber so in Erinnerung, dass es ziemlich stark vom Spiel abhing, wie viel es genutzt hat. Und je nachdem sogar mit Whitelisting von Spielen? Ich weiss es nicht mehr. Vega ist aber schon bald 5 Jahre alt. Evtl. hat AMD nun eine Lösung, welche generell aktiv ist und gut funktioniert.

Würde wohl jeder gern sehen. Aber so lange das nicht existiert, bleibt nur die Wahl zwischen 8 GB und 16 GB.
Sehr richtig. Deswegen die Idee mit dem High Bandwidth Cache und HBCC ;)

Edit:
Hier noch ein GamersNexus Video von HBCC
https://www.youtube.com/watch?v=hyr9CS2Cf_0

Und hier sieht man, dass mit HBCC 10.7 GByte Speicher alloziert wurden, bei einer 8 GByte Karte ;)
https://techgage.com/article/a-look-at-amd-radeon-vega-hbcc/

Und hier ganz aktuell unser GPU-König Raff mit Vega 56 @ Far Cry 6 HD Textures ;)
https://www.youtube.com/watch?v=GlsMt8BwqHY

[Gast]

Navi33 Leistung einer jetzigen RX 6900XT - was gibt es da zu meckern?
Freuen ohne Ende; so viel Leistung.

Gäbe es diese im Laden für 500 € zu kaufen, wäre dies super.
Preislich, nun ja, wird natürlich nicht so sein, da Great Reset (Digitalisierung, Industrialisierung 4.0), Lieferengpässe, hohe Inflation, jeder will was vom Kuchen bei TSMC usw.

[Gast]

Was ist ein "effektives Interface"?

Interface unter Einrechnung der Hitrate des Infinity Caches. Was aber ein Blödsinn ist und nur stimmen würde wenn andere Karten gar keinen Cache hätten, was aber real nicht der Fall ist, alle Grafikkarten haben mehr oder weniger Cache nur nicht alle einen Fancy Namen dafür.

[Gast]

Sollten die kolportierten Werte stimmen wäre das doch lächerlich.
12GB für ne Karte die 50% schneller sein soll als ne 6900XT?
Wie gesagt, bei Nvidia gilt eine 10GB 3080 als MÜll und eine 3080TI mit 12GB ebenfalls.
Da muss ich dir Recht geben. 12GB bei so einer Karte wäre klar zu wenig, egal von welchem Hersteller. Die VRam Ausstattung der 3080TI, 3080 sowie der 3070TI und 3070 ist für mich klar zu wenig, wenn AMD dann auch mit nur 12GB um die Ecke kommt, dann ist das genauso zu wenig. Da müsste man schon massiv über einen billigen Preis gehen (locker 1/3 billiger als die Konkurrenz), was ich mir nicht vorstellen kann.

[Leonidas]

Insofern wäre ich für klotzen statt kleckern:
N33 mit 16 GB
N32 mit 24 GB
N31 mit 32 GB

[Lehdro]

Insofern wäre ich für klotzen statt kleckern:
N33 mit 16 GB
N32 mit 24 GB
N31 mit 32 GB
Aber bitte! Dann ergibt das auch Sinn, AMD hat eigentlich nie mit VRAM gespart, es sei denn es hatte technische Gründe (HBM @ Fury).

[WedgeAntilles]

Insofern wäre ich für klotzen statt kleckern:
N33 mit 16 GB
N32 mit 24 GB
N31 mit 32 GB

Klingt für mich plausibler als der Leak.
Vor allem wenn man sich überlegt, was man wohl für Preise für die Karten aufrufen wird.
1000 Euro für N32 wurde ja schon spekuliert.

Ich kann doch nicht 2022 eine Karte der neuen Gernation für 1000 Euro anbieten, mit 12 GB Ram.

Ich bin kein Freund von AMD (finde die Firma unglaublich unsympathisch), aber eine zu kleine Ram-Bestückung kann man ihnen wirklich nicht vorwerfen. Und dass es signifikant WENIGER Ram als in der aktuellen Serie geben soll finde ich hanebüchen. Da würde ich Haus und Hof drauf verwetten, dass das nicht passiert.

Mich wundert nur, dass die Quelle doch in den letzten Monaten eigentlich eine gute Historie hat, oder täusche ich mich da?
Aber jetzt so ein - in meinen Augen - offensichtlicher Murks?
Passt IMO nicht zusammen.

[basix]

Interface unter Einrechnung der Hitrate des Infinity Caches. Was aber ein Blödsinn ist und nur stimmen würde wenn andere Karten gar keinen Cache hätten, was aber real nicht der Fall ist, alle Grafikkarten haben mehr oder weniger Cache nur nicht alle einen Fancy Namen dafür.

Blödsinn ist das überhaupt nicht. Klar haben alle GPUs Caches, aber das endet in dieser Form bei modernen GPUs beim L2-Cache. Da diese Caches sehr klein sind, ist eine Bandwidth Amplification hinsichtlich grösserer Datenmengen praktisch nicht existent. Hier geht es mehr um Daten, auf welchen in kurzer Zeit viele Operationen gemacht werden, wo Peak Bandwidth entscheidend ist und welche zwischen den einzelnen Shader Arrays schnell ausgetauscht werden müssen.

Nun kommt Infinity Cache hinzu, bei welchem aufgrund der schieren Grösse man effektiv eine Bandwidth Amplification in Richtung GDDR erhält. Das ist das neue am Infinity Cache. Das hat man bei anderen GPUs nicht. Selbst GA102 hat nur 6 MByte L2$.

Bezüglich "effektivem Speicherinterface" muss man also beim L2-Cache schneiden. Nimmt man das gesamte Speichersystem und schneidet zwischen L2-Cache und dem Rest (direkter Anschluss ans GDDR-Interface oder wie bei RDNA2 Infinity-Cache und erst dann GDDR-Interface), "sieht" die GPU inkl. Infinity Cache eine andere Bandbreite als wenn die GPU direkt ans Speicherinterface angeschlossen wäre. Im Prinzip funktionieren ja alle Caches so (neben Latenzreduzierung und Data Locality).

Infinity Cache erlaubt es somit, mit einem schmaleren GDDR-Interface auszukommen. "Effektiv" aus Sicht der GPU bis und mit L2-Cache, hat die GPU aufgrund des Bandbreitenmulitplikators also deutlich mehr Bandbreite zur Verfügung.

Das kann man jetzt so aufstellen, dass man ein effektiv breiteres Speicherinterface hat (in [bit]). Kann man machen. Ich hätte allerdings nicht die Breite des Speicherinterfaces angegeben als "effektives Interface", sondern die "effektive Speicherbandbreite" (in [GByte/s], was näher an dem liegt was real passiert.


Insofern wäre ich für klotzen statt kleckern:
N33 mit 16 GB
N32 mit 24 GB
N31 mit 32 GB
Wie schon vor einigen Posts erwähnt: Wieso nicht etwas an Datenkompression, HBCC usw. basteln? Dadurch erhöht sich die Effektivität der Speichermenge. Das ist langfristig deutlich smarter als einfach Brute Force viel Speicher draufzuklatschen. Viel Speicher bedeutet komplexere PCBs (Clamshell), mehr Stromverbrauch (verdoppelte Anzahl GDDR6-Packages) und höhere Kosten (höhere Speichermenge). Und je nachdem wo die Kompression passiert (vermutlich in der GPU), würde man noch einen zusätzlichen Bandbreitenmultiplikator erhalten. Für dGPUs wie auch iGPUs von Vorteil. Und HBCC gibt es bereits in Vega, wenn auch noch nicht optimal umgesetzt.

Zudem liegt noch Potential auf Seiten Treiber. Nvidia kommt typischerweise ja mit weniger Speicher aus.

[Gast]

Blödsinn ist das überhaupt nicht. Klar haben alle GPUs Caches, aber das endet in dieser Form bei modernen GPUs beim L2-Cache. Da diese Caches sehr klein sind, ist eine Bandwidth Amplification hinsichtlich grösserer Datenmengen praktisch nicht existent.


Selbstverständlich gibt es das auch mit kleineren Caches. Wobei eine "Erhöhung der effektiven Bandbreite" durch Caches generell Schwachsinn ist, vielmehr ist es eine Verringerung der benötigen Bandbreite.

Und klar auch dass die 128MB bei RDNA eine wesentlich bessere Hitrate als die 6MB eines Ampere haben und man deshalb wie man sieht auch mit einem geringeren Interface auskommt. 0 ist die Hitrate aber auch bei kleineren Caches nicht, ansonsten wären diese ja umsonst und wenn man die von AMD angegebenen IF-Hitrates als "Bandbreitenerhöhung bzw. Interfaceverbreiterung" einrechnet, was wie gesagt generell ein Schwachsinn ist, auch wenn GPU-Hersteller schon seit Jahrzehnten bandbreitenschonende Maßnahmen als "effektive Durchsatzerhöhung" verkaufen wollen, geht man eben davon aus, dass die Cache-Hitrate bei anderen GPUs 0 ist.

Und letzteres ist eben nicht der Fall, bzw. andersrum müsste man eben auch bei anderen GPUs deren Cache-Hitrate mit einrechnen, die sicher bedeutend geringer als bei AMDs Monstercache aber eben auch nicht 0 sind.


Hier geht es mehr um Daten, auf welchen in kurzer Zeit viele Operationen gemacht werden, wo Peak Bandwidth entscheidend ist und welche zwischen den einzelnen Shader Arrays schnell ausgetauscht werden müssen.



Im Prinzip funktionieren ja alle Caches so (neben Latenzreduzierung und Data Locality).


Jeder Cache bringt nur etwas wenn Daten mehrfach gebraucht werden. Für ein Datum, dass genau 1x gebraucht wird bringt kein Cache irgendwas und wenn er mehrere GB an Größe hätte. Deshalb bringt den AMD Karten der ganze IF-Cache beispielsweise beim Ethereum Mining kaum was.



Wie schon vor einigen Posts erwähnt: Wieso nicht etwas an Datenkompression, HBCC usw. basteln? Dadurch erhöht sich die Effektivität der Speichermenge.


Verlustfreie Kompression bringt immer nur eine Bandbreitenersparnis und keine Ersparnis im Speicherbedarf, letzteres geht transparent nur mit verlustbehafteter Kompression.

[basix]

Selbstverständlich gibt es das auch mit kleineren Caches. Wobei eine "Erhöhung der effektiven Bandbreite" durch Caches generell Schwachsinn ist, vielmehr ist es eine Verringerung der benötigen Bandbreite

Ob erhöht oder reduziert ist eine Frage, von wo her du hineinschaust.

Hinsichtlich GDDR6 Interface: Ja, dort reduziert sich die benötigte Bandbreite. Schaut man von von dort in Richtung GPU, wird weniger Bandbreite benötigt.
Schaut man aber von Seiten L2$ in Richtung IF$ sowie Speicherinterface, bleibt die Bandbreite identisch wie ohne IF$. Man könnte einfach ein breiteres Speicherinterface ohne IF$ verwenden. Und genau hier an dieser Schnittstelle entsteht der Gedanke von effektiv erhöhter Speicherbandbreite, wenn man die L2-to-outer-world Bandbreite mit der off-chip Bandbreite vergleicht. Nach dem IF$ kann man eine höhere Bandbreite nutzen als die, die man vor dem IF$ hat.

Und Hitrate hat man sicher auch bei kleineren Caches. Ohne L1/L2 müsste die off-chip Bandbreite nochmals viel höher sein und man bekäme Probleme mit der Latenz und dem Stromverbrauch. Ändert allerdings nichts and dem Fakt, dass der L3$ (was der IF$ effektiv ist) eine zusätzliche Reduktion der off-chip Bandbreite ermöglicht. Oder eben mehr Bandbreite aus Sicht des L2$ zur Verfügung steht.

Verlustfreie Kompression bringt immer nur eine Bandbreitenersparnis und keine Ersparnis im Speicherbedarf, letzteres geht transparent nur mit verlustbehafteter Kompression.
Da würde ich gerne nachhaken. Bei einer PS5 werden komprimierte Daten in der SSD abgelegt. Und dann on-the-fly in den VRAM entpackt. Die Daten auf der SSD sind definitiv nicht verlustbehaftet. Wieso sollte das bei GPUs und dem VRAM nicht gehen?

Hier aus der Kraken Beschreibung (http://www.radgametools.com/oodlekraken.htm):
Kraken is an amazing new lossless data compressor that gets both high compression and super fast decode speeds!

Werden zwischen GPU und VRAM nur stark komprimierte Daten hin- und hergeschickt, kann man effektiv mehr Daten übertragen und auch mehr Daten im VRAM vorhalten können (komprimiert = geringere Grösse). Bereits heute sind Texturen usw. komprimiert und innerhalb der Caches ist bei AMD ebenfalls das meiste komprimiert. Am besten hat man alle Daten maximal komprimiert bis zum Zeitpunkt wo man effektiv mit den Daten etwas machen muss.

[matty2580]

Jetzt, da bekannt wird dass der 12400F doch deutlich teurer wird als der 11400F, verliere ich immer mehr dass Interesse an Alder Lake.

Da warte ich dann doch lieber auf Produkte in Intel 4, also einem möglichen 14400F.
Und da bin ich auch bereit, mit einer noch halbwegs modernen Node, einen Aufpreis zum 11400F zu akzeptieren.

Bis dahin muss die PS5 und Switch für mich reichen.
D.h. ich werde erst nach 5 Jahren PC Abstinenz wahrscheinlich wieder zum PC zurückkehren, aber auch nur wenn der PC für mich wieder bezahlbar wird.

Und so sorgt die Hardwareindustrie selbst dafür, dass Sony durch mich ordentlich weiter gefüttert wird. ^^

[ryan]

Jetzt, da bekannt wird dass der 12400F doch deutlich teurer wird als der 11400F, verliere ich immer mehr dass Interesse an


Wo wurde das bekannt, gibt es schon offizielle Preise? Preislistungen von einem shop vorm release sind immer mit Vorsicht zu betrachten, die liegen meist weit über den tatsächlichen Preisen nach release. Meinst du das hier:

https://videocardz.com/newz/intel-65w-alder-lake-s-pricing-has-been-leaked-6-core-cpus-to-cost-180-240-usd-4-core-110-140-usd

180USD beim 12400F sieht mir nicht nach deutlich teurer aus, sondern eher gleich bis leichte Preiserhöhung.


i3-10100 Cinebench R20 Werte gibt es hier:

https://www.hardwareluxx.de/index.php/artikel/hardware/prozessoren/53669-kleine-kometen-intel-core-i3-10100-und-core-i3-10320-im-test.html?start=2

[Gast]

Ob erhöht oder reduziert ist eine Frage, von wo her du hineinschaust.


Nicht wenn man wie üblich die Speicherbandbreite angibt, die verändert sich nicht dadurch egal was dahinter passiert.

Man könnte natürlich auch die Bandbreite irgendeiner Cache-Stufe angeben, macht aber keiner, in den Spezifikationen steht immer die Speicherbandbreite und die wird nicht irgendwie höher, egal durch welche Maßnahmen dahinter.

Ist wie gesagt nichts neues, der Schwachsinn wird ja schon seit Early-Z&Co so kommuniziert.


Schaut man aber von Seiten L2$ in Richtung IF$ sowie Speicherinterface, bleibt die Bandbreite identisch wie ohne IF$.


Dann müsste man aber wie gesagt die Cachebandbreiten angeben und nicht die Speicherbandbreite und sich dann noch irgendwas künstlich auf diese dazudichten was physikalisch gar nicht möglich ist.



Und Hitrate hat man sicher auch bei kleineren Caches. Ohne L1/L2 müsste die off-chip Bandbreite nochmals viel höher sein und man bekäme Probleme mit der Latenz und dem Stromverbrauch.


So ist es womit auch, wenn man mal über den Schwachsinn hinwegsieht, dass sich die Speicherbandbreite oder Interface nicht irgendwie magisch vergrößern, auch "normale" GPU eine höher effektive Bandbreite/Interface als deren physikalisches Interface hergibt zugesprochen werden müsste.
Klar bringt der IF deutlich mehr, das steht außer Frage, der Unterschied ist aber deutlich geringer als diese Tabelle hier vorgibt, weil eben die (unbekannten) Hitrates in den Caches der GPUs ohne IF nicht mit berechnet werden.



Da würde ich gerne nachhaken. Bei einer PS5 werden komprimierte Daten in der SSD abgelegt. Und dann on-the-fly in den VRAM entpackt. Die Daten auf der SSD sind definitiv nicht verlustbehaftet. Wieso sollte das bei GPUs und dem VRAM nicht gehen?


Das ist wie Direct Storage und entlastet nur die CPU und das PCIe Interface.
Die GPU wird sowohl von der Rechenleistung als auch von der Speicherbandbreite sogar mehr belastet und Caching sollte hier auch kaum helfen die Speicherbandbreite zu entlasten.

Der normale Vorgang ist ja, dass die Assets in welchem Format auch immer auf dem Festspeicher liegen. Diese werden dann in den Hauptspeicher geladen und von der CPU entpackt und anschließend über den PCIe im VRAM abgelegt.

Mit DirectStorage, werden die Assets direkt in gepackter Form in den VRAM geschrieben, die CPU selbst hat damit also nichts mehr zu tun, zumindest die Kerne, die Daten müssen ja immer noch übers PCIe Interface was in der CPU liegt. Die GPU ließt dann die gepackten Daten und entpackt sie und legt die Entpackten Daten im VRAM ab. GPU-seitig steigt damit der Bandbreitenbedarf minimal, weil anstatt 1x entpackte Daten schreiben, muss diese nun 1x gepackte Daten schreiben, 1x gepackte Daten lesen und 1x entpackte Daten Schreiben.

Auf den Konsolen verhält sich das durch den unified memory pool natürlich etwas anders, da das hin und herkopieren entfällt.
Was die neuen Konsolen so "besonders" macht ist einerseits, dass es durch den erstmaligen SSD-Einsatz eine enorme Steigerung der Bandbreite zum Festspeicher gibt, und wahrscheinlich noch wichtiger es gibt im SoC dezidierte Hardware zum entpacken der Game-Assets ohne die CPU-Kerne zu belasten.
Die alten Konsolen waren gar nicht so sehr durch das Fehlen der SSD ausgebremst, sondern durch die lahmen CPUs. Ich hab mal eine Xbox One auf SSD umgebaut, und die Ladezeiten verbessern sich überraschend wenig, weil das Limit gar nicht die Festspeicherbandbreite sondern die lahmen Jaguar Kerne sind.

Und ich habe nicht umsonst von transparenter Kompression gesprochen, also Kompression die ohne Wissen der Software die darauf läuft von der Hardware automatisch gemacht wird.

Assets die bereits in komprimierter Form und verwendet werden können sparen natürlich sowohl Bandbreite als auch VRAM. Nur gibt es da nichts großartiges zu holen, beispielsweise Texturen, die einen Großteil der Assets ausmachen werden seit Jahrzehnten nur in komprimierter Form verwendet.
Das zweite ist, die Daten müssen bereits von der Software in entsprechend komprimierter Form vorliegen damit das gut funktioniert, das ist nicht was man vernünftig erst bei der GPU ansetzen kann.

Was die GPU transparent machen könnte ist die Kompression von Daten die erst zur Laufzeit entstehen, wie beispielsweise die diversen Rendertargets.

Und wenn man diese on the fly verlustlos komprimiert kann man eben keinen VRAM einsparen, weil eine verlustlose Kompression im worst case eben nicht kleiner als das Original ist.

Das zweite Problem ist die Adressierung. Nicht umsonst werden für Texturen beispielsweise nur verlustbehaftete Formate mit fixer Größe verwendet. Ganz einfach weil man damit jederzeit auf die Texel die man benötigt zugreifen kann.

Bei verlustloser Kompression mit dynamischer Größe, und nur das würde auch VRAM einsparen, hat man keine Ahnung wo die eigentlichen Daten liegen, und man müsste jedes mal das gesamte komprimierte Konstrukt einlesen, wenn man auch nur einen kleinen Teil der Daten braucht. Damit würde man dann zwar VRAM einsparen aber sogar deutlich mehr Bandbreite benötigen, und vor allem jede Menge Energie unnötig für das dekomprimieren verschwenden.

[Leonidas]

i3-10100 Cinebench R20 Werte gibt es hier:
https://www.hardwareluxx.de/index.php/artikel/hardware/prozessoren/53669-kleine-kometen-intel-core-i3-10100-und-core-i3-10320-im-test.html?start=2

Danke! Habe es eingearbeitet.