[Sammelthread] Grafikkarten - Technikdiskussion

Sorry.Hätt ich ma lesen sollen.:confused:
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Abend zusammen,

ich habe seit einiger Zeit Probleme mit meiner GTX260, abstürze, schwarzer Bildschirm etc.
Jetzt habe ich eben mal das aktuelle GPU-Z laufen lassen, dabei ist mir aufgefallen, das die verschiedenen Taktraten krumme Werte haben (siehe Screen).
Jetzt stellt sich mir die Frage, ob das evtl. damit zusammenhängen könnte?

gtx260.gif
 
Das ... kann ... nicht ... dein ... Ernst ... sein! Den Nutzer über dir hab ich abgemahnt, dass er sich mal die Threadregeln durchlesen soll, und der nächste postet gleich wieder OT?
 
Oh sorry, hab ich in der Panik des Fehler überlesen.:fresse:
 
Lord schrieb:
Jungs, ich hab gestern abend vorm Einschlafen über etwas nachgedacht, was ich nicht so recht beantworten konnte.

Und zwar geht es um die in aktuellen GPU-ALUs enthaltene MUL-Funktionalität. Soweit wir wissen, wird dort eine Multiplikation in einem Takt durchgeführt. Die einzige mir bekannte Möglichkeit, die Multiplikation soweit zu parallelisieren, dass das möglich ist, ist per PLA-Decoder-Multiplikationseinheit. Das erfordert aber für 2 32 Bit breite Datenworte schon 2^64 * 64 Bit Speicher und das haben aktuelle ALUs definitiv nicht. Die normale bitserielle Multiplikationslogik braucht pro Stelle des Multiplikanden einen Takt plus einen Takt für die Addition der temporären Ergebnisse - das kann es also auch nicht sein. Aber sogar, wenn man das ähnlich wie beim Carry-Save-Addierer mit großem Logikaufwand zu parallelisieren versucht, sehe ich noch nicht, wie man ohne MIMD-ALUs die gesamte Multiplikation in einen Takt kriegen soll - ich komme bestenfalls auf einen Takt für den multiplikativen Anteil und (je nach ADD-Logik) entsprechend viel für den Rest. Einfach jedes alternative Verfahren, ob auf 2K-Zahlen (wo mir übrigens mal einer sagen könnte, ob Booth Recoding das effizienteste aktuell genutzte Verfahren ist) oder Gleitkommaarithmetik, dauert mehr als einen Takt.

Jemand Ahnung, wie das laufen soll?
Zum Vergrößern anklicken....

Ich hab vor längerer Zeit mal eine ALU aus Transistoren gebaut, sie war 32bit breit und konnte pro Takt: 2Operanten Multiplizieren(MUL); Addieren (ADD); Multiplizieren mit folgendender Addition (MADD); Subtrahieren (SUB); Negieren(NEG) und vergleichen( >= ). Es war möglich ein Integer-Wert sowie ein FP-Wert als Operant zu verwenden. Die ganze Alu fraß 4356 npn-Transis. Zum vergleich ist hier mal ein 8086 (16-bit CPU mit cache und registern) mit 29 000 Transitoren. Das einzige Problem war eine Taktbegrezung durch die Schaltzeiten der Transistoren. Fertigt man diese allerdings in kleineren Strukturen, veringert man die Schaltzeit ;) - Programm war ein kleines Freeware-Tool dessen Name ich nichtmehr kenne. Die Datei ist auch seit einem HDD-Crash vor 2Jahren weg, ich erinnere mich aber lustigerweise noch an den Aufbau und könnte die ALU entsprechend neubauen *happy*

