[Sammelthread] Grafikkarten - Technikdiskussion

Ladies and Gentlemen
HWLUXX proudly presents:

[HWLUXX] =Die Grafikkarten-Technik-Diskussionsrunde= [HWLUXX]
Der ultimative Thread für Leute die nur Shader und ROPs im Kopf haben​

Zum Vergrößern anklicken....

Abt. Regelwerk -Allgemeines-

• In der =Grafikkarten-Diskussionsrunde= ist unbedingt die „Netiquette“ zu wahren! Vergesst bitte niemals, dass auf der anderen Seite ein Mensch sitzt, daher bitten wir euch, von Beleidigungen, Beschimpfungen und/oder herablassendem Verhalten gegenüber anderen Forennutzern abzusehen. Wir greifen niemand persönlich an und beschimpfen niemanden. Aggressive und beleidigende Worte haben bei uns keinen Raum. Bleibt stets fair und seid freundlich zueinander!

• Desweiteren herrschen natürlich auch hier die *allgemeinen Forumsregeln*

Zum Vergrößern anklicken....

Abt. Regelwerk -Spezielles-

• Beiträge, die keinen Zweck erfüllen bzw. nur darauf abzielen, andere Diskussionsteilnehmer zu kompromittieren, zu demotivieren, Zwietracht zu sähen und/oder der Diskussion auf andere Art und Weise abträglich sind, sind zu unterlassen und werden geahndet.

• Diskussionsthemen, die nicht weiter diskutiert werden, so genannte "Null-Postings", wenig sinnergänzende Beiträge, Füllworte und Smilies können ohne Hinweis von uns gelöscht werden. Beiträge, die reine Werbung sind, werden ebenfalls gelöscht.

• Das Zitieren von Beiträgen, die in irgendeiner Form nicht den Forenregeln entsprechen, ist nicht gestattet. Des Weiteren ist beim Zitieren darauf zu achten, dass lediglich relevante Stellen eines Beitrags im Zitat aufgefasst werden sollen - keine Fullqoutes. Artikel oder Namensbeiträge, identisch übernommen von Fremdquellen ohne Angabe der Quelle, können Urheberrechtsverletzungen darstellen. Wir behalten uns vor, solche "Zitate" zu löschen.

• Beiträge mit markenfeindlichem Spam (Nvidia, Ati, Microsoft,...), kommerzieller Natur und/oder reine Werbebeiträge für Dienstleistungen, den Vertrieb unerwünschter E-Mail-Nachrichten, usw sind zu unterlassen.

• Zitate aus urheberrechtlich geschützten Werken (beachtet die gesetzlichen Regelungen).

Zum Vergrößern anklicken....

Der Aufbau einer modernen Grafikkarte



Inhaltsverzeichnis:

• 1. Einleitung
• 2. Grundaufbau
• 3. Hauptaufbau
  • a) Shader -Einheiten
  • b) ALU
  • c) ROP
  • d) TMU
  • e) Füllraten und Bandbreiten
• 4. Aktuelle Architekturen im Detail
  • a) NVIDIA: GT200b-Chip
  • b) AMD: RV790
• 5. Zukunftsausblick

no1
1. Einleitung

Die Entwicklung von Grafikkarten zählt zu den am schnellsten wachsenden Sektoren im Computer-Business und schreitet noch immer sehr zügig voran. Während bei CPUs (Central Processor Unit) das Mooresche Gesetz, was besagt, dass sich die Transistorenanzahl alle 18 Monate verdoppelt, gilt, wird die Anzahl der kleinen Schaltkreise bei GPUs (Graphical Processor Unit) hingegen schon nach sechs Monaten verdoppelt. So besitzt ein aktueller Grafikkarten-Chip mehr als 1,4 Milliarden Transistoren. Ein Prozessor der neusten Generation bringt es hierbei mit rund 750 Millionen nur knapp auf die Hälfte. Doch wofür braucht man diese Rechenpower?
Die Grafikkarte ist neben dem Hauptprozessor, also dem Herzstück eines jeden Computers, eine der wichtigsten Einheitein und für die Berechnung von 2D- und 3D-Grafiken verantwortlich. Diese Funktion ähnelt dabei einem Koordinaten-System, wobei jeder Pixel genau einem Punkt in diesem System entspricht. Mit Einzug der 3D-Grafik mussten die Pixel allerdings nicht nur aufgestellt, sondern auch texturiert werden. Die GPU berechnet neben den gesamten Pixelinformationen also auch deren Farbe.

Zum Vergrößern anklicken....

no2
2. Grundaufbau

Der Grundaufbau einer Grafikkarte gestaltet sich eigentlich ganz simpel:

