[Sammelthread] Grafikkarten - Technikdiskussion

Aber das bringt wieder den Nachteil mitsich, das es dann keine Dual GPU Karte mehr ist sondern ein großer Chip, wenn man so will

Evtl. Es muss ja nicht sein das es eine native MultiGPU wird.

Aber mal zurück zu der Sache mit den Daten. Die Überschneidung sollte trotzdem verdammt groß sein. Die größten Datenmengen wie Texturen würden trotzdem beide Chips nahezu Zeitgleich anfordern. Auch Daten über Geometrie sollten sich nicht allzu arg in einem Framewechsel ändern.

Auch eine Logikeinheit wäre nicht zu kompliziert weil sie die Daten ja wirklich nur Splitten müsste und keinen eigenen "Entscheidungen" treffen muss ob zB Daten für einen Chip verworfen werden müssen usw.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Evtl. Es muss ja nicht sein das es eine native MultiGPU wird.

Aber mal zurück zu der Sache mit den Daten. Die Überschneidung sollte trotzdem verdammt groß sein. Die größten Datenmengen wie Texturen würden trotzdem beide Chips nahezu Zeitgleich anfordern. Auch Daten über Geometrie sollten sich nicht allzu arg in einem Framewechsel ändern.
.

Was machst du denn aber,wenn beide zur selben zeit,auf die nur einmal vorhandenen daten,im gemeinsam genutzten vram zugreifen wollen;)
 
Zuletzt bearbeitet:
Was machst du denn aber,wenn beide zur selben zeit,auf die nur einmal vorhandenen daten,im gemeinsam genutzten vram zugreifen wollen;)

wenn beide zur exakt selben zeit auf die selben Daten zugreifen wollen (was eher unwarscheinlich ist) könnte man die Logik so programmieren, das diese die Daten in dem Fall nur einmal ausließt aus dem Speicher aber an beide GPUs sendet...
Wobei der Fall wirklich extremst selten auftreten sollte...
 
Das Problem ist genau das: Die Daten werden viel öfter leicht zeitversetzt angefordert als exakt im gleichen Moment. Von zwei Quellen gleichzeitig auf denselben Speicherinhalt (dieselbe Speicheradresse, really) zugreifen ist eigentlich kein Problem (von zu kleinen Signalstärken evtl abgesehen), denn die Information, die am Speicherbus anliegt, muss ja nur zu zwei GPUs gesendet werden anstatt zu einer (das ist nur eine Verdrahtungsfrage). Der Zeitversatz würde aber dafür sorgen, dass man - wenn man nicht hochgradig ineffizient zweimal hintereinander dasselbe lesen will - buffern muss. Und das bei größeren Daten ohne Ende, sodass es zu teuer wird, um praktikabel zu sein.
 
Zuletzt bearbeitet:
Im prinzip müssten die GPUs noch zusätzlich einen cache zur seite gestellt bekommen in dem fall,das wolltest du doch sagen damit oder?

---------- Beitrag hinzugefügt um 13:29 ---------- Vorheriger Beitrag war um 13:01 ----------

@Scully: Das klärt aber immer noch nicht die frage, wie eine von diesen 32Bit-Multiplikationen in einem Takt realisiert werden soll - was ja fast offensichtlich der Fall ist.

Sind wir nicht von 64bit (double precision)ausgegangen?

Ich finde leider diesen anderen beitrag nicht mehr,wo über die effizienz beim g200 u SIMD geredet wurde,dort war einer der auffassung das die berechnung mehrere durchläufe(taktzyklen) benötigt dafür.

Ich denke das nvidia gerade deswegen MIMD einsetzt bei dem neuen chip.

Edit

Hab deinen beitrag oben falsch gedeutet:fresse:

Dort war ja von 32bit länge die rede u nicht 64bit:wall:

Könnte eventuell "shared memory" des rätzels lösung sein für das 64bit speicherproblem was du in dem zusammenhang angesprochen hast:confused:

Denn wenn jeder wert einzeln behandelt wird sind wir doch nicht bei 64bit;)

unbenanntcv6a.png



Das ist auch recht aufschlussreich;)
http://www.ddj.com/hpc-high-performance-computing/208801731

unbenanntn56h.png
 
Zuletzt bearbeitet:
Im prinzip müssten die GPUs noch zusätzlich einen cache zur seite gestellt bekommen in dem fall,das wolltest du doch sagen damit oder?