@Multi-GPU:
das Problem ist wie einige male Angedeutet der Syncronisationsaufwand. Es sit nötig eine Steuereinheit der GPU-Cores überzuordnen, die sehrschnellen Zugriff auf die Cores sowie den Inhalt des VRAMS besitzt. Wenn man das weiterführt ist es tatsächlich einfacher die Recheneinheiten zu vervielfachen und Effizenter zu Organisieren, um extreme Latenzen zu vermeiden.
EDIT: Es wäre viell möglich am Thread-Dispatcher einen Komunikationslink nach außen (oder vier ;D) anzubringen, der dann zusammen mit den Anderen in GPU1; GPU2; GPU3 die Instructionen auf die 2-4 GPU-Cores verteilt. Der TD bekommt schließlich die fertig compilierten Vertex/Pixel/Compute Anweisungen die nurnoch verteilt werden müssen. Problem ist das trotzdem zwei- bis vierfach die selben Anweisungen Compiliert werden müssen. Viell ist es besser dann schon am Command-Prozessor anzusetzten, den der saugt sich die Anweisungen aus dem Speicher und schickt sie zum compilen (mit Compilen ist hier das Transformieren der Daten zu ALU-Verständlichen Daten gemeint). Der Sideport ist am Hub angeschlossen und hat indirect zugang zum Command Prozessor und zum Speicherinterface der GPU, es wäre also durchaus schon möglich gewesen, wenn man diesen benutzt hätte, die GPUs bei einer 4870X2 auf nahe zu die doppelte Leistung zu beschleunigen und das AFR hinter sich zu lassen. Woran es genau scheitert ist ungewiss.

@5D-ALUs bzw. SIMDs in der R600-RV870:
"Ich versuchs auch mal zu erklären.
Architektur:
- Der RV870-Chip(Stream-Prozessor) besteht aus 20 SIMD-Engines, die unabhängig voneinander arbeiten
- Jede SIMD-Engine ist in 16 ThreadProzessoren unterteilt, die stets die gleiche Instruktion ausführen(ein VLIW).
- Jeder Thread-Prozessor hat 5 skalare Alus(Stream-Cores), die von einem VLIW gesteuert werden

Ablauf:
- Alle 4 Takte führt eine SIMD-Engine ein identisches VLIW für eine Wavefront(=Bündel aus 64 Threads) aus
- In Takt0 wird das VLIW für die Threads 0-15 ausgeführt, Takt2: Threads 16-31, Takt3: Threads 32-47, Takt4: Threads 48-63. Jeweils von den 16 Threadprozessoren.
- In jedem VLIW sind 5 skalare Instruktionen kodiert, die keine Abhängigkeit untereinander haben. Eine Instruktion davon kann komplex sein(sin/cos), die anderen 4 MAD.

=> Dieses 5D-VLIW wurde vom Compiler erzeugt und ist danach fix.
Wenn der (Shader-)-Sourcecode nicht genug unabhängige Instruktionen ermöglicht, wird das VLIW mit bis zu 4 NOPs aufgefüllt, und die Effizienz sinkt entsprechend auf bis zu 20%.

Zusammenfassend: Je SIMD-Engine und Taktzyklus werden also bis zu 16x5=80 skalare Instruktionen abgearbeitet. Auf dem gesamten Chip also 20x80=1600. " - Nighthawk13 @3DCenter

Anhang:
ich denke das bei ca. 10-12nm für unsere herkömmliche Bauweise ersteinmal schluss ist, dann nach geht das Effizenz-Rennen los.
Es wird endlich ein Weg gefunden der Overhead beseitigt, der entsteht wenn ein Dreieck ein Anderes überzeichnet.
Viell macht man sich sogar die Mühe von Handoptimierung^^ NAND+NAND=>NAND+NOT=>AND und solche Scherze x)
Es könnten die Schaltwege der Transistor Ein-/Ausgänge angepasst werden, die Gates mit Materialien erstellt werden, die geringere Schaltzeiten ermöglichen, um eine Taktsteigerung zu ermöglichen.

LG:btt:
 
Zuletzt bearbeitet:
12nm mit herkömmlicher Lithografie? Ui, viel Spaß :fresse:
Oder war das auf den Weg "Transistoren lassen sich nur durch eins ersetzen: Mehr Transistoren!" bezogen? Den Versuch, die Rechenlast von vornherein durch Optimierung und Auswahl der zu rendernden Polygone drastisch zu verringern, den gabs ja schon. Aber die Kyro verschwand auch recht fix wieder vom Markt...irgendwann wird das wieder jemand aufgreifen, ja.
 
Die durchschnittliche FPS wird aus min. und max FPS errechnet, wie sollen dann solche Werte herauskommen?
Die HD5870 hat unter max fps 3fps mehr
Fermi hat unter min fps 17fps mehr
im Durchschnitt liegt Fermi aber ~2,5 fps hinter einer 5870
 
@Turbostaat: es wird nicht nur der (max-wert + mindwert )/ 2 = average sondern so wie motkachler es sagt - gerechnet.
also avg-fps über den ganzen verlauf des tests
 
Zuletzt bearbeitet:
Turbostaat schrieb:
Die durchschnittliche FPS wird aus min. und max FPS errechnet, wie sollen dann solche Werte herauskommen?
Die HD5870 hat unter max fps 3fps mehr
Fermi hat unter min fps 17fps mehr
im Durchschnitt liegt Fermi aber ~2,5 fps hinter einer 5870
Zum Vergrößern anklicken....

Falsch...
Die AVG FPS sind ein Durchschnittswert über einen Gemessenen Zeitabschnitt und nicht der Durchschnitt nur von MIN und MAX!
MIN und MAX FPS Angaben sind absolute Werte und zeigen jeweils den kleinsten und den größten Ausschlag der FPS Kurve an. Ohne ein Frameverlaufsdiagramm nutzt dir MIN und MAX gar nix.
 
Turbostaat schrieb:
Die durchschnittliche FPS wird aus min. und max FPS errechnet, wie sollen dann solche Werte herauskommen?
Die HD5870 hat unter max fps 3fps mehr
Fermi hat unter min fps 17fps mehr
im Durchschnitt liegt Fermi aber ~2,5 fps hinter einer 5870
Zum Vergrößern anklicken....

Es kommt drauf an wie lang die FPS-Min Grenze da war. Wenn sagen wir die Min-FPS bei ca. 25FPS war, und das nur eine halbe Sekunde lang, dann wirkt sich das quasi auf die durchschnittliche FPS nicht aus! ;)
 
Die durchschnittlichen FPS sind aber nicht gleich dem arithmetischen Mittel zwischen den min. und max. FPS.
Die errechnen sich in dem alle Frames zusammengezählt und durch die Zeit des Benchmarks geteilt werden.
Wenn die ATI nur einen Einbruch hat der vielleicht 2 Sekunden dauert in einem Bench von 30 oder mehr Sekunden, liegen die durchschnittlichen FPS nicht gleich viel weiter unten.

Edit: Bisschen langsam. :d
 
Zuletzt bearbeitet:
Ganz einfache Rechnung der durschnitts FPS:

Anzahl Einzelbilder / benötigte Zeit (in Sekunden) für den ganzen Benchmark = Durchnittliche FPS! ;)
 
Romsky schrieb:
Wenn sagen wir die Min-FPS bei ca. 25FPS war, und das nur eine halbe Sekunde lang, dann wirkt sich das quasi auf die durchschnittliche FPS nicht aus! ;)
Zum Vergrößern anklicken....

Wie soll das gehen? FPS (Frames/Bilder pro Sekunde) werden sekündlich gemessen, wie soll das also nur eine halbe Sekunde lang anliegen?

Einige hier sollten sich vllt erstmal mit den Grundlagen beschäftigen bevor man hier Theorien aufstellt... :wall:

Und nein, der MIN FPS Wert wirkt sich idR immer negativ auf die AVG FPS aus, einziges Szenario wo das nicht so ist, wenn MIN und MAX Wert exakt das gleiche Zeigen...

SOLDIER schrieb:
Um nochmals zu den abgespeckten Shader ALUs zu kommen, hies es nicht einmal sie würden die Shaders kürzen auf 480 um die TPD ein zu halten um die 300W weil der Fermi recht heiss laufen soll, ich verstehe einfach nicht wiso immer alle davon reden sie wollen die volle 512 Shader wenn es nicht von der TPD her geht, ich denke die werden bei den 480 bleiben der Verbrauch sollte moderat sein. Wie sehe wohl das aus wenn ich die vollen 512 hätte und die TPD geht über die 300W Temparatur dem entsprechend, geht nicht dachten die Ingieure doch da.
Zum Vergrößern anklicken....

Eine logische Erklärung warum man nur mit 480 Einheiten kommt liegt wohl viel eher darin, das man so die Ausbeute funktionsfähiger GPUs erhöht. Weil eben mehr Fehler im Chip tollerierbar sind.

Von moderatem Verbrauch kann nicht wirklich die Rede sein ;)
 
Zuletzt bearbeitet:
EDIT:"Ein Nanometer entspricht in einem Stück Metall ungefähr einer Strecke von vier benachbarten Atomen" wären bei 10nm Gate-Breite also noch ca. 40 Atome bzw. etwas mehr weil... naja Genau kann ich dir überhaupt nix sagen, da es im Inet einfach nix offenes gibt zum nachschauen wie weit man in der Entwicklung ist ;)
http://de.wikipedia.org/wiki/Fotolithografie_(Halbleitertechnik) <-- bis 7nm angeblich, aber ich glaube nur was ich sehe und begründen kann ;D

Kyro war in der Technik weit voraus, aber ihnen fehlte das Geld und der Mut zu größerem. Schade eigendlich.
EDIT: Einen Verdeckungs-Algorithmus ähnlich eines Raytracers könnte zumindest die Texturierungs und Pixelleistung vermindern.
 
Zuletzt bearbeitet:
@fdsonne
Du weisst schon was ich meine, oder? Die halbe Sekunde war nur ein Beispiel. Dann sagen wir halt nur 1 Sekunde. (Außerdem weisst du nicht in welchen Intervallen Benchmarktools die FPS berechnen. Mag sein das es meist 1 Sekunde ist... aber Intervalle von 500ms oder weniger sind zumindest technisch auch möglich. Ich bin selber Programmierer, und Abfrageintervalle werden eigentlich immer in ms angegeben.). Desweiteren klar wirkt sich ein MIN-FPS Wert auf die AVG aus.... aber wenn diese MIN-FPS nur 1 Sekunde da sind ist es was anderes als wenn die MIN-FPS 10 Sekunden da sind!

Von daher mal nicht ganz so voreilig mit dem Vorwurf fehlenden Wissens einer Materie! ;)
 
Zuletzt bearbeitet:
Romsky schrieb:
@fdsonne
Du weisst schon was ich meine, oder? Die halbe Sekunde war nur ein Beispiel. Dann sagen wir halt nur 1 Sekunde. (Außerdem weisst du nicht in welchen Intervallen Benchmarktools die FPS berechnen. Mag sein das es meist 1 Sekunde ist... aber Intervalle von 500ms oder weniger sind zumindest technisch auch möglich. Ich bin selber Programmierer, und Abfrageintervalle werden eigentlich immer in ms angegeben.). Desweiteren klar wirkt sich ein MIN-FPS Wert auf die AVG aus.... aber wenn diese MIN-FPS nur 1 Sekunde da sind ist es was anderes als wenn die MIN-FPS 10 Sekunden da sind!

Von daher mal nicht ganz so voreilig mit dem Vorwurf fehlenden Wissens einer Materie! ;)
Zum Vergrößern anklicken....

Was ist da unklar?
FPS bedeutet Frames pro Sekunde...
Also Einzellbilder die in einer Sekunde dargestellt werden können.

Nix mit kleineren Intervallen. Dann sind das keine FPS mehr, sondern Frames pro s/2 oder weis der Geier.


Und ja, das was du beschreibst ist genau das Problem der absoluten MIN FPS Angabe. Man weis nicht wie lange dieser Wert bestand hatte bei der Messung. Logische Schlussfolgerung -> Frameverlaufsdiagramme ;)
Erschwerend kommt teilweise noch hinzu, das einige Karte bei Beginn der Messung für die ersten wenigen Sekunden noch im 2D Modus verweilen und erst dann hochtakten. Oder das zu Beginn einer Messung erst Daten in den Speicher geladen werden. Sprich die MIN FPS kommen sehr oft in den ersten paar Sekunden zu stande und verfälschen das Game Bild. Aufschluss bringt halt nur ein Verlaufsdiagramm
 
Zuletzt bearbeitet:
Klar.... du weisst aber nicht wie die FPS von dem Tool/Benchmarkenginbe berechnet werden. Nehmen wir an der Abfrageintervall liegt bei 250ms, und die Min-FPS liegt für 250ms bei 10 dann wieder bei 20..... dann hast du bei dieser Sekundenberechnung einen FPS Wert von 17,5. Sprich in dieser Sekunde wurden 17,5 Bilder berechnet.

Weisst du was ich meine? FPS definiert zwar die Anzahl der Bilder pro Sekunde, wie diese aber berechnet/abgefragt wird ist eine andere Sache. Und wie gesagt, bei Programmen werden Intervallabstände immer in ms angegeben. Daher ist es auch messebar wenn ein MIN-FPS nur 200ms anlag oder so.
 
Zuletzt bearbeitet:
Romsky, es gibt kein "Abfrageintervall".
Das Programm zählt einfach nur jede Sekunde die Frames.
Mehr raffinierte Technik steckt da nicht hinter.
 
Du bist kein Programmierer, oder? ^^
Was denkst du wie das Programm weiß wann ne Sekunde zu ende ist. Sowas nennt man einen Intervall. Sprich das Programm fragt alle 1000ms ab wieviel Bilder gerendert wurden. So etwas geht nur mit Intervallen.
 
Romsky schrieb:
Klar.... du weisst aber nicht wie die FPS von dem Tool/Benchmarkenginbe berechnet werden. Nehmen wir an der Abfrageintervall liegt bei 250ms, und die Min-FPS liegt für 250ms bei 10 dann wieder bei 20..... dann hast du bei dieser Sekundenberechnung einen FPS Wert von 17,5. Sprich in dieser Sekunde wurden 17,5 Bilder berechnet.

Weisst du was ich meine? FPS definiert zwar die Anzahl der Bilder pro Sekunde, wie diese aber berechnet/abgefragt wird ist eine andere Sache. Und wie gesagt, bei Programmen werden Intervallabstände immer in ms angegeben. Daher ist es auch messebar wenn ein MIN-FPS nur 200ms anlag oder so.
Zum Vergrößern anklicken....

Das ändert aber nix an der Tatsache, das es dann kein FPS Wert mehr ist, weil die Messung eben nicht mehr im Sekundenintervall stattgefunden hat.

Und mir ist schon bewusst, das man das noch weiter runter brechen kann. Das geht soweit, das man die einzelnen Frametimes misst um die Gleichmäßigkeit der Bildausgabe zu begutachten. Aber wie gesagt, ein FPS besteht eben aus x Bildern pro 1000ms. Nicht mehr und nicht weniger.
 
Richtig gerade ATI bricht im in den ersten Sekunden eine Benches immer gut ein , Benchmarks wie der von Crysis zählt natürlich genau diesen Moment als schwächste Stelle und dadurch macht es den Anschein als hätte ATI bei diesen Games weniges Min Frames.

Die Messungen sind fürn Garten, jeder der sich mal selber hinsetzt und es nachstellt wird merken das beim ersten Run die ersten Sekunden immer wegen starken Nachladerucklern einbrechen. Min Frames Messe ich nach dem 3 oder 4 Durchgang wenn genug Daten im Speicher liegen und keine Nachladeruckler mehr sind.
 
Klar, mir ging es nur darum das ein Min-FP"S" Wert auch nur für "ne halbe Sekunde" anliegen kann und das sich nur minimal auf die AVG auswirkt.
 
Zuletzt bearbeitet:
Wenn du eine halbe Sekunde lang 10Frames hast ud die andere hälfte dieser Sekunde dann wieder 30, hast du 40FPS.
 
Korrekt... bestes Beispiel dafür SLI/Crossfire mit uRuckler! ;)

Wenn das Programm / die Engine allerdings alle 500ms abfragt wieviel Bilder denn schon gerendert sind dann rechnet es:
{10+30/2} ergo 20 FPS

(was sicher bezüglich Ruckler eine bessere Aussage machen würde)
 
Zuletzt bearbeitet:
trunxsz schrieb:
Romsky, es gibt kein "Abfrageintervall".
Das Programm zählt einfach nur jede Sekunde die Frames.
Mehr raffinierte Technik steckt da nicht hinter.
Zum Vergrößern anklicken....