• Interne Verbindung zum Computer
  Wie eingangs schon kurz erwähnt, zählt der Grafikkarten-Sektor zu den schnellst wachsenden Bereichen im Computer-Business. Daher steigt natürlich auch die Leistung der verschiedenen Karten rapide an. So musste man auch die Schnittstelle zum Computer selbst immer wieder verbessern. Nach einigen Standards, wie ISA, PCI oder AGP, sind wir heute bei PCI-Express-2.0 angekommen. Dieses Interface erlaubt eine maximale Bandbreite von bis zu 500 MB/s pro Lane. Demnach stehen sage und schreibe 8GB/s zur Verfügung. Außerdem dürfen die neusten 3D-Beschleuniger mit 300 Watt nun mehr aus dem Netzteil ziehen - davon kommen rund 75 Watt aus dem Steckplatz.
• Der Speicher
  Der Grafikspeicher fasst heute bis zu 2-GB-Daten und dient zur Speicherung von Informationen, die in der GPU verarbeitet werden sollen. Aktueller Standard ist hierbei GDDR5, welcher eine Weiterentwicklung des DDR-Speichers, der auch als Arbeitsspeicher verwendet wird, darstellt. Hauptunterschied zwischen diesen beiden Speichertypen sind die unterschiedlich hohen Taktraten sowie die verschiedenen Latenzzeiten.
• Der Framebuffer
  Der Framebuffer ist ein Teil des Speichers und enthält eine Kopie des aktuellen Monitorbildes. Der Framebuffer enthält auch die entsprechenden Farbwerte der berechneten Pixel.
• Der Grafikprozessor GPU
  Der Grafikprozessor ist das Herzstück einer jedes Pixelmonsters. Dieser ist eine Art Co-Prozessor zur CPU und ist in den letzten Jahren deutlich komplexer geworden. Er ist zuständig für die Berechnung der Bildausgabe - darauf gehen wir aber später noch ein.
• Bildausgabe-Anschluss
  Der Bildausgabe-Anschluss stellt die Verbindung zwischen Monitor und Grafikkarte her. Für die älteren Analog-Anschlüsse - wie D-SUB - bedarf es auch noch des RAMDACs. Dieser Chip ist zur Umwandlung der digitalen in analoge Bildsignale zuständig. Aktuell ist derzeit DVI bzw. HDMI. Auch der DisplayPort-Anschluss ist immer mehr im Kommen.

no3

Zum Vergrößern anklicken....

3. Der Hauptaufbau
Nun wird es etwas anspruchsvoller:

no3a

a) Die Shader-Einheiten
Während früher die Anzahl der Grafik-Pipelines mitbestimmend war, sind es heute eher die Shadereinheiten. Mit Umstellung auf Unified-Shader, welche mit der NVIDIA GeForce 8800 GTX (G80) Einzug fanden, beseitigte man einen entscheidenden Nachteil: Hatte eine Grafikkarte vormals 48 Pixelshader und acht Vertex-Einheiten, so konnte es vorkommen, dass die Vertex-Piplene voll ausgelastet war, die Pixelshader aber kaum etwas zu tun hatten. Ein derartiger Stau kann mit der neuen Architektur nicht mehr vorkommen.
Ein Unified Shader ist ein Floating-Point-Prozessor, der in der Lage ist, sowohl Vertex-, als auch Pixeloperationen durchzuführen. Auch Geometrieoperationen dürfen dabei nicht fehlen. Für nicht GPU-Operationen lassen sich diese Einheiten aber auch zweckentfremden (Stichwort: GPU-Computing).
Alle Shadereinheiten beschränken sich nun also auf die grundlegenen Rechenoperationen: ADD (Addition), SUB (Subtraktionen), NOT (Negierungen) oder MUL (Multiplikationen) und noch MADD (Kombination aus ADD+MUL). Dabei entscheidet der Grafikkarten-Treiber zu welchem Zeitpunkt er welchen Shader ansprechen möchte. Dadurch steigt in erster Linie natürlich die Granulität (Auslastung).​

Zum Vergrößern anklicken....

no3b

b) ALU
Eine ALU berechnet die verschiedenen Rechenoperationen, die für die Berechnung eines Shaders notwendig sein. Dabei kann eine ALU eine bestimmte Breite haben. Während man bei einer Breite von 1 auch von einer Scalar-ALU spricht, nennt man ALUs mit einer Breite höher als 1 hingegen Vektor X-ALU (X ist eine beliebige Zahl!). Bsp.: Vec4-ALU.
Mit diesen Informationen können wir die maximale aritmethische Rohleistung der Grafikkarten bestimmen. Diese gibt man in FLOPs (floating-point operations) an.
Ein ADD und ein MUL sind je ein FLOP wert; eine MADD zwei FLOPs. Durch die Breite erhöhen sich natürlich auch die FLOPS. So ist eine Vec2-ALU 4 FLOPS und eine Vec3-ALU 6 FLOPS wert.

