[Sammelthread] Grafikkarten - Technikdiskussion
- Ersteller Stegan
- Erstellt am
Neurosphere
Enthusiast
- Mitglied seit
- 06.11.2008
- Beiträge
- 4.324
Boby, mach nen Thread oder such. Aber das jetzt auf einmal alle ihre Probleme hier reinschreiben wollen ist irgendwie nervig.
@Lord, gut gemacht
@Lord, gut gemacht
Boby_fan schrieb:
Was an "du bist hier nicht im richtigen Thread" hast du nicht verstanden? Also wirklich.
Ich werde weitere Posts von dir hier kommentarlos löschen.
Neurosphere
Enthusiast
- Mitglied seit
- 06.11.2008
- Beiträge
- 4.324
Mal wieder zu was anderem. SLI und Crossfire haben ja mehrere Probleme wie die bekannten Microruckler. Allerdings habe ich auch davon gelesen das es zu einem verstärkten Imputlag kommen soll. Genaue Informationen dazu habe ich leider nicht gefunden und ohne ein Multigpu-System fällt mir das Nachprüfen schwer.
Die Frage ist aber zum einen wie diese Lags entstehen und zum anderen ob sie sich zum Inputlag eines TFT-Bildschirms addieren (was wohl zutrift da das Signal ja mit einem Lag erst eintrifft), was wohl wirklich störende folgen haben sollte.
Die Frage ist aber zum einen wie diese Lags entstehen und zum anderen ob sie sich zum Inputlag eines TFT-Bildschirms addieren (was wohl zutrift da das Signal ja mit einem Lag erst eintrifft), was wohl wirklich störende folgen haben sollte.
Neja ich sag mal so, ich hab die X2 vor kurzem getestet und ich habe keine störenswerten Verzögerungen oder ähnliches festgestetllt, dabei muss ich aber zugeben, das ich kein Hardcore CS oder Quaker bin, bei dem Reaktion über alles geht...
Im normalen Gaminggebrauch merkt man davon denke ich mal recht wenig...
Aber das Inputlag sollte mit steigender Anzahl der GPUs größer werden, einfach aus dem Grund, weil die GPUs die Bilder im Vorraus berechnen und somit die Eingabe erst später zum Tragen kommt...
Hier zeigt sich wieder der Nachteil von AFR, wie schon bei den MR auch, SFR oder ähnliche Modi, wo alle GPUs am selben Bild arbeiten würden hier abhilfe schaffen...
Im normalen Gaminggebrauch merkt man davon denke ich mal recht wenig...
Aber das Inputlag sollte mit steigender Anzahl der GPUs größer werden, einfach aus dem Grund, weil die GPUs die Bilder im Vorraus berechnen und somit die Eingabe erst später zum Tragen kommt...
Hier zeigt sich wieder der Nachteil von AFR, wie schon bei den MR auch, SFR oder ähnliche Modi, wo alle GPUs am selben Bild arbeiten würden hier abhilfe schaffen...
Naja, ist einermaßen logisch, woher der Inputlag kommt. Eine von beiden GPUs errechnet aufgrund der aktuellen Daten das aktuelle Bild, wobei die andere GPU zu diesem Zeitpunkt schon das darauffolgende Bild berechnen muss - zu dem natürlich aber noch keine neugeschriebenen Eingabedaten, Engineberechnungen etc. zur Verfügung stehen. Ergo kriegt der Nutzer ein Bild mit "veraltenen" Daten oder, umgedreht, seine Eingaben erst nach doppelt so vielen Bildern zu sehen (normalerweise beim nächsten Bild, jetzt erst beim übernächsten, bei 4-fach CFX dann zum Beispiel erst nach 4 Bildern...).
- Mitglied seit
- 21.09.2006
- Beiträge
- 2.402
Ich wusste einfach nicht wo ich das reinposten soll und einen neuen Thread wollte ich dafür nicht offnen. Hier ein sehr interessanter Artikel über den aktuellen Preiskampf zwischen AMD und Nvidia im Mid-Range Segment:
http://www.techradar.com/news/compu...-really-need-a-high-end-graphics-card--616712
http://www.techradar.com/news/compu...-really-need-a-high-end-graphics-card--616712
scully1234
Banned
Ja wunderbar das mysterium ist nun also ausführlich u endgültig gelösst
Hoffentlich genehmigt das pcie konsortium auch das hier ihre geheimnisse gelüftet werden
Ich sehe schon die copyrightsklagen einflattern
Sorry war lange nicht mehr on zuviel arbeiterei imo
Zuletzt bearbeitet:
scully1234
Banned
Moderation: Ab hier verschobene Beiträge aus dem GT300-Spekuthread
Cache in GPUs? Wo denn?
Controller ist in diesem Fall ohnehin ein mehr oder weniger schwammiger Begriff, weil das, was man in GPUs als Memory Controller bezeichnet, längst nicht dasselbe ist wie das, was man in CPUs als Memory Controller bezeichnet (was eigentlich die korrekte Bezeichnung ist). Jedenfalls: Nein, das würde nicht gehen, weil aktuelle GPUs nicht darauf ausgelegt sind, so zu funktionieren. Aber: Ja, theoretisch würde es natürlich gehen. Es ist "nicht schwer" (relativ gesehen), eine Architektur zu entwickeln, die ein breites Interface an wenige Chips anschließt. Die müssten dann allerdings bestimmte Anforderungen erfüllen (niedrige Latenz, Kohärenz, Lastfaktoren...).
Was die Diskussion mit der Auslastung der ALUs trotz geringen SIs angeht, hast du mich (im Gegensatz zu PCZeus :P ) ganz richtig verstanden. Laufzeitkomplexität != Speicherkomplexität - ich kann mit sehr geringen Datenmengen auch extrem komplexe Algorithmen zaubern, an denen sich klassische ALUs dumm und dämlich rechnen. Insbesondere bei Dingen, die solche vergleichsweise einfachen ALUs wie die in den GPUs nicht nativ beherrschen, sondern die per Mikroprogrammierung implementiert sind (per PLA-Steuertabelle oder dedizierter Logik zum Beispiel, wobei ich bei GPUs letzteres annehme, zugunsten der Geschwindigkeit).
Cache in GPUs? Wo denn?
fdsonne schrieb:
Controller ist in diesem Fall ohnehin ein mehr oder weniger schwammiger Begriff, weil das, was man in GPUs als Memory Controller bezeichnet, längst nicht dasselbe ist wie das, was man in CPUs als Memory Controller bezeichnet (was eigentlich die korrekte Bezeichnung ist). Jedenfalls: Nein, das würde nicht gehen, weil aktuelle GPUs nicht darauf ausgelegt sind, so zu funktionieren. Aber: Ja, theoretisch würde es natürlich gehen. Es ist "nicht schwer" (relativ gesehen), eine Architektur zu entwickeln, die ein breites Interface an wenige Chips anschließt. Die müssten dann allerdings bestimmte Anforderungen erfüllen (niedrige Latenz, Kohärenz, Lastfaktoren...).
Was die Diskussion mit der Auslastung der ALUs trotz geringen SIs angeht, hast du mich (im Gegensatz zu PCZeus :P ) ganz richtig verstanden. Laufzeitkomplexität != Speicherkomplexität - ich kann mit sehr geringen Datenmengen auch extrem komplexe Algorithmen zaubern, an denen sich klassische ALUs dumm und dämlich rechnen. Insbesondere bei Dingen, die solche vergleichsweise einfachen ALUs wie die in den GPUs nicht nativ beherrschen, sondern die per Mikroprogrammierung implementiert sind (per PLA-Steuertabelle oder dedizierter Logik zum Beispiel, wobei ich bei GPUs letzteres annehme, zugunsten der Geschwindigkeit).
Zuletzt bearbeitet:
Neurosphere
Enthusiast
- Mitglied seit
- 06.11.2008
- Beiträge
- 4.324
Ich meine auch das Cache in den GPUs vorhanden ist.
Eine ähnliche Idee mit "Riesencache", realisiert durch Speicher direkt in den GPUs hatten zumindest mal die BitBoys:
http://alt.3dcenter.org/artikel/glaze3d_avalanche/index6.php
Edit:
Hier auch mal was dazu:
"SIMD steht für „Single Instruction, Mulitple Data“ – ein SIMD-Core kann also in einem Takt die gleiche Rechenoperation auf viele Daten gleichzeitig ausführen, allerdings keine unterschiedlichen Aufgaben. Jeder SIMD-Core besitzt einen 16 KByte großer lokalen Speicher für den schnellen Datenaustausch zwischen den Stream-Prozessoren. Zu jedem Core gehören zudem ein Textur-Cluster mit vier Textur-Prozessoren, ein Decompressor, eine Adresseinheit, ein Sampler und eine Filtereinheit sowie eine L1-Textur-Cache für die Zwischenspeicherung von Texturen. Über einen ebenfalls 16 KByte messenden globalen Cache kommunizieren die Cores über den Data Request Bus miteinander.
Zusätzlich stecken im Chip vier L2-Cache-Blöcke, die direkt mit dem Hauptspeicher verbunden sind und über die Crossbar mit den SIMDCores Daten austauschen. Die von der Setup Engine aufbereiteten Datenströme – entweder zu einem Vertex-, Pixel- oder Geometry-Programm – verteilt der Ultra-Threaded Dispatch Processor (UTDP) und sorgt für die optimale Auslastung der Rechenwerke."
Chip über den RV770
Zuletzt bearbeitet:
Ja, das ist korrekt. 
Ist halt nur nicht dasselbe wie der klassische Cache im Stil einer Harvard-Architektur (L1, Instr. und Data getrennt), sowohl in Aufbau als auch Funktion. Ist auch nicht ganz so nötig wie bei CPUs, weil der Zugriff auf den VRAM schneller ist als der auf den RAM. Und man ist natürlich anders als bei CPUs daran interessiert, das ganze möglichst kompakt ( => klein) zu halten, weil Cache Unmengen an Transistoren frisst und in GPUs, wie schon gesagt, nicht so nötig ist (insbesondere bei klassischer Grafikberechnung nicht, soweit ich weiß, bei GPGPU schon eher - drum hatten das die älteren GPUs auch alle nicht).
edit: Mich würde an dieser Stelle eigentlich mal interessieren, wie Takt und Assoziativität bei den GPU-Caches geregelt sind.
Ist halt nur nicht dasselbe wie der klassische Cache im Stil einer Harvard-Architektur (L1, Instr. und Data getrennt), sowohl in Aufbau als auch Funktion. Ist auch nicht ganz so nötig wie bei CPUs, weil der Zugriff auf den VRAM schneller ist als der auf den RAM. Und man ist natürlich anders als bei CPUs daran interessiert, das ganze möglichst kompakt ( => klein) zu halten, weil Cache Unmengen an Transistoren frisst und in GPUs, wie schon gesagt, nicht so nötig ist (insbesondere bei klassischer Grafikberechnung nicht, soweit ich weiß, bei GPGPU schon eher - drum hatten das die älteren GPUs auch alle nicht).edit: Mich würde an dieser Stelle eigentlich mal interessieren, wie Takt und Assoziativität bei den GPU-Caches geregelt sind.
Zuletzt bearbeitet:
@Lord: zum Beispiel Texture Cache
Texture Cache in einer GPU wird dazu benutzt um Bandbreite zu sparen; bei einer CPU senkt es die Latenzen. Dieser Cache in der GPU kann kein out-of-order requests durchführen oder die Latenzen verbessern. Beim GT200 ist der L1 z.B. im TPC vorhanden (24kB groß; in 3x8kB eingeteilt). Der L2 Texturecache wiederum sitzt im Memory Controller, jeder davon 32kB groß...
Texture Cache in einer GPU wird dazu benutzt um Bandbreite zu sparen; bei einer CPU senkt es die Latenzen. Dieser Cache in der GPU kann kein out-of-order requests durchführen oder die Latenzen verbessern. Beim GT200 ist der L1 z.B. im TPC vorhanden (24kB groß; in 3x8kB eingeteilt). Der L2 Texturecache wiederum sitzt im Memory Controller, jeder davon 32kB groß...
Zuletzt bearbeitet:
Siehe letzter Beitrag. Aber wie Cache Out-Of-Order-Requests durchführen soll, musst du mir nochmal erklären. Und das, was du mit "wird dazu benutzt, um Bandbreite zu sparen" meinst, ist auch das, warum ich erst so scheinheilig gefragt habe "Cache? Wo?" - weil der Cache hier viel eher die Funktionen von Registern erfüllt als von Cache. Der Assemblercoder weiß, was ich meine.
Aber wie Cache Out-Of-Order-Requests durchführen soll, musst du mir nochmal erklären. Und das, was du mit "wird dazu benutzt, um Bandbreite zu sparen" meinst, ist auch das, warum ich erst so scheinheilig gefragt habe "Cache? Wo?" - weil der Cache hier viel eher die Funktionen von Registern erfüllt als von Cache. Der Assemblercoder weiß, was ich meine.
Zuletzt bearbeitet:
Ja, das ist korrekt.
edit: Mich würde an dieser Stelle eigentlich mal interessieren, wie Takt und Assoziativität bei den GPU-Caches geregelt sind.
Ich denke mal viele Leute beziehen viel zu viele Sachen von CPUs einfach 1:1 auf GPUs (aus Unwissenheit)
Was ich mit Cache oben meinte, war einfach nur ein Zwischenspeicher, in welcher Form auch immer, spielt ja auch keine Rolle, an CPU parallelen hab ich dabei gar nicht gedacht.
Gleichsam die Problematik mit dem aufkommenden Dualcore-Vorderungen im GPU Bereich, nur weil das CPUs nun bieten...
Und ja, CB schreibt zum Beispiel auch, das diese Caches eher im GPGPU Bereich Sinn machen
Zum letzten, ich denke mal das werden wir wohl nicht rausbekommen, derartige Infos sind denke ich nur extrem schwer zu bekommen und wenn dann nur bei AMD oder NV direkt...
Das hätte ich früher wahrscheinlich nicht anders gemacht, ich hab mich nur studienbedingt in letzter Zeit etwas detaillierter mit Mikroprozessordesign (für RISC-Kerne) auseinandergesetzt und da verschiebt sich die Perspektive (glücklicherweise).
Und ja, du hast schon Recht, dass man sowas schwer herausbekommt, aber wohlplatzierte Vermutungen haben noch niemandem geschadet. Wilde Spekulationen sind aber keine wohlplatzierten Vermutungen.
Und ja, du hast schon Recht, dass man sowas schwer herausbekommt, aber wohlplatzierte Vermutungen haben noch niemandem geschadet.
Wilde Spekulationen sind aber keine wohlplatzierten Vermutungen.
Siehe letzter Beitrag.
Register hin oder her, der Cache heißt nicht umsonst so
Ich kann mal versuchen mich hinzusetzten und etwas in Bezug auf den out-of-order request zu schreiben; kann alles ein bisschen dauern, da ich vermeiden will, dass wir aneinander vorbei reden.
@Lord: in Bezug auf den Texturecache: wenn dort Infos bzgl. der Texels zwischengelagert werden, bevor sie in den Reorder Buffer bzw. die Texturememory kommen, wird der Cache nicht umsonst so heißen
Das nur mal am Rande.
€dit: danke für's Verschieben
Das nur mal am Rande.
€dit: danke für's Verschieben
Zuletzt bearbeitet:
scully1234
Banned
Ich denke mal früher oder später wird kein weg an multicore plattformen im grafiksektor vorbeiführen,da es so langsam aber sicher eng wird mit Strukturverkleinerungen aus physikalischer Sicht u Taktfrequenzrekorden
Andere Technologien sind ja leider noch in weiter Ferne u imo noch nicht greifbar
Zuletzt bearbeitet:
Ich denke mal früher oder später wird kein weg an multicore plattformen im grafiksektor vorbeiführen,da es so langsam aber sicher eng wird mit Strukturverkleinerungen aus physikalischer Sicht u Taktfrequenzrekorden
Andere Technologien sind ja leider noch in weiter Ferne u imo noch nicht greifbar
die dinge die du erwähnst kritisieren aber genau so deinen vorschlag.
mehr kerne = mehr transistoren, mehr strom verbrauch, ist quasi nichts anderes wie eine vergrößerte recheneinheit im ganzen.
iergentwie auch keine wirkliche effizienz steigerung.
mit architektur verbesserung lässt sich in zukunft noch am meisten leistung raus holen.
Ich frage mich immer warum die Taktfrequenzen bei GPUs soviel geringer als bei CPUs sind. Da liegt ja immerhin ein Faktor 4 dazwischen.
GPU-Chip-Strukturen sind deutlich homogener und deutlich leichter durch eine höhere Anzahl von Pipelinestufen für höhere Frequenzen optimierbar.
Da selten gesprungen wird, sollten lange Pipelines im worst case einer falschen Vorhersage auch nicht so weh tun wie bei CPUs.
GPU-Chip-Strukturen sind deutlich homogener und deutlich leichter durch eine höhere Anzahl von Pipelinestufen für höhere Frequenzen optimierbar.
Da selten gesprungen wird, sollten lange Pipelines im worst case einer falschen Vorhersage auch nicht so weh tun wie bei CPUs.
Zuletzt bearbeitet:
scully1234
Banned
Es ist einfach so das mit Strukturverkleinerung physikalisch bedingt nicht mehr lange fortgefahren werden kann,die kleinste strukturbreite waren glaube ich 20 oder 15 nm die laut Aussagen noch realisierbar sind(korrigiert mich wenn ich mich irre)ohne das die elektronen flüchtig werden u die vorgegebenen Leiterbahnen verlassen
Und Quantentechnologie existiert mehr oder weniger noch in den Köpfen als in der Realität.
Also welche anderen Möglichkeiten bestehen noch (in naher Zukunft) ausser auf Multicoreplattformen zu wechseln,um die Performance noch weiter nach oben zu treiben
Zuletzt bearbeitet:
Neurosphere
Enthusiast
- Mitglied seit
- 06.11.2008
- Beiträge
- 4.324
11nm...vorher sollten 16nm kommen.
Das Problem scheint dann aber noch immer nicht die Atombreite sondern dieFertigung zu sein. Physikalische ginge also evtl noch weniger.
Das Problem scheint dann aber noch immer nicht die Atombreite sondern dieFertigung zu sein. Physikalische ginge also evtl noch weniger.
scully1234
Banned
Wenn ich mir anschaue was TSMC jetzt schon für massive probleme mit der 40nm Strukturbreite hat sehe ich 11nm für eher unwahrscheinlich als machbar
Zuletzt bearbeitet:
Es ist einfach so das mit Strukturverkleinerung physikalisch bedingt nicht mehr lange fortgefahren werden kann,die kleinste strukturbreite waren glaube ich 20 oder 15 nm die laut Aussagen noch realisierbar sind(korrigiert mich wenn ich mich irre)ohne das die elektronen flüchtig werden u die vorgegebenen Leiterbahnen verlassen
Und Quantentechnologie existiert mehr oder weniger noch in den Köpfen als in der Realität.
Also welche anderen Möglichkeiten bestehen noch (in naher Zukunft) ausser auf Multicoreplattformen zu wechseln,um die Performance noch weiter nach oben zu treiben
davon hab ich nichts bestritten.
nur kann man auch nicht einfach mehr kerne implementieren da dadurch auch die strom und hitze entwicklung immer mehr zunimmt.
stell dir vor du hast nen dual core in der größe einer heutigen karte
oder einen 20 core mit der karten größe deines towers
da kannst du dir sicher vorstellen welche strom mengen da benötigt werden.
einfach mehr chips und kerne dran pappen ist eben auch kein weg um dem nm stopp auszuweichen.
die entwicklung wird sicher schlagartig verlangsamt und alle paar jahre wird es dann architektur verbesserungen geben, und alle 5-10 jahre eine komplett neu entwickelte architektur.
Neurosphere
Enthusiast
- Mitglied seit
- 06.11.2008
- Beiträge
- 4.324
Wenn ich mir anschaue was TSMC jetzt schon für massive probleme mit der 40nm Strukturbreite hat sehe ich 11nm für eher unwahrscheinlich als machbar
Bei sowas musst du Intel als Standard nehmen. Sie haben meines wissens die besten Fabs zur Fertigung und sind eigentlich auch die Maßangabe was sowas betrifft.
---------- Beitrag hinzugefügt um 16:57 ---------- Vorheriger Beitrag war um 16:54 ----------
Das ist schwer zu sagen. Ich denke nicht das das ganze verlangsamt wird oder zumindest nicht schon wesentlich langsamer als jetzt.
Ich denke durch den Umschwung auf andere Materialien die wesentlich Temperaturunempfindlicher sind oder verbesserte Transistoren ermöglichen wird in Zukunft noch einiges bei den Taktraten passieren.
Zuletzt bearbeitet:
scully1234
Banned
Das mag sein das Intel die technologisch hochwertigsten Fabs hat,aber wir sind heute schon bei 40nm angelangt bzw Intel bei 32nm,selbst wenn 11nm wirklich eines guten Tages zu händeln wären,sind dies sicherlich keine grossen Sprünge mehr bis zu dieser Strukturbreite,die die Performance signifikant in die Höhe treiben werden
Es muss ein anderer Ausweg her,um das Mooresche Gesetz aufrecht zu erhalten,soviel ist sicher
Zuletzt bearbeitet:
Soweit ich weiß scheint die Intel's Yield Rate bei 32nm auch nicht so toll zu sein; also einfach ist es jedenfalls nicht.