fanatiXalpha
Fleet Admiral
- Registriert
- Aug. 2011
- Beiträge
- 13.672
du hast beides mal den Link für die Petition eingesetzt
bitte korrigieren
bitte korrigieren
Folge dem Video um zu sehen, wie unsere Website als Web-App auf dem Startbildschirm installiert werden kann.
Anmerkung: Diese Funktion ist in einigen Browsern möglicherweise nicht verfügbar.
poi schrieb:Also die angegebenen "bis zu 224GB/s" sind nicht einmal theoretisch möglich,
kisser schrieb:Ist nicht so ganz richtig, was 3DCenter da schreibt. Die 970 kann (sofern es erforderlich/machbar und im Treiber umgesetzt ist) gleichzeitig 196GB/s lesen und 28GB/s schreiben bzw. umgekehrt. Es wird aber wohl in der Praxis nur wenige Fälle geben, wo das auch wirklich nutzbar ist.
Denn dazu müsste ja zu einer Schreibanforderung auf das 3,5GB-Segment zeitgleich eine Leseanfordeung auf die Daten im 0,5GB Segment vorliegen (bzw. umgekehrt).
Banger schrieb:Beim Drüberscrollen habe ich gesehen, dass hier jemand auf der miesen Onboardgrafik des Prozessors zocken muss, weil die GTX970 retour geht.
Wie das technisch gehen soll auf den 512 MB zu schreiben, während gleichzeitig im selbe L2 Cache der gemeinsamen Anbindungen des siebten Ports völlig andere Daten gelesen werden aus den 3,5 GB, ist nirgendwo erwähnt - wie auch. Ein Datenport kann das eben nicht gleichzeitig.kisser schrieb:Doch, das sind sie, aber nicht gleicher Speicheroperation (lesen/schreiben) auf beiden Segmenten.
Es ist aber möglich, das 3,5GB Segment zu beschreiben und gleichzeitig aus dem 0,5GB Segment zu lesen und umgekehrt.
Muss ichs jetzt noch zitieren damit du es begreifst? Ich beziehe mich auf den Anandtech Artikel.RIPchen schrieb:Es ist nicht so ganz richtig, was DU da schreibst. Die 970 kann keine 224GB/s erreichen, ließ den Artikel auf Anandtech über die XOR-Situation beim Zugriff der Speichercontroller 7 und 8.
Despite all of this, achieving peak memory bandwidth performance on the GTX 970 is still possible, but it requires much more effort since simple striping will not do the trick. The easiest and most effective solution in this regard is to interleave reads and writes over the segments, such that one segment is writing while another segment is reading. Interleaving in this fashion allows both segments to work at once – avoiding the blocking effect of the shared read and write buses – and makes it more likely that both segments are doing useful work rather than waiting for their turn on an operation.
Jetzt mal ohne Witz. Anand schreibt in deinem Link:kisser schrieb:Muss ichs jetzt noch zitieren damit du es begreifst? Ich beziehe mich auf den Anandtech Artikel.
DU hast ihn wohl offenbar nicht gelesen!!
Quelle:
http://www.anandtech.com/show/8935/...cting-the-specs-exploring-memory-allocation/2
Du kannst nicht sagen ein Auto fährt 300 kmh wenn 250 vorwärts und 50 kmh rückwärts gehen.GTX 970 can read the 3.5GB segment at 196GB/sec (7GHz * 7 ports * 32-bits), or it can read the 512MB segment at 28GB/sec, but it cannot read from both at once; it is a true XOR situation. The same is also true for writes, as only one segment can be written to at a time.
Unfortunately what this means is that accessing the weaker 512MB segment blocks access to the stronger 3.5GB segment if both memory operations are identical; or put another way, using the 512MB segment can harm the performance of the 3.5GB segment. For example, if we want to issue reads to both segments at once, reading the 512MB segment blocks any other reads to the 3.5GB segment for that cycle. If the 3.5GB segment is blocked in this fashion and doesn't have a non-blocking write to work on instead, it would have to go idle for that cycle, which would reduce the effective memory bandwidth of the 3.5GB segment. This means that taken over time in our example, the larger the percentage of the time the crossbar is reading the 512MB segment, the lower the effective read memory bandwidth would be from the 3.5GB segment.