Nun mal zwei realitätsnahe Beispiele:

• NVIDIA GeForce GTX 285
  Der GT200b besitzt 240 Shadereinheiten, die pro Takt ein MADD+MUL abliefern können. Daraus ergibt sich folgende Rechnung:

240 Shadereinheiten * 3 FLOPS (MADD+1MUL) * 1,476 GHz (Shadertakt) = ~1.063 GFLOPS​

• AMD/ATI HD4890
  Der RV790 hat 160 Unified Shader, welche 5D Shader sind. Diese werden aus Marketinggründen als 800 Streamprozessoren (160*5) vermarktet. Der Shadertakt ist gleich dem Chiptakt; 850 MHz. Die 160 5D-Shader bringen es auf 10FLOPs. Daraus ergibt sich folgende Rechnung:

160 Shadereinheiten * 10FLOPS * 0,850GHz = 1.360GFLOPS​

Zum Vergrößern anklicken....

no3c

c) ROP
ROPs stellen die Verbindung zwischen Speicher und Shadereinheiten her und sind somit das letzte Bindeglied zwischen den beiden Einheiten. Die Rastereinheiten kümmern sich dabei um Kantenglättung.
Heutige Karten haben bis zu 32 ROPs.

Zum Vergrößern anklicken....

no3d
d) TMU
Die TMUs sind ein wichtiger Bestandteil und zuständig für die Texturadressierung und anisotropische Filterung (AF).

Zum Vergrößern anklicken....

no3e
e) Füllrate und Bandbreiten
Natürlich ist aber nicht nur die Anzahl der zur Verfügung stehenden Einheiten ausschlaggebend. So gibt es zahlreiche Leistungsindexe, die auf die Leistung einer Grafikkarte schließen können:

Die Beispiele gelten jeweils für eine NVIDIA GeForce GTX 285!

• Die Pixelfüllrate errechnet sich aus dem Coretakt und den zur Verfügung stehenden ROPs.
  
  
  32 ROPs * 648 MHz = 20.736 MPix/s​
• Die Texelfüllrate errechnet sich aus der Anzahl der TMUs und dem Coretakt.
  
  
  80 TMUs * 648 MHz = 51.840 MTex/s​
• Der Speicherdurchsatz errechnet sich aus Speicheranbindung, dem Channelmodus sowie dem Speichertakt.
  
  
  2 (DualChannel) * 1242 MHz * 512 Bit = 1271808 MBit/s => 158,9 GB/s​

Zum Vergrößern anklicken....

no4
4. Die Architekturen im Detail:

Für die meisten Anwender würde es wohl reichen, die Anzahl der jeweiligen Einheiten auf den Tisch zu legen. Doch wenn man einmal tiefer ins Geschehen einsteigt, dann könnte man vielleicht das ein oder andere Gerücht zu kommenden Grafikkarten-Generationen wiederlegen oder einfach auf einem fachlich hohem Niveau mitdiskutieren.
Alles in allem unterscheiden sich die Architekturen von NVIDIA bzw. AMD, führen aber doch in einer unterschiedlichen Art und Weise zum gleichen Ziel.

Zum Vergrößern anklicken....

no4a

a) NVIDIA GeForce GTX 285
Beginnen wollen wir an dieser Stelle mit NVIDIAs aktuellem GT200b-Chip, welcher sich auf den Karten der GTX-200-Reihe wieder findet. Der Grafikprozessor verfügt dabei insgesamt über 240 skalare Shadereinheiten, 80 TMUs, 32 Rastereinheiten und ein 512 Bit breites Speicherinterface sowie einen 1024 MB großen GDDR3-Videospeicher.

Im Vergleich zum Vorgängerchip, dem G80, erhöhte der Hersteller nicht nur die Anzahl der Cluster, sondern änderte auch die Organisation innerhalb des Chips. Demnach ordnete der kalifornische Grafikkartenhersteller die einzelnen Streamprozessoren so an, dass jeweils 24 zu einer Einheit zusammengefasst sind. Diese Shadercluster sind dann nochmals in drei 8er-ALU-Böcke, die sich wiederrum in zwei vierer Blöcken organisieren, unterteilt.
Insgesamt kommt der GT200b damit auf seine 240 Shadereinheiten, da insgesamt zehn Cluster, die jeweils auf 24 einzelne ALUs zurügreifen können, vorhanden sind (2x4x3x10 = 240). Die zehn Sektionen besitzen dabei jeweils einen schnellen L1-Cache und eine Anbindung über eine Crossbar an den Speichercontroller.

​

Das Verhältnis zwischen den einzelnen ALUs und TMUs legte NVIDIA beim GT200b-Chip auf 3:1 fest. Demnach stehen jedem Shadercluster ein Texturcluster, bestehend aus acht Textureinheiten, zur Seite (10x8 = 80).
Im Vergleich zum G80 erweiterte man die sechs ROP-Partitions auf nun acht. Jede solche Partition besteht aus insgesamt vier einzelnen Rastereinheiten. Insgesamt stehen somit 32 ROPs (8x4) zur Verfügung.
Da die Rastereinheiten auch als letztes Bindeglied zum Speicher gesehen werden können, resultiert aus ihnen auch die Breite des Speicherinterfaces. Jeder ROP-Partition steht ein 64-Bit-Controller bereit. Daraus eribt sich dann auch das 512 Bit breite Speicherinterface (8x64).
Auch die Größe des Speichers ist nicht wahllos gewählt. So verrichten bei der NVIDIA GeForce GTX 285 an jedem 64-Bit-Controller jeweils zwei Speicherbausteine mit einer Kapazität von je 64 MB ihr Dienste. Demnach stehen der schnellsten Single-GPU-Karte satte 1024 MB zur Verfügung. (8x2x64)​

Zum Vergrößern anklicken....

no4b

b) ATI Radeon HD 4890
Die Architektur hat der RV790 von der nicht ganz so leistungsstarken R600-Architektur übernommen. Zuerst sei gesagt, dass die 800 Streamprozessoren ein reiner Marketing-Gag sind, da der Chip über 5D-Shader verfügt. Folglich stehen 160 Unified Shader bereit. Dabei setzt sich deren Anzahl aus zehn SIMD-Blöcken (Single Instruction Multiple Data) zusammen. Jeder Block kommt dabei mit jeweils 16 ALUs sowie einem Texturcluster - samt vier einzelnen Textureinheiten - daher. Dazu gibt es einen 16 KB großen L1-Zwischenspeicher.

​

Die 16 Rastereinheiten sind ebenfalls in vier ROP-Partitions unterteilt.
Bekanntlich besitzt der verbaute GDDR5-Videospeicher der ATI Radeon HD 4890 über ein 256 Bit breites Speicherinterface. Dieses setzt sich aus ingesamt vier 64-Bit-Controllern zusammen, die jeweils zwei Speicherbausteine ansprechen können. Um also auf 256 Bit zu kommen, muss jeder Chip mit 32 Bit angesprochen werden.
​

Zum Vergrößern anklicken....

no5
5. Zukunftsausblick

In Kürze wird mit dem RV870 die nächste Grafikkarten-Generation von AMD eingeläutet. Der G(T)300 wird aktuellen Gerüchten zufolge wohl erst im ersten Quartal 2010 folgen. Große Änderungen in den jeweiligen Architekturen sind allerdings nicht zu erwarten, denn beide Hersteller bringen wohl nur einen Refresh-Chip mit kleineren Verbesserungen auf den Markt. Hierzu zählen für AMD wohl ein dickeres Speicherinterface sowie die fortschrittlichere 40-nm-Fertigung. Es wird dieses Jahr jedenfalls nochmals spannend!

Zum Vergrößern anklicken....

6. Danksagung

Ein großer Dank gebührt unserem Forenmitglied Nakai, der uns mit seinem Thread eine hervorragende Grundlage geschaffen hat.

Zum Vergrößern anklicken....

Ich hoffe der Thread gefällt und hilft an so manchen Stellen ein bisschen weiter!

Gruß

Schöner Thread, vielen Dank.

Dann fang ich gleich mal an und zwar mit dem Thema Multi-GPU-Karten.

Bisher kannten wir ja nur zwei Varianten, zum einem das unterbringen zweier GPUs auf einem PCB mit jeweils eigenem Speicher und Kommunikation über einen Brückenchip bei Ati, oder bei Nvidia die GX2 Karten mit jeweils eigenem PCB welche dann aufeinander gesetzt wurden.

Der R700 soll ja erstmals shared Memory ermöglichen, durch den Wegfall eines Brückenchips und direkte Kommunikation via den Vram.
Wenn man diese Entwicklung berücksichtigt, gehe ich davon aus, dass sich Mittelfristig AFR verabschieden wird und SFR bei Multi-GPU-Lösungen einzug halten wird, oder seht ihr das anders?

vanD schrieb:

Der R700 soll ja erstmals shared Memory ermöglichen, durch den Wegfall eines Brückenchips und direkte Kommunikation via den Vram.
Wenn man diese Entwicklung berücksichtigt, gehe ich davon aus, dass sich Mittelfristig AFR verabschieden wird und SFR bei Multi-GPU-Lösungen einzug halten wird, oder seht ihr das anders?

Zum Vergrößern anklicken....

Warum sollte shared Memory der Auslöser zum Wechsel zu SFR sein?

Ich denke aufgrund der einfacheren Implementierung wird der Schwerpunkt weiterhin auf AFR liegen.

Gruß

Nach meinem Kenntnisstand verhält es sich so, dass der größte Nachteil beim SFR mit Scissor-Mode (ich glaube bei Nvidia nennt man das Load-Balancing) jener ist, dass die Geometrie-Daten zum Ausgleich der Rechenlast pro GPU bis jetzt seperat bereit gestellt werden mussten.

Durch Verständigung über den VRAM sollte es den GPUs doch ohne Umwege möglich sein auf diese Daten parallel zugreifen zu können und somit das Split-Frame-Rendering zu optimieren.

sehe ich genauso, SFR wird dadurch eigentlich erst ermöglicht korrekt mit shadern zu funktionieren.

wenn das allerdings auch kartenübergreifend funktionieren würde wäre es die perfekte technik, stellt euch mal 2 4870x2 mit einer crossfire-verbindung von 300gb/s und insgesamt 4,8tflops vor

fehlt nurnoch ein quadHD monitor ^^

geht doch 4x 30" Dells und das alles auf einer Auflösung geht ja mit CF

Ich bin echt gespannt was ATI sich hat einfallen lassen zum Thema der neuen X2, *verbesserte PCI-Express-Bridge der zweiten Generation und GPU-Interconnect* sind die neuen Schlagworte zu diesem Thema.

Mich würde es interessieren was es mit dem *GPU-Interconnect* auf sich hat?

Klingt, als könne man mit damit mehrere GPUs direkt miteinander verbinden.
Jedenfalls fallen dem Grafikspeicher wohl in Zukunft mehr Aufgaben zu, weshalb ich für eine drastische Erhöhung plädiere!

Le_frog99 schrieb:

Ich bin echt gespannt was ATI sich hat einfallen lassen zum Thema der neuen X2, *verbesserte PCI-Express-Bridge der zweiten Generation und GPU-Interconnect* sind die neuen Schlagworte zu diesem Thema.

Mich würde es interessieren was es mit dem *GPU-Interconnect* auf sich hat?

Zum Vergrößern anklicken....

Naja mit "GPU-Interconnect" hat auch Sapphire sein PureCrossfire-Board beworben, ich denke dass ist einfach ein schöner Anglizismus für "GPU-Verbindung". Andererseits besteht natürlich die Möglichkeit dass es diesmal einen wirklichen Fortschritt beschreibt.

Irgendwo stand doch auch, dass es bei dem R700 keine Mikroruckler mehr geben soll und die Karte sich für das System wie eine Verhält. Wäre das evtl. ein Indiz dafür, dass die Karte wirklich Hardware seitig mit SFR im Scissor-Mode arbeitet und gar keinen anderen Modus mehr beherrscht?
Schließlich verhält es sich doch so, dass bei SFR die geballte Ladung der beiden GPUs auf ein jedes Frame lsogelassen wird und somit keine Verzögerung mehr auftreten kann.

Generell sieht es ja so aus, als ob aus Kostengründen nicht mehr mit den sogenannten Brute-Force-Chips gearbeitet wird und der Trend mehr zum Kosten effizienten Multi-GPU-System geht. SFR wäre doch dann ein wirklicher Fortschritt was die Effiziens eines MGPUs angeht.

Ich will jetzt nicht sagen, dass sich der R700 so verhalten wird, aber so könnte ich mir die nächsten Generationen von Grafikkarten vorstellen.

bei den Shadern bitte noch einfügen was die verschiedenen "Modelle" unterscheidet.

Der Zugriff auf den Speicher wird durch den Shared Memory zwar vereinfacht, aber das Grundproblem des SFR-Algorithmus - ein vernünftiges Load Balancing - löst sich dadurch leider nicht. Nur, weil beide Karten auf alle notwendigen Daten zugreifen können, wissen die beiden GPUs trotzdem noch nicht, welcher Bildteil gerade die intensiveren Berechnungen beansprucht. Die Unterteilung muss dynamisch angepasst werden und das kostet CPU-Zeit, was wiederum die Performance beeinträchtigt. Sollte SFR angepeilt werden, müsste man also als erstes das Load Balancing in Hardware gießen.
Vorteil von SFR ist, wie schon angesprochen, das Fehlen von Mikrorucklern im klassischen Sinne. Hier sehen Mikroruckler einfach anders aus: Ist eine Karte langsamer mit der Berechnung ihres Bildanteils, muss die andere warten, bis beide beginnen können, ein neues Frame zu berechnen. Über Multiple-Buffering-Systeme könnte man hier zwar puffern, aber das Problem löst sich so eigentlich nicht. Dementsprechend bedeutet ungenügendes Load Balancing hier einfach massiv schlechtere Frameraten. Oder Tearing. Beides ist nicht besonders angenehm.
Zum GPU-Interconnect: Da die GPUs nicht über den Speicher "kommunizieren", weil das mit dem Adressing nicht so einfach zu lösen ist, fehlt bei gemeinsamen Speicherzugriff eine enorm schnelle Inter-GPU-Verbindung, um im Falle von Abhängigkeiten zu synchronisieren. Ich nehme an, genau hier setzt ein wie auch immer gearteter, neuartiger GPU-Interconnect an.

Danke dir Lord, sehr schöner Beitrag.

Meinst du wirklich das ATI auf SFR umschwenkt? Ich denke nicht, war da nicht noch was das aktuelle Spielengines ja auch ihre Probleme damit haben dadurch die schlechte skalierung? Welche möglichkeiten hätte ATI mit AFR die MR in den Griff zu bekommen?

Die schlechte Skalierung aktueller Engines resultiert mMn in erster Linie aus zwei Dingen: Dem bisher absolut ungenügenden, schon angesprochenen Load-Balancing-Algorithmus - mir fällt hier zugegebenermaßen auch keine effiziente Methode ein, aber ich bin auch kein GPU-Designer - sowie der Problematik, dass im Bereich der "Teilungskante" keine Skalierung stattfinden kann, falls dort Shader berechnet werden. Für den Fall, dass ein Shader sich über beide Bildhälften erstreckt, muss er zeitaufwändig "Stück für Stück" zusammengerechnet werden, weil es nicht möglich ist, solch eine Berechnung auf zwei unabhängige GPUs aufzuteilen. Das ist ein ähnliches Problem, wie es damals der Ansatz des Scanline Interleaving hatte. Ich könnte mir hier eine Lösung über einen komplexen Tiling-Ansatz vorstellen, der aber aufwändig zu realisieren ist und vermutlich eine vollständig neue Scheduling- und Prediction-Hardware benötigt, um ALU-Stalls zu vermeiden: Man könnte das Bild in entsprechend viele (polygonale - ich nehme an, Quadrate bieten sich an) Tiles aufteilen und diese dynamisch (je nach Rechenlast) an die GPUs verteilen. Das steigert die Synchronisationslast enorm, aber hey - wenn man das Balancing-Problem für SFR gelöst kriegt, dann auch hier.

Zum Thema MR bei AFR hab ich leider auch keine Ahnung. Ich weiß nicht genau, wo die Dinger überhaupt herkommen. Es ist nur meiner Meinung nach keine Lösung, die Framerate zu limitieren, denn damit schieße ich mir ja letztlich ins Knie - M-GPU für mehr Frames und dann muss ich sie limitieren? Ich könnte mir einen gesonderten Framebuffer vorstellen, der die fertigen Bilder von GPU X solange cached, wie GPU Y noch nicht mit ihrem Bild fertig ist. Ein entsprechendes Prerenderlimit gegeben, könnte X so bereits an weiteren Bildern arbeiten. Problem ist hier nur: Immer, wenn das Auftritt, also vmtl. bei jedem zweiten Frame, vergrößert sich der Frame-to-Frame-Abstand zwischen beiden GPUs (also der Positionsunterschied der beiden simultan berechneten Frames im Renderablauf) mehr, was letztlich entweder zu großem Inputlag, riesigen benötigten Caches oder permanent falschen Sprungvorhersagen resultieren würde.

Ich sehe schon, hier kann ich wirklich was lernen.

Lord schrieb:

Sollte SFR angepeilt werden, müsste man also als erstes das Load Balancing in Hardware gießen.

Zum Vergrößern anklicken....

heise.de schrieb:

Für eine höhere Leistung in der Geometrie-Shader-Konfiguration hat AMD die Zahl der gleichzeitig aktiven GS-Thread vervierfacht und die Menge der auf dem Chip speicherbaren Geometrie-Daten erhöht.

Zum Vergrößern anklicken....

Geometrie-Shader können ja Volumendaten generieren. Gäbe es eine Möglichkeit, vorrausgesetzt eben eines wie auch immer gearteten und schnellen GPU-Inteconnect, über die GS das Load-Balancing zu arrangieren?

Falls das totaler Stuss ist, ich bin eben nur Laie

So, ich melde mich auch mal zu Wort.
Während meinem (zugegeben langweiligen) Ferienjob-Tag heute kam mir der Gedanke, warum spricht man die zwei GPUs auf zBsp. einer HD 3870x2 nicht als eine einzige GPU an, also keinen geteilten Speicher sondern einen gemeinsamen Speicher und der Treiber würde mit den zwei GPUs einfach so verfahren als wäre es eine "große" GPU mit der doppelten Anzahl an Funktionseinheiten? Das ist nartürlich nur ein einfacher und schlagartiger Gedanke, vielleicht kann mir aber doch der Eine oder Andere weiterhelfen.

Danke im Vorraus Prydain

Enigma256 schrieb:

bei den Shadern bitte noch einfügen was die verschiedenen "Modelle" unterscheidet.

Zum Vergrößern anklicken....

Was meinst du denn? Sollte kein Thread werden, der die Karten besser vergleicht!

Prydain schrieb:

So, ich melde mich auch mal zu Wort.
Während meinem (zugegeben langweiligen) Ferienjob-Tag heute kam mir der Gedanke, warum spricht man die zwei GPUs auf zBsp. einer HD 3870x2 nicht als eine einzige GPU an, also keinen geteilten Speicher sondern einen gemeinsamen Speicher und der Treiber würde mit den zwei GPUs einfach so verfahren als wäre es eine "große" GPU mit der doppelten Anzahl an Funktionseinheiten? Das ist nartürlich nur ein einfacher und schlagartiger Gedanke, vielleicht kann mir aber doch der Eine oder Andere weiterhelfen.

Danke im Vorraus Prydain

Zum Vergrößern anklicken....

Es ist ziemlich komlizierter, als angenommen. Vor allem AMD holt gerade auf diesem Gebiet neue Erfahrungen und versucht den verfügbaren Speicher der HD4870 X2 auf beide Cores aufzuteilen. Das nächste Problem wird die Auslastung sein. Bis es so gehandelt wird, wie bei CPUs, vergeht sicherlich noch eine Weile. Ich denke aber die Hersteller versuchen weiter den Schritt in den Multi-Core-Bereich bei Grafikkarten zu gehen!

Gruß

Sehr schöne Darstellung. Eines vermisse ich jedoch: Energieffizenz. Sprich Stromverbrauch/Leistung/Hitzeentwicklung. Da hätte man vielleicht etwas schreiben können.

Okay aus aktuellem Anlass würde ich sagen -> Thema *VRam Auslastung* nochmal genauer unter die Lupe zu nehmen.

Würde mich über rege Beteiligung sehr freuen

bitte gleich auf mehr als 8aa gehen da es dort schnuppe ist und kaum auswirkungen hat.(bei ati karten)

Na ich hab mir das ganze so gedacht, ich werd ein paar Spielstände abspeichern in verschiedenen Games, dann dort für das Game die Einstellungen für Auflösung, Details und AA/AF vornehmen, danach Game komplett beenden und neustarten.
Zum schluss den Spielstand laden und nichts mehr bewegen (also keine Maus und Tastatureingabe).
Danach so lange warten bis sich die VRam Verbrauchsanzeige eingependelt hat und nen Screen machen...
Das halt für die verschiedenen Auflösungen und AA/AF Level.

Denke mal so bekommt man nahezu 100% die gleiche Ausgangssituation um den Verbrauch vergleichen zu können. Was meint ihr?

Wedde Games soll ich testen?
Ich hatte vorerst an CoH, Stalker, Gothic 3 und CoD4 gedacht. Crysis ggf. noch, mal schauen ob ich das unter XP zum laufen bekomme...
Kane % Lynch hätt ich noch...
Mass Effect bekomm ich wohl im laufe der Woche mal von nem Kumpel zum antesten.
Assassin's Creed hab ich zur not auch noch irgendwo rumfliegen

jericho,ut3 wären auch ganz gut weil die eh schon die ramfresser sind.

falls du die spiele nicht hast gibts für alle auch die demo und das reicht ja aus dafür

Jo die hab ich leider nicht...
Gut dann zieh ich mir mal die Demos, solange diese nicht in irgendeiner Weise beschnitten wurden (wie glaub damals bei der Crysis Demo, nur 32Bit und DX9 oder sowas) sollten die Ergebnisse auch vergleichbar sein.

So kleines Problem derzeit bei mir ist, das der derzeit aktuelle Rivatuner meine HD4870 nicht erkennt, sprich VRam Messungen sind derzeit noch nicht möglich...
Ich hoffe mal das in den nächsten 4 Wochen da ne lauffähige Version kommt (hab nämlich Urlaub und somit Zeit zu testen)

ATI Tray Tools sollten gehen

Kann man damit die VRam Auslastung anzeigen?
Und wedde Version brauch ich dafür?

Schau in den Fred vom Zocker

http://www.forumdeluxx.de/forum/showthread.php?t=509735&highlight=tray

das ist ja mal richtig praktisch gleich im screen dabei.

Jo aber das Tool funzt doch auch net 100% richtig, bei manchen Games zeigt es auch keinen VRam verbrauch an...
Probier ich morgen im laufe des Tages mal, werd mich jetzt erstmal ein paar Bier widmen, schließlich hab ich Urlaub

So hab das jetzt endlich mal probiert unter Vista64Bit vorerst...
Soweit ich das jetzt analysiert hab, ist das was zocker dort in seinem Screen als VRam Verbrauch ausgibt nur die Systemmomory Anzeige, also das was die Anwendung an Arbeitsspeicher braucht. (Es stimmt nämlich auch mit der Speicherverbrauchsanzeige im Taskmanager überein)

Auf jedenfall ist mit dem Tool in Vista nix zu machen, die zweite Anzeige, welche sich "Freier Videomemory" schimpft, steht bei ner Auflösung von 1680x1050 konstannt bei 500MB... bei 1024x768 sinds dort 506MB.
Die dritte Anzeige, welche sich "Freier Texturspeicher" schimpft, zeigt was von 22xxMB an, also ich denke mal das wird der Grafikspeicher + die Größe an Arbeitsspeicher sein, welche die Grafikkarte mit als Ablageort verwenden kann oder sowas in der Art...
Mal schauen ob mit XP was zu machen ist.

Soweit so gut...
XP scheint dann doch ein wenig kooperationsfreudiger zu sein.
Denn dort funzt die Anzeige des "Freien Grafikspeichers" zumindest erstmal, in wie weit die Werte stimmen, kann ich aber leider nicht sagen.
Des weiteren ist noch anzumerken, das ich nicht weis ob nebenbei noch Daten ausgelagert wurden, gehe aber mal stark davon aus, das das nicht passiert ist.

Hab vorerst mal Gothic 3 und CoD4 getestet.
Bei G3 hab ich aber AA nicht zum laufen gebracht, ich erinner mich dunkel, das das auch nicht ging anfangs, aber dann irgendwann mal mittels Treiber erzwungen werden konnte (hat aber bei mir net geklappt)

Auf jedenfall hier CoD4 640x480, max. Details ohne AA/AF
FVM: 171MB --> 341MB Verbrauch


CoD4 640x480, max. Details + 4xAA inGame
FVM: 170MB --> 342MB Verbrauch


CoD4 640x480, max. Details + 24xAA/16xAF im CCC
FVM: 171MB --> 341MB Verbrauch


CoD4 1680x050, max. Details ohne AA/AF
FVM: 136MB --> 376MB Verbrauch


CoD4 1680x1050, max. Details + 4xAA inGame
FVM: 128MB --> 384MB Verbrauch


CoD4 1680x1050, max. Details + 24xAA/16xAF im CCC
FVM: 136MB --> 376MB Verbrauch (kann ich aber leider nicht im Screen festhalten, beim Screenshot schießen aus mir unerklärlichen Gründen die FPS und die VRam Anzeige nicht mit eingeblendet wird, muss wohl am ATT liegen denk ich)


Gothic 3 800x600, max. Details, HDR+Tiefenunschärfe, 16xAF
FVM: 339MB --> 173MB Verbrauch


Gothic 3 1680x1050, max. Details, HDR+Tiefenunschärfe, 16xAF
FVM: 288MB --> 224MB Verbrauch



Im Beispiel von CoD4 werden bei 640x480 341MB verbraucht, bei 1680x1050 sinds 376MB. Bedeutet ein Verbrauchsanstieg von 10,26% bei 574,22% mehr Pixeln...
Anhand der Screens mit AA sieht man auch das AA nahezu kein Speicher verbraucht.

Anmerkung:
Den einen 1680x1050 Screen mit 24xAA muss ich noch mal machen, da ist irgendwie die Verbrauchsanzeige nich mit drauf. Wird aber gleich nachgereicht...

So und jetzt kommt ihr doch bitte mit den Gegenbeweisen und nicht wieder bloß mit leeren Behauptungen. Weitere Games werden folgen, aber ich denke ich habe meine Schuldigkeit vorerst getan...
Was ich noch komisch finde, bei G3 ist die GPU Aktivitätsanzeige so drastisch niedrig, warum auch immer, bei CoD4 ist die immer bei fast 100%.