Ein Cache ist ja ein Pufferspeicher ( -> Buffer). Ergo: Ja, das wäre nötig. Allerdings nicht "die GPU", sondern in erster Linie die Logik, die genutzt wird, um aus dem Speicher zu lesen. Oder ein asynchroner Bus, aber das wirft das ganze Design über den Haufen, schließlich benutzt sowas niemand.

Was meine Multiplikationsprobleme angeht, es ist völlig egal, welche Länge da die beiden Faktoren haben. Die Multiplikation dauert (naja, bei jeder Länge > 1 :fresse: ) immer mehr als einen Taktzyklus. Und das kommt mir spanisch vor. Es ist also eine algorithmische Frage, die mich eigentlich beschäftigt.
 
Ich sag aber mal so, ich gehe stark davon aus, das läuft analog zum PCIe 1.x zu 2.0 Umstieg, denn dort wurde die Datenrate Pro Lane und Richtung ja ebenfalls bei gleichem Takt verdoppelt.

Ja moment mal ist es nicht so das die taktfrequenz des pcie slots zwischen 1.x u 2.0 auch verdoppelt wurde um die höheren transferraten zu erreichen:wink:

Oder bin ich jetzt auf dem holzweg:confused:
 
Hmm, stimmt. PCIe konnte man ja im Bios von Standard 100 MHz verstellen...hmm, jetzt bin ich auch überfragt.
 
PCI läuft wie Lord schon sagte idR mit 33,33MHz in der normalen 32Bit Version.
Ein 64Bit PCI Slot läuft mit 66MHz
Und PCI-X gibts in ner 100MHz und ner 133MHz Version.

AGP rennt mit 66MHz
Und PCIe (1.x und 2.0) läuft mit 100MHz...


Das was die dort schreiben auf der Seite weis ich net genau, klingt für mich so, als würden die da was verwechseln, weil im Fließtext steht was von 2,5GBit/sec und unten in der Tabelle steht was von 2,5GHz...!?
Oder gibts da noch irgendwie nen anderen Takt unter der Decke, von welchem der User nix mitbekommt?
Keine Ahnung, Lord, weist du was darüber???
 
Ich bin auch der Meinung das PCIe wesentlich höher Taktet, also in den Regionen wie von Scully beschrieben....

Haha, Lord, wir brauchen dich;)
 
Neja was heist der Meinung...schau lieber auf Fakten ;)
Der PCIe Bus (gut ist ja gar kein Bus aber egal) taktet mit 100MHz wie oben schon mehrfach gesagt. Und das ist Fakt und daran lässt sich nicht rütteln.

Das was die dort mit diesen hohen Taktfrequenzen angegeben haben, ist was anderes, hat aber mit dem Takt der Schnittstelle nix zu tun.
 
Ich hab hier irgendwo ne PCGH Ausgabe wo auf PCIe 3.0 eingegangen wurde und das alles auch gut erklärt wurde mit den Daten. Aber wie das immer so ist finde ich sie gerade jetzt natürlich nicht.
 
Moep Moep :wink:

PCIe ist vollduplexfähig und arbeitet mit einer Taktrate von 1,25 GHz. Daraus berechnet sich die Datenrate einer Lane (nach 8B10B-Kodierung) zu maximal 125 MByte/s pro Richtung (zum Vergleich: der Standard-PCI-Bus mit 32 Bit Busbreite bei 33 MHz erreicht nur maximal 133 MByte/s). In der Praxis erreicht man Raten von über 240 MByte/s bei langen Datentransfers. Verwendet man nur eine Lane, spricht man von PCIe x1. Durch Koppelung mehrerer Lanes kann man die Datenrate erhöhen, etwa x4 mit vier Lanes bis zu x32 mit 32 Lanes. Inzwischen existiert die Version 2.0 der PCIe-Spezifikation mit einer Datenrate von 500 MByte/s pro Lane. Die PCI-SIG plant darüber hinaus zukünftig auch eine Version mit 1000 MByte/s pro Lane.
 
Das kling schon stimmiger. Dann sollte PCIe 3.0 wohl auf 2,5 GHz laufen, oder wurde dieser Schritt schon mit PCIe 2.0 getan?
 
Das kling schon stimmiger. Dann sollte PCIe 3.0 wohl auf 2,5 GHz laufen, oder wurde dieser Schritt schon mit PCIe 2.0 getan?