Das stimmt auch nicht wirklich, man zählt wenn dann die Zeit die vergeht, bis das nächste Bild auf den Schirm kommt in ms. Und bildet dann einen Durchschnittswert der Bilder für eben eine Sekunde. Genau aus diesem Grund wirken bei Beispielsweise 30FPS im Schnitt MGPU Systeme oft deutlich ruckliger als SGPU Systeme. Einfach weil die Frametimes zwischen den Frames stark schwanken. Im Schnitt sind es aber immernoch 30 FPS pro Sekunde. Wie diese sich zusamensetzen, spielt primär bei FPS Vergleichen keine Rolle. Da man eben nur mit Durchschnittswerten arbeitet.

Romsky schrieb:
Klar, mir ging es nur darum das ein Min-FP"S" Wert auch nur für "ne halbe Sekunde" anliegen kann und das sich nur minimal auf die AVG auswirkt.
Zum Vergrößern anklicken....

Ja schon klar, ich weis was du meinst, aber nochmal, das sind dann keine MIN FPS...

trunxsz schrieb:
Wenn du eine halbe Sekunde lang 10Frames hast ud die andere hälfte dieser Sekunde dann wieder 30, hast du 40FPS.
Zum Vergrößern anklicken....

Richtig, wenn sich das ganze periodisch wiederholt, sind das altbekannte MR in MGPU Systemen.

Romsky schrieb:
Korrekt... bestes Beispiel dafür SLI/Crossfire mit uRuckler! ;)

Wenn das Programm / die Engine allerdings alle 500ms abfragt wieviel Bilder denn schon gerendert sind dann rechnet es:
{10+30/2} ergo 20 FPS

(was sicher bezüglich Ruckler eine bessere Aussage machen würde)
Zum Vergrößern anklicken....

Ähm ne, das wären wenn dann 20 Frames pro halbe Sekunde ;)

Wenn ne halbe Sekunde lang 10 Frames gezeigt werden und ne weitere halbe Sekunde lang 30 Frames. Sind das in Summe 40 Frames in einer Sekunde -> ergo 40FPS.

Misst du nun im halbsekunden Intervall, also alle 500ms musst du zwei Messungen erfassen. Es sind immernoch 40 FPS, da FPS eben eine Sekundengenaue Angabe ist. (daher auch zwei Messungen nötig)
 
Zuletzt bearbeitet:
Jupp ich weis, ich schieb das gleich mal in den Technikthread... Aber das musste einfach geklärt werden ;)
 
fdsonne schrieb:
Ähm ne, das wären wenn dann 20 Frames pro halbe Sekunde ;)
Wenn ne halbe Sekunde lang 10 Frames gezeigt werden und ne weitere halbe Sekunde lang 30 Frames. Sind das in Summe 40 Frames in einer Sekunde -> ergo 40FPS.
Misst du nun im halbsekunden Intervall, also alle 500ms musst du zwei Messungen erfassen. Es sind immernoch 40 FPS, da FPS eben eine Sekundengenaue Angabe ist. (daher auch zwei Messungen nötig)
Zum Vergrößern anklicken....

Es sind bereits 2 Messungen: 1. Messung (10 Frames) + 2. Messung (30 Frames). Meine Rechnung wär der Sekundeninterne AVG Framewert. ^^

Aber ok... b2Topic!
 
Zuletzt bearbeitet:
Romsky schrieb:
Es sind bereits 2 Messungen: 1. Messung (10 Frames) + 2. Messung (30 Frames). Meine Rechnung wär der Sekundeninterne AVG Framewert.
Zum Vergrößern anklicken....

Klar hast du zwei Messungen, aber die beiden Messungen ergeben in Summe eben nur eine ganze Sekunde. Sprich du darfst hier nicht den Mittelwert beider Messungen nehmen, sondern musst diese Addieren um einen FPS Wert zu bekommen.

Eine halbe Sekunde + eine halbe Sekunde ergibt bekanntlich erst eine ganze Sekunde.
Nicht eine halbe + eine halbe / zwei ;)
 
Ohne zu wissen wie ein Programm wie Fraps seine Werte ermittelt gibts irgendwie keine richtige grundlage für diese Diskussion.
 
Anmelden, um zu antworten.
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