News Radeon R9 390(X): AMD spricht über den HBM-Grafikspeicher von Fiji

Und jetzt nehme man HBM-Speicher der die Größe des für Streaming verwendeten Speicherpools dynamisch bestimmen kann (Treiberseitige Zuweisung wie ja auch bisher)
Der HBM-Speicher hat an sich mit dem Speichermanagement nichts zu tun. Das bestimmt der Treiber und teilweise die GPU selbst (wie du im nächsten Satz auch geschrieben hast?).

und mit einem eigenen Takt betreiben kann, unabhängig von dem Speicher der für den restlichen Renderprozesse benutzt wird
Das ergibt keinen Sinn. Denn falls die Addressen nicht interleaved auf die einzelnen Kanäle abgebildet werden hat man immer die Geforce 970 Problematik.

Es muss nicht der gesamte zu berechneden Datenverkehr auf einen gemeinsamen Zyklus in Wavefronts zusammen gefasst werden, oder eben es werden kleinere Wavefronts gebildet die dadurch Latenz und Effizienz des Speichers verbessern in Anwendungen.
Der Satz ergibt keinerlei Sinn. Wie kann ein Datenverkehr "zu berechnen" sein?
Des Weiteren ist der Begriff Wavefront hier vollkommen fehl am Platz. Der Begriff Wavefront bezeichnet bei AMD eine Gruppe von GPU-Threads die per SIMD/SIMT alle Befehle gemeinsam abarbeiten. Eine Wavefront ist bei AMD momentan 64 Threads groß. Die Größe einer Wavefront beeinflusst dabei wie viel Kontroll-Hardware die GPU benötigt (je kleiner die Wavefronts umso mehr). Allerdings geht bei kleineren Wavefronts auch weniger Performance durch mangelnde Datenparallelität verloren. Die Threads einer Wavefront arbeiten Speicherzugriffe ebenfalls gemeinsam ab. Dabei werden Speicherzugriffe einer Wavefront zusammengefasst, so dass die angeforderten Daten nicht mehrmals übertragen werden müssen. Das Zusammenfassen geschieht allerdings schon auf L1-Ebene, dh wenn mehrere Threads einer Wavefront bei der selben L1-Cache-Line einen Miss verursachen, wird sie nur einmal aus dem L2-Cache angefordert. Deshalb kommen beim L2-Cache nur noch L1-Misse an, der dann wiederum bei L2-Misse den DRAM abfrägt. Ergo haben Wavefronts an sich nichts mit den Speicherzugriffen auf dem DRAM zu tun.

Eventuell ändert sich nichts an FPS, doch mit Sicherheit hat man mehr Frames in denen höhere Texturen zum Einsatz kommen - wird nur schwierig dies in Benchmarks zu testen oder darzustellen.
Wie gut das Speichermanagment beziehungsweise Paging funktioniert ist primär davon abhängig, wie gut die enstprechende Engine, API, GPU oder der Treiber das implementiert und wie schnell die PCI-E Bandbreite ist. Es ist nicht (oder nur sehr wenig) davon abhängig welche Speichertechnologie für den GPU-DRAM letztendlich verwendet wird. Oder würdest du dir schnelleren CPU-DRAM kaufen, wenn die CPU anfängt Daten auf die Festplatte zu thrashen?

MIt HBM wird diesen Streamingeffekten und separaten Verarbeitungsgeschwindigkeiten unterschiedlicher GPU Einheiten entgegen gearbeitet
Ein weiterer Satz ohne Sinn. . . .
 
Zuletzt bearbeitet:
Nai schrieb:
Der HBM-Speicher hat an sich mit dem Speichermanagement nichts zu tun. Das bestimmt der Treiber und teilweise die GPU selbst (wie du im nächsten Satz auch geschrieben hast?).
Ja das ist bei HBM Speichrcontroller auch der Fall und auch im Treiber. Siehe dazu auch Nvidias Präsentation die ich schon mehrfach verlinkt habe. Manche haben diesen Fortschritt anscheinend völlig verpasst. Daher immer wieder deine Behauptungen es würde nicht gehen. Du bist hier einfach nicht up to date. http://www.cs.utah.edu/thememoryforum/mike.pdf

Das ergibt keinen Sinn. Denn falls die Addressen nicht interleaved auf die einzelnen Kanäle abgebildet werden hat man immer die Geforce 970 Problematik.

Eben nicht - genau das wäre kein Problem bei der GTX970, da man den 7. Cache Channel im eigenen Takt betreiben hätte können und die anderen nicht blockiert gewesen wären weil kein Read und Write zugleich auf dem Chanel möglich sind - mit HBM könnte man jeden Chanel beliebig bestücken ohne dass der gesamte Speicher in einem gemeinsamen Takt refresht werden muss.

Und was die Wavefronts angeht, habe ich den Begriff gewähl weil mir eben nicht der vielleicht passende eingefallen ist. Ich rede von den Daten die gesammelt werden um mit dem nächsten Takt in den Speicher geschrieben oder gelesen zu werden. Die bestehen aus den Daten, welche in den Wavefronts gruppiert wurden. Es geht lediglich um den Rhythmus der Speichertaktung und vollen Datenbelegung.

Vielleicht kannst du mir mit dem richtigen Begriff aushelfen.
 
Ja das ist bei HBM Speichrcontroller auch der Fall und auch im Treiber. Siehe dazu auch Nvidias Präsentation die ich schon mehrfach verlinkt habe. Manche haben diesen Fortschritt anscheinend völlig verpasst. Daher immer wieder deine Behauptungen es würde nicht gehen. Du bist hier einfach nicht up to date.
Wieso verlinkst du mir jetzt eine Präsentation wo der passende englische Begriff Memory Management keinmal auftaucht? Was hat die Präsentation überhaupt mit Speichermanagement (siehe zum Beispiel http://en.wikipedia.org/wiki/Memory_management) zu tun?

Eben nicht - genau das wäre kein Problem bei der GTX970, da man den 7. Cache Channel im eigenen Takt betreiben hätte können und die anderen nicht blockiert gewesen wären weil kein Read und Write zugleich auf dem Chanel möglich sind - mit HBM könnte man jeden Chanel beliebig bestücken ohne dass der gesamte Speicher in einem gemeinsamen Takt refresht werden muss.
HBM hätte an der Problematik bei der Geforce nichts geändert: Zu wenig GPU-interne Crossbar-Resourcen für die maximale Speicherbandbreite und ungleichmäßige Verteilung von L2-Cache-Segmenten auf Speicherkanäle, wodurch sich bei dem standard interleaved Layout auch bei den entsprechenden Speicheraddressen eine kleinere effektive Cache-Größe und Cache-Bandbreite ergeben. Noch weniger hat HBMs Single-Bank-Refresh mit der Problematik zu tun.

Ich rede von den Daten die gesammelt werden um mit dem nächsten Takt in den Speicher geschrieben oder gelesen zu werden. Die bestehen aus den Daten, welche in den Wavefronts gruppiert wurden.
Daten die Wo gesammelt werden und wie gruppiert werden?
 
Zuletzt bearbeitet:
Also da du es aus der Präsentation nicht abstrahieren kannst weiss ich jetzt wo dein Kenntnisstand ist.
In dieser HBM Präsentation wird eben die Fähigkeit des Speichercontollers Single Bench Refresh so zu nutzen wie von mir beschrieben wörtlich genannt. Offensichtlich diskutierst du etwas ohne die Grundlagen zu kennen.
 
In dieser HBM Präsentation wird eben die Fähigkeit des Speichercontollers Single Bench Refresh so zu nutzen wie von mir beschrieben wörtlich genannt.
Was zur Hölle hat Single-Bank-Refresh mit der Speichermagment/Memory Managment/Speicherverwaltung (je nachdem wie man es bezeichnen möchte) zu tun?
 
Ich schrieb doch, dass es in der Präsentation beschrieben ist. Nutze doch die Quellen die man dir gibt und schreib nicht einfach mal dein Unwissen raus. Lesen, verstehen und dann bei Verständnisschwierigkeiten beschreiben wo es hängt und man bekommt es erklärt. Dafür sind Foren da.

Wie soll den Singel Cell Refreh NICHTS mit dem Speichermagment/Memory Managment/Speicherverwaltung zu tun haben?
 
Zuletzt bearbeitet:
Daedal... Auch nach dem anschauen wird mir das aus der Quelle ehrlich gesagt nicht klar, also bitte sei mal konstruktiv und erklär das doch forengerecht anstatt einfach Nebelkerzen zu werfen. Wenn Du schon niveauhaltige Unterhaltung suchst, dann lebe diese auch vor und wirf nicht einfach mit Thesen und ominösen Quellen um Dich die vordergründig wenig bis nichts mit dem Thema gemein haben. Wenn Du was Sinnvolles zu sagen hast, dann tu es so dass auch möglichst alle Leser davon profitieren.
 
Zuletzt bearbeitet:
Wie kann das nicht klar werden wenn es in einem einfachen Satz da steht. Und Nebelkerzen würde ich werfen wenn das nicht schon mitlerweile mehrfach erklärt worden wäre in 3-4 verschiedenen Threads. Hier ist es nur noch ermüdend, dass man jetzt darüber diskutieren muss ob der Speichercontroller überhaupt bei HBM etwas mit SBR zu tun hat^^

Seite 12
Memory controller responsible for ensuring all banks get enough refreshes each refresh period
Damit wäre doch deulich geklärt was der memory controller mit dem SBR zu tun hat.

Auf Seite 13 ist sehr schön grafisch dargestellt welche Auswirkungen dies hat für Daten und deren Durchsatz
hbm_sbr-jpg.494491


Auf Seite 15 steht auch, dass der Speichercontroller Temperaturdaten aus dem HBM Speicher erhält und entsprechend den Takt anpassen kann um TDP-Budgets einzuhalten.

Wer mit dem Englischen nicht klar kommt kann auch in dem Artikle von Hardwareluxx diese Infos auf Deutsch erhalten:
http://www.hardwareluxx.de/index.ph...ine-erhoehung-der-speicherbandbreite-ist.html
Ergänzung ()

Man stelle sicih nun vor, dass Bank 1 bei der GTX 970 der zusätzliche 512 MB Speicher ist auf dem 7. Chanel. Der gesamte 3.5 GB Speicher muss warten wenn diese 512 MB refresht werden, da nur 1 der Rambausteine angesprochen werden kann und der andere nicht.

GM204_arch.jpg


So etwas wie diese Crossbar exisitiert bei HBM nicht mehr. Es gibt kein zwingendes gemeinsames Refresh aller Speicherbänke mehr.

Seite 16-18:
http://www.hotchips.org/wp-content/...Bandwidth-Kim-Hynix-Hot Chips HBM 2014 v7.pdf
1 bank : 2 sub-banks(64Mb) non-shared I/O between sub-banks

Dies ist alles schon ausführlich besprochen
Hier: https://www.computerbase.de/forum/t...-mehr-bandbreite.1475118/page-2#post-17379997
Und hier: https://www.computerbase.de/forum/t...-mehr-bandbreite.1475118/page-6#post-17380630
Und hier: https://www.computerbase.de/forum/t...-mehr-bandbreite.1475118/page-7#post-17380969

Und dort hast du auch gepostet - das ist gerade mal 8 Tage her:
https://www.computerbase.de/forum/t...mehr-bandbreite.1475118/page-14#post-17390321
Also wüsste ich kaum was du da nicht begriffen hast.

DRAMs.jpg
 

Anhänge

  • HBM_SBR.JPG
    HBM_SBR.JPG
    110,9 KB · Aufrufe: 647
Zuletzt bearbeitet:
Inwiefern aber hat jetzt der Controller letztlich was mit Memory Management zu tun?

Merkst Du eigentlich dass das Thema ursprünglich anders war (VRAM Memory Management), Du selbst sogar Texture Streaming als eine Art Möglichkeit genannt hast?

Post402, Satz 1. Wie hätte der Speichercontroller mit Memory Management nun zu tun?
 
Armandex0 schrieb:
Inwiefern aber hat jetzt der Controller letztlich was mit Memory Management zu tun?
Das ist jetzt aber wirklich albern, oder?
Ich weiss nicht warum ich diesen Satz beim Thema HBM Speicher deutlich öfter zitieren muss als je zuvor:
Wer sich beim argumentieren dumm stellt, erscheint nicht intelligenter.

Was ist Pos 402?
Mobil sieht man keine Beitragsnummern. Bitte verlinke Forengerecht, damit man weiss wovon du redest. Und zitiere bitte die Passage die du meinst.

Und das Thema ist HBM Speicher als ich eben auf den Threadtitel geschaut habe.

Texture Streaming unter GDDR5:
Es wird ein Speicherpool für die Texturen gebildet. Der Gesamte Speicher wird in regelmäßigen Takten gleichzeitig refresht. Texturen könnten mit kleinerem Speicherpool auskommen, wenn der Speicherpool z.B. doppelt so hoch getaktet wird wie der restliche Speicher der das andere Rendering und Spieldynamik beinhaltet. Oder man könnte mit der selben größe des Texture-Streaming-Pools doppelt so viele Mip-Levels streamen als bisher für höhere Qualität ohne Leistungsverlust. Oder man könnte den Speicherpool für Texturen dynamisch zwischen diesen beiden Möglichkeiten switchen lassen je nach verfügbarem Speicher.
Dies alles sind Möglichkeiten die HBM bietet - wie kann da der Speichercontroller nichts mit zu tun haben?
 
Zuletzt bearbeitet:
Ergänzung vom 23.05.2015 07:27 Uhr: Man stelle sicih nun vor, dass Bank 1 bei der GTX 970 der zusätzliche 512 MB Speicher ist auf dem 7. Chanel. Der gesamte 3.5 GB Speicher muss warten wenn diese 512 MB refresht werden, da nur 1 der Rambausteine angesprochen werden kann und der andere nicht. Es gibt kein zwingendes gemeinsames Refresh aller Speicherbänke mehr.
1. Eine Bank ist kein Channel
2. Refresh aller 8 Channels ist bei der Geforce 970 "gleichzeitig" möglich, da jeder Channel seinen eigenen Memory Controller hat und ist auch gar nicht das Problem. Die Geforce 970 Problematik ist, dass eben kein gleichzeitiges Read/Write auf jeden der 8 Channels möglich ist. Denn der 7 und 8 Memory Controller teilen sich einen Anschluss an das 7. L2-Cache-Segment, wodurch die "Bandbreite" zwischen L2 und Memory Controller limitiert. Das ist wieder unabhängig davon, was jetzt letztendlich am Memory Controller für ein Speicher dranhängt.

Ich werd das Gefühl nicht los, dass du nicht einmal weißt was ein DRAM-Refresh ist.

So etwas wie diese Crossbar exisitiert bei HBM nicht mehr.
Sicher gibt es bei HBM kein GPU-internes Kommunikationsnetzwerk mehr. Wer braucht schon soetwas mit HBM? L2 und SMs Kommunizieren dann gemeinsam nur mit Luft und Liebe!

Es wird ein Speicherpool für die Texturen gebildet.
Das ist Memory Management.
Der Gesamte Speicher wird in regelmäßigen Takten gleichzeitig refresht.
Das macht der Memory Controller. Hat aber nichts mit dem ersteren zu tun.

Texturen könnten mit kleinerem Speicherpool auskommen, wenn der Speicherpool z.B. doppelt so hoch getaktet wird wie der restliche Speicher der das andere Rendering und Spieldynamik beinhaltet.
Der benötigte Speicherplatz ist nicht von der Taktung abhängig. Außerdem ist, zum wiederholten male, auch bei HBM-GPUs das Speicherlayout interleavt, weil alles andere keinen Sinn ergibt beziehungsweise man dann auf jeden Fall die "Geforce 970 Problematik" hat. Dadurch kannst du ein Objekt nicht auf einen bestimmten Kanal abspeichern sondern es wird automatisch zyklisch auf die einzelnen Kanäle aufgeteilt. Ergo funktioniert deine Überlegung mit der spezifischen Taktung nicht mehr.
Oder man könnte mit der selben größe des Texture-Streaming-Pools doppelt so viele Mip-Levels streamen als bisher für höhere Qualität ohne Leistungsverlust.
Technobabbel?
Oder man könnte den Speicherpool für Texturen dynamisch zwischen diesen beiden Möglichkeiten switchen lassen je nach verfügbarem Speicher.
Technobabbel?

Dies alles sind Möglichkeiten die HBM bietet - wie kann da der Speichercontroller nichts mit zu tun haben?
Das was du gesagt hast erklärt immer noch nicht was Speicherverwaltung mit Single Bank Refresh zu tun hat oder der Speichercontroller mit der Speicherverwaltung.
 
Zuletzt bearbeitet:
Na dann schreibst du "technobabbel" wenn du es nicht verstehst. So ist das also bei Lernresistenz.
Refresh aller 8 Channels ist bei der Geforce 970 "gleichzeitig" möglich, da jeder Channel seinen eigenen Memory Controller hat und ist auch gar nicht das Problem.
Es sind aber nur 7 Channel und es geht nicht darum ob es gleichzeitig möglich ist, sondern ob es auch einzeln möglich ist - du scheinst es nicht verstehen zu wollen.

Sicher gibt es bei HBM kein GPU-internes Kommunikationsnetzwerk mehr. Wer braucht schon soetwas mit HBM? L2 und SMs Kommunizieren dann gemeinsam nur mit Luft und Liebe!
Was für ein sinnloses Argument - hast du nun behauptet HBM benutzt eine Crossbar? Da hast du dir auch schon die Quellen angeschaut? Verlink das doch mal bitte hier und belege deinen Sarkasmus.

Es ist offensichtlich, dass du absolut gar keine Ahnung von der Hardwareseite hast - deine immer wiederkehrenden Argumentation ist aus Softwaresicht ausgelegt und da ändert sich prinzipiel nichts, denn die HBM Techniken benötigen keinerlei Änderung im Code. Doch versuche doch nicht deinen Unwissenheitsstand hier als den aktuellen technischen Stand zu verkaufen. Ich würde gerne mal sehen wie du Substanz hier einbringst.
Ergänzung ()

Nai schrieb:
Der benötigte Speicherplatz ist nicht von der Taktung abhängig. Außerdem ist, zum wiederholten male, auch bei HBM-GPUs das Speicherlayout interleavt, weil alles andere keinen Sinn ergibt beziehungsweise man dann auf jeden Fall die "Geforce 970 Problematik" hat. Dadurch kannst du ein Objekt nicht auf einen bestimmten Kanal abspeichern sondern es wird automatisch zyklisch auf die einzelnen Kanäle aufgeteilt. Ergo funktioniert deine Überlegung mit der spezifischen Taktung nicht mehr.

Du beschreibst GDDR5 - wo ist eine Quelle, dass dies bei HBM ebenso ist - alle Quellen sagen dies sei so nicht mehr nötig um maximale Auslastung zu erhalten. Der Grund: Single Cell Refresh - einfach mal das gelesene akzeptieren. Das ist ja nciht meien Behauptung, wie du in allen Links erkennen kannst.

Und was mir gerade einfällt - selbst die GTX 970 hat das mit GDDR5 angeblich geschafft. Zumindest war genau das "Segmented Memory Allocation", genau das was du hier schreibst es würde nicht gehen:
http://www.anandtech.com/show/8935/...cting-the-specs-exploring-memory-allocation/3
Virtual_address_space_and_physical_address_space_relationship_575px.png


Without going quite so far to rehash the entire theory of memory management and caching, the goal of memory management in the case of the GTX 970 is to allocate resources over the entire 4GB of VRAM such that high-priority items end up in the fast segment and low-priority items end up in the slow segment. To do this NVIDIA focuses up to the first 3.5GB of memory allocations on the faster 3.5GB segment, and then finally for memory allocations beyond 3.5GB they turn to the 512MB segment, as there’s no benefit to using the slower segment so long as there’s available space in the faster segment.

Und jetzt erzähle mir nochmal dies wäre mit HBM und Single Cell Refresh nicht deutlich effektiver.
 
Zuletzt bearbeitet:
Na dann schreibst du "technobabbel" wenn du es nicht verstehst. So ist das also bei Lernresistenz.
Weißt du, die Warps in HBM kollidieren mit dem L2-Cache und die FPUs werden durch die Wavefronts am PCI-Controller bei Bank-Conflicts ausgelöst, wodurch der Interposter von HBM bei den TMUs die Reihenfolge der Pakete vergrößert. . . und ähm ach ja Single-Cell-Refresh!!!!!!

Es sind aber nur 7 Channel und es geht nicht darum ob es gleichzeitig möglich ist, sondern ob es auch einzeln möglich ist - du scheinst es nicht verstehen zu wollen.
1. Die Geforce 970 hat 256 Bit interface also 8 32-Bit-GDDR5 Kanäle mit je einem Speichercontroller, die sich um den Refresh kümmern.
2. Single Bank Refresh bezieht sich nicht auf Kanäle sondern auf die Bänke innerhalb eines Kanals: Während eine Bank refresht, also die Ladung der Speicherzellen der Bank wiederhergestellt wird, können die anderen Bänke weiter arbeiten um den Kanal zu befeuern, wodurch weniger Speicherbandbreite durch das Refresh verloren geht. Das hat so ungefähr gar nichts mit der Geforce 970 Problematik zu tun. . . .


Was für ein sinnloses Argument - hast du nun behauptet HBM benutzt eine Crossbar? Da hast du dir auch schon die Quellen angeschaut? Verlink das doch mal bitte hier und belege deinen Sarkasmus.
Ein GPU internes Kommunikationsnetzwerk zwischen L2-Cache und SMs hat so ungefähr gar nichts mit der Speichertechnologie zu tun und wird auf alle Fälle benötigt. Oder wie soll deiner Meinung nach bei HBM die Kommunikation zwischen SMs und L2 von statten gehen? Durch "Single-Cell-Refresh"?

Ich würde gerne mal sehen wie du Substanz hier einbringst.
:lol:

Du beschreibst GDDR5 - wo ist eine Quelle, dass dies bei HBM ebenso ist - alle Quellen sagen dies sei so nicht mehr nötig um maximale Auslastung zu erhalten. Der Grund: Single Cell Refresh - einfach mal das gelesene akzeptieren. Das ist ja nciht meien Behauptung, wie du in allen Links erkennen kannst.
Nenn es doch endlich auch mal richtig und nicht Single-Cell-Refresh. Single Bank Refresh hat mal wieder gar nichts mit der genannten Problematik zu tun. Und nenne mir bitte auch nur eine Quelle die sagt, dass ein Interleaving bei den HBM Channels nicht mehr nötig ist. Bitte nur eine! Und die mir auch gleich erklärt was Single-Bank-Refresh damit zu tun hat! Aber ich weiß schon: Das folgt alles aus dem Quellen, die Daedal bisher gepostet hat, die er auch so gut verstanden hat, dass er die Fachbegriffe falsch wiedergibt, und Nai ist nur zu dumm zum abstrahieren :lol: .

Ich kann dir auch eine anschauliche Erklärung liefern, wieo man bei HBM weiterhin Interleaving benötigt:
Nehmen wir an wir würden unsere virtuellen Addressen linear auf physische Addressen abbilden. Dann wäre beispielhaft 0 bis 512 MiByte der 1. Kanal, 512 bis 1024 MiByte der 2. Kanal. Nehmen wir an ein Objekt wäre 50 MiByte groß. Dann würde es wahrscheinlich komplett in einem der beiden Kanäle liegen. Beim Lesen dieses Objektes würde der andere Kanal unbenutzt bleiben, die Speicherbandbreite wäre dementsprechend halbiert. Deshalb trickst man, dass man die virtuellen Addressen interleaved auf die physischen abbildet: 0 bis 1 MiByte der erste Kanal, 1 bis 2 MiByte der zweite Kanal, 2 bis 3 MiByte der erste Kanal, 3 bis 4 MiByte der zweite Kanal. Durch dieses Interleaving würde sich das Objekt nun halbe halbe in beiden Kanälen befinden, wodurch man auch die Bandbreite beider Kanäle ausnutzen könnte.

Wie lässt sich bei HBM diese Problematik durch Single-Bank-Refresh und ohne Interleaving vermeiden? Erkläre mir das bitte!

Und was mir gerade einfällt - selbst die GTX 970 hat das mit GDDR5 angeblich geschafft. Zumindest war genau das "Segmented Memory Allocation", genau das was du hier schreibst es würde nicht gehen:
Ich schrieb bereits, dass man ohne Interleaving die Geforce 970 Problematik hätte. Genau die du hier mit der Quelle belegst.

Und jetzt erzähle mir nochmal dies wäre mit HBM und Single Cell Refresh nicht deutlich effektiver.
Ok dann erkläre mal, wie genau wird das "Segmented Memory Allocation" durch Single-Bank-Refresh effektiver wird! Ganz geschweige von den übrigen Antworten die du uns auch noch schuldig bist, da du stattdessen lieber eine neue Sau durch Dorf treibst.
 
Zuletzt bearbeitet:
Ok dann erkläre mal, wie genau wird das "Segmented Memory Allocation" durch Single-Bank-Refresh effektiver wird! Ganz geschweige von den übrigen Antworten die du uns auch noch schuldig bist, da du stattdessen lieber eine neue Sau durch Dorf treibst.
Aha...na dann ist alles klar. Ich soll dir nun erklären wie etwas funktioniert von dem du bis eben noch behauptete hast es existiere gar nicht und geht nicht. Ich denke nicht, dass ich dich auf diese Weise durch jeden einzelnen Satz führen möchte den du offensichtlich technisch nicht erfassen kannst.

Ich kann dir nur raten die Quellen zu nutzen um dich zu informieren.
 
Ich soll dir nun erklären wie etwas funktioniert von dem du bis eben noch behauptete hast es existiere gar nicht und geht nicht
Sagte ich nie ?

Ich denke nicht, dass ich dich auf diese Weise durch jeden einzelnen Satz führen möchte den du offensichtlich technisch nicht erfassen kannst.
Soll heißen: Daedal kann es gar nicht erklären.
 
Ich habe es schon zweimal erklärt. Du musst es verstehen oder weitere Grundlagen dafür schaffen dies zu tun.
 
"Erklärt" hast Du gar nichts Daedal. Ich setz Dich hier auf ignorieren, die ständigen Denunziationsversuche gegenüber Anderen anhand wirrer Ausführungen und zusammenhangloser Quellen nervt einfach tierisch. Mir kommen Deine Äußerungen, hier im Forum allgemein, eher wie Propaganda oder absichtliche Provokation vor. Ist wohl die beste Methode um provozierten Anfeindungen gemütlich aus dem Weg zu gehen.
 
Also keiner hat dich dazu aufgefordert hier meinen Ausführungen folgen zu müssen.
Man liest einfach eine Thread nicht wenn er einen nicht interessiert. Du denkst du kannst das Thema Personalisieren und dann ohne Inhalte wie deinen letzten Beitrag etwas das du nicht verstehst einfach mal kleinreden.

Welche Fakten hast du denn hier eingebracht?
Keine Links, keine technischen Quellen
..hmmm
Provozieren dich technische Whitepapers und Präsentationen?

Wenn du keine Zusammenhänge in meinen Quellen erkennen kannst, solltest du mehr Grundlagen erlernen. Ich kann sehr gut erkennen wenn ein softwarefokusierter Gesprächspartner Defizite hat zu sehen was hinter seinem Abstraktionslayer passiert.
 
graysson schrieb:
8GB sind imho auch in 2016 noch vollkommen ausreichend. Aktuell ist die höchste Speicherauslastung so um die 6GB bei der Titan mit 12GB.

Das stimmt so nicht, Beispiel shadow of mordor Verbraucht gerne mal mehr, oder Ac Unity. Man es mit GTA 5 sogar geschafft 14GB zu fordern.
 
Den Speicher voll zu pumpen ist das eine, dabei aber durchgehend spielbare fps ist das andere.
 
Zurück
Oben