Ja wurde er, aber das Problem ist doch, wo liegt diese Taktrate an?
nicht an der Schnittstelle, denn diese Taktet mit 100MHz... (was man mit jedem halbwegs tauglichen OC Board selbst nachprüfen und sogar verstellen kann)

Ums mal genauer zu sagen, man könnte quasi die Bandbreite des PCIe 2.0 Slots mit nem 1.x Slot simulieren, wenn man den 1.x Slot auf 200MHz übertakten würde... (was natürlich idR nicht machbar ist, aber theoretisch möglich)
Sprich die Basistaktrate bleiben wohl nach wie vor die 100MHz... und diese ominösen 1,25GHz bzw. 2,5GHz bei 2.0 hängen da irgendwie direkt dran, oder wie auch immer. Und genau das gilt es hier wohl rauszubekommen...

Bei PCI zum Beispiel taktet der Bus mit 33MHz genau so wie der Slot wohl!? Da gibts also nix, was irgendwie intern deutlich höher Taktet, oder steh ich grad aufm Schlauch!?
 
Das kling schon stimmiger. Dann sollte PCIe 3.0 wohl auf 2,5 GHz laufen, oder wurde dieser Schritt schon mit PCIe 2.0 getan?

Pcie 3.0 taktet mit 4ghz da der overhead von 2bits(nötig für die syncronisation) dort aber wegfallen soll,ist er mit 4ghz trotzdem doppelt so schnell wie 2.0 mit 2,5ghz
 
Zuletzt bearbeitet:
Der PCIe Bus (gut ist ja gar kein Bus aber egal)

So? Was soll es denn sonst sein? :hmm:

Ich darf gestehen, dass ich auch keine Ahnung habe, wo die 1,25GHz Takt herkommen. Meinem Kenntnisstand nach sind die 100 MHz, die man im BIOS sehen kann, ein vom Basisoszillator des MBs errechneter Referenztakt, der an das Interface angelegt wird. Wieviel vom Signal man da abgreift, muss (und das ist ja scheinbar auch so) nach außen nicht ersichtlich sein, aber genaueres kann ich dazu auch nicht sagen. Ich frag am Freitag mal nach.
 
Zuletzt bearbeitet:
Es ist wirklich kein Bus mehr. Wenn ich die PCGH Ausgabe doch blos finden würde ;(
 
Das würde ich zu gerne begründen, aber mir jetzt aus dem Gedächtniss Sachen aus dem Wissensartikel hier hinzuschreiben oder einfach auf wiki oder andere Sachen zu verlinken find ich zu unpräzise.
 
Haha, hab gerade die PCGH gefunden, mom^^

So:

PCIe unterscheidet sich im Aufbau erheblich vom alten PCI-Bus. Während PCI die parallele Datenübertragung benutzt setzt PCIe woe viele neuere Protokolle auf eine serielle Datenübertragung. Zudem ist die Hierarchie eine völlig andere. PCI war ein Bus, an dem zahlreiche PCI-Slots oder Onboard-Komponenten angeschlossen waren, die sich die zur verfügungstehende Bandbreite teilen mussten. Wollten mehrere Geräte gleichzeitig auf den PCI Bus zugreifen, musste ein Bus-Arbiter entscheiden, wer zugreifen darf. Ein vorgeschriebenes Verfahren gab es nicht, weswegen einige Hersteller auf ein simples Zeitscheibenverfahren zurückgriffen, andere auf komplexe Methoden mit Priorisierungs- und Parking Funktion.

PCIe dagegen ist kein Bus mehr, sondern eine bzw. mehrere Punkt zu Punkt Verbindungen, die über einen Switch skalierbar sind, ähnlich wie bei einem LAN. Aufgrund der des seriellen Aufbaus kann PCIe auf deutlich höhere Grundfrequenzen zurückgreifen. Während beim klassischem PCI Bus bei 33 MHz und 32 Bit Busbreite das Ende der fahnenstange erreicht war (PCI-X 133 MHz bei 64Bit) arbeitet PCIe mit einer Grundfrequenz von 1,25 GHz.

So, Specs:

PCIe 1.x: 1,25 GHz , 2,5 GT/s, 20% Overhead, 250 MB/s Datenrate
PCIe 2.0: 2,5 GHz , 5 GT/s, 20% Overhead, 500 MB/s Datenrate
PCIe 3.0: 4 GHz , 2,5 GT/s, 0% Overhead, 1000 MB/s Datenrate

Jeweils je Lane.
 
Zuletzt bearbeitet:
Ich darf gestehen, dass ich auch keine Ahnung habe, wo die 1,25GHz Takt herkommen

Es ist bei dem takt von 1,25ghz immer von der Grundfrequenz die rede,also hat diese wohl nichts mit dem slot selber zu tun

Edit

Jepp bei dem link den froggi gepostet hat steht es auch nochmal gesondert

unbenannt6bxk.png
 
Zuletzt bearbeitet:
Es ist bei dem takt von 1,25ghz immer von der Grundfrequenz die rede,also hat diese wohl nichts mit dem slot selber zu tun

Neja so kann man das nicht sagen, sonst würde beim erhöhen der PCIe Slot Frequenz die Bandbreite nicht steigen, sprich das ganze muss in irgend einer Forum voneinander abhängen.
Bzw. die Durchsatzrate pro Lane und Richtung muss in irgendeiner Weise von der Slotfrequenz abhängen...

Der nächste Punkt ist, das man ja ne PCIe 2.0 Karte in einem Slot und ne 1.x Karte in nem anderen Slot betreiben kann, was unabhängig voneinander Funktioniert, sprich diese 1,25GHz bzw. 2,5GHz müssen sich irgendwie immer nur auf einen Teil der Lanes (oder besser einen Bereich) beziehen.

So wie ich das vorhin rausgelesen hab, wird beim einstecken einer 1.xer Karte in nen 2.0er Slot diese Frequenz auf 1,25GHz gedrosselt um die Kompatibilität zur 1.xer Generation zu gewährleisten und die Bandbreite bereit zu stellen.
Die Slotfrequenz von 100MHz hingegen bleibt nach wie vor identisch...

Wenn man so will (und das ist jetzt Spekulation meinerseits) müssten also die 100MHz die Basistaktfrequenz sein, und bei 1.x ready Slots kommt es via Multi zu nem internen Takt von 1,25GHz, bei nem 2.0 Slot hingegen ebenso viel Teiler zu nem Takt von 2,5GHz (welcher aber beim Betreiben von ner alten Karte im neuen Slot ebenso auf 12,5 gesenkt wird)


Was ich nur nicht verstehe, wo liegt dieser Takt an? Der kann ja dann nur über bestimmte Lanes anliegen...!?
Denn die 100MHz Slotfrequenz liegen ja über alle PCIe Geräte an, sowohl Slots als auch interne Verbindungen für NICs oder HDD Controller Onboard.



@Lord
ja eigentlich ist es kein Bus wie Neurosphere schon zitierte, sondern ne Punkt zu Punkt Verbindung. Wenn man so will kann man aber via PCIe Switches eine Art Bus damit bauen, beispielsweise diese NF200 Chips, welche aus 1x 16 Anbindung 2x 16er Slots für GPUs bereit stellen wie auf dem Skulltrail Intel Board zum Beispiel.
In dem Fall wäre das wohl wie eine Art Bus, nicht oder?
 
Zuletzt bearbeitet:
Wenn man so will (und das ist jetzt Spekulation meinerseits) müssten also die 100MHz die Basistaktfrequenz sein, und bei 1.x ready Slots kommt es via Multi zu nem internen Takt von 1,25GHz, bei nem 2.0 Slot hingegen ebenso viel Teiler zu nem Takt von 2,5GHz (welcher aber beim Betreiben von ner alten Karte im neuen Slot ebenso auf 12,5 gesenkt wird)
Das klingt sogar schlüssig,nur leider geht das aus keinen der dokumente so hervor:wink:

Bei Pcie 3.0 müsste der teiler demzufolge aber modifiziert werden,da er nicht mit dem verdoppelten takt von 5ghz arbeitet sondern nur mit 4ghz.

Die frage ist,ist das auch real so die vorgehensweisse:confused:
 
Zuletzt bearbeitet:
Ich bezweifel mal ganz stark das die 100MHz mit einem Multiplikator auf 1,25 GHz gebracht werden, da muss es nen anderen zusammenhang geben. Die 1,25 GHz sind bereits der Grundtakt.

Das muss was anderes sein und evtl nichts mit der PCIe Anbindung zu tun haben sondern aus irgendeinem Grund mit dem Slot.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh