Also sprechen wir von FMA Einheiten die pro Taktzyklus eine Addition und eine Multiplikation durchführen können. Allerdings nach IEEE 754 Standart mit doppelter Precision als 8byte Zahl. Was also bei der Berechnung durch die späte Rundung zu viel Aufwand führt und zu längeren Zahlenwerten aber auch zu höhere Genauigkeit der Werte.
Aufwand ist ja relativ, kostet halt den Platz, um so breite Datenpfade und ALUs zu implementieren, nicht wahr
Neurosphere schrieb:
Hätte ich also die Aufgabe 2^1/2 würde ich bei einfacher Genauigkeit einen Wert mit knapp 40 Nachkommastellen und in doppelter Prezision mit rund 300 Nachkommastellen.
Ich hätte also zum einen das Problem der längeren/aufwändigeren Berechnung und zum anderen der größeren Zahlenwerte die ich händeln muss.
Was für eine Aufgabe? Was ist an 2^1/2 denn eine Aufgabe? 2^1/2 lässt sich doch schon mit IEEE-754r (16 Bit) mehr als exakt darstellen (würde ja sogar mit einem Bit VZ, zwei Bit Exponent und ohne Mantissenbits gehen
).
An der Stelle kommt mir spontan die Frage in den Sinn, obs auch Gleitkommazahlen mit einem Exponentenbit gibt und ob da der Bias ernsthaft 1 ist.
Neurosphere schrieb:
Wenn ich also nV wäre und die Fähigkeit meines Chips in DP steigere, steigere ich doch eigentlich auch automatisch die Leistung in SP, zumindest in der puren Berechnung der Zahlenwerte.
Mr.Malik schrieb:
Würde vermuten, dass es also durch die Verbreiterung auf 32-Bit diesen
Performanceboost bei DP gibt.
Ich weiß nicht, ob ich da gerade auf dem Schlauch stehe, aber wieso soll die Verbreiterung auf INT32 bei MUL etwas mit dem FP64-Durchsatz zu tun haben? Ich denke mal, Neurosphere liegt da schon ganz richtig, und wenn DP wirklich 1/2 von SP ist, riecht das doch einfach ganz gewaltig nach schlichter paarweiser Kopplung der ALUs. Setzt wohl eine gewisse Modularität beim Scheduling voraus (oder der Compiler macht hier seinen Job), aber ATi machts ja (fast) genauso.
Mr.Malik schrieb:
Klar, ich besorg mir gleich eine Hornbrille, damits authentisch wirkt.
fdsonne schrieb:
Aber ich könnte mir vorstellen, das man native DP Einheiten auch mit SP Aufgaben füttern kann, sollte theoretisch ja kein Problem darstellen... und somit die Leistung erhöhen.
Theoretisch schon, ist eigentlich nur eine Compilerfrage. Aber wer würde sowas in Zeiten von VLIW noch machen (falls einer auf die fixe Idee kommt, ja, ich weiß, dass es hier nicht um Instruktionen geht
)? Da laufen ja überwiegend nur Zero Bits durch das Schaltnetz. Das kann ich mir nicht vorstellen.
fdsonne schrieb:
Bei AMD arbeitet doch seit dem R600 eine komplette "5D ALU" an einem DP Operation, was bedeutet, das man nur ein fünftel der SP Leistung für DP hat...
Bei NV geschieht dies doch derzeit durch mehrere Durchläuft durch die SP Einheiten + das bisschen, was die nativen DP Einheiten können, soweit ich weis...
Das wäre mir neu, nach meinem Kenntnisstand sind die Transcendentals in jeder Vektor-ALU nicht DP-fähig (d.h. nicht für DP-Berechnungen nutzbar). Oder hab ich das falsch verstanden und die Einheiten sind zwar DP-fähig, aber es gibt nur keine DP für sine/cosine/sqrt/etc (Transcendentals eben)?
Neurosphere schrieb:
Wundert mich ja eigentlich etwas das bisher niemand mit FPGAs bei GPUs arbeitet afaik. Optimaler ginge es ja eigentlich nicht mehr.
mr.dude schrieb:
FPGA ist seit dem Wegfall von T&L hin zu universelleren Shadern ein zentraler Bestandteil von GPUs. Das ist mittlerweile wie lange her? Ein Jahrzehnt?
Ich wüsste nicht, dass jemand auf die Idee kommen sollte, FPGAs in GPUs einzubauen. Das ist ja so ziemlich das genaue Gegenteil eines ASIC. Und es hat auch einen Grund, warum man das nicht nutzt: Performance. Custom-made logic ist deutlich schneller als ein FPGA. Das sag ich aus zwei Gründen, erstens, weil das Board der ersten Revision beim Open Graphics Project auf einem FPGA basiert und ich mich gut an das Performance-Geschrei erinnern kann, was dadurch aufkam, und zweitens, weil ich das selber schon ausprobieren durfte (natürlich nicht an einer GPU, sondern an einem einfachen RISC-Mikroprozessor). Auch wüsste ich nicht, welche logischen Funktionen einer GPU man so gut minimieren kann, dass es sich lohnt (Primimplikanten haben die alle recht viele) und die vor allem auch noch so reichlich vorhanden sind, dass man dafür ein FPGA nutzen wöllte. Ist ja letztlich auch eine Platzfrage, denn wenn man nicht alle Knoten und Ports am FPGA belegt, verschwendet man selbigen nur.
Ich lass mich aber gern eines besseren belehren, wenn du konkrete Beispiele hast, wo ein FPGA in einer GPU eine Rolle spielt. Ich kanns mir nur wie gesagt nicht vorstellen.
Verschiebung in den Technikthread ist übrigens keine schlechte Idee, andererseits passt das ja auch prima hierhin. Sind eben mal gehaltvollere Spekus als "Ich will ne GTX380!!!!111einself".