Physikprozessoren in Zukunft denkbar?

[Höhnangst]

Da ich bis zum heutigen Tage finde, dass die Physik immer noch eines der größten Mankos - abgesehen von der KI - ist, würde mich mal interessieren, was ihr von der Idee eines hochspezialisierten Prozessors haltet, der allein für physikalische Vorgänge zuständig ist und diese möglichst schnell und korrekt berechnen soll - ähnlich den Grafikchips (nur eben für die Physik). Aufgrund der Möglichkeit, die typischen, physikalischen Vorgänge mathematisch beschreiben zu können, sehe ich als Laie schon eine Vorraussetzung gegeben, dass so ein Chip gebaut werden kann.

Was spricht dafür oder dagegen, dass solche Prozessoren im zukünftigen PC Einzug halten könnten?

[huha]

Was dagegen spricht: Die nur sehr begrenzte Einsatzfähigkeit solcher Prozessoren. Das Problem ist, daß sich sowas erst lohnt, wenn Spiele dermaßen abhängig von der Physik werden, daß wirklich zusätzliche, hochspezialisierte Rechenkapazität in der Hinsicht gefordert ist. Das wird wohl kaum der Fall sein, da bei Spielen immer auf größtmögliche Abwärtskompatibilität geachtet wird und somit auch Rechner ohne diese Physikprozessoren kompatibel sein müssen. Abstriche bei der Graphik sind für ein Spiel erträglich, Abstriche bei der Physik verändern das Spiel an sich. Oder würdest du es gut finden, wenn bestimmte Sachen im Spiel erst dann möglich wären, wenn du eine Zusatzkarte mit Physikprozessor einbaust? Ich nicht.

Insofern denke ich nicht, daß sowas in absehbarer Zeit kommen wird. Da glaube ich schon eher, daß die Graphikkarten in Zukunft viel mehr mißbraucht werden als heutzutage und vielleicht auch solche Berechnungen noch als Zusatz für die Shader kriegen.

Das Problem bei Physikberechnungen ist ja "an sich" nicht die Komplexität einzelner Berechnungen, sondern die schiere Masse an Berechnungen, die durchgeführt werden müssen (Wechselwirkungen etc. pp.). Insofern wird ein Prozessor benötigt, der besonders schnell ist und gleichzeitig halbwegs flexibel. Sowas läßt sich recht schwer auf irgendeine Erweiterungskarte bauen, da das sozusagen eine Zweit-CPU wäre, eben nur mit erhöhter Wärmeabgabe, da das Ding möglichst schnell sein soll. Ob sich sowas für den Massenmarkt lohnt, bezweifle ich doch stark, da die entsprechenden Sachen auch nicht ganz billig wären. Und wenn es ein Nischenmarkt bleibt, verschwindet die Implementierung dieses Features in Spielen wieder genausoschnell wie sie gekommen ist.

-huha

[BlackBirdSR]

Was spricht dafür oder dagegen, dass solche Prozessoren im zukünftigen PC Einzug halten könnten?

dass CPUs das schon ganz gut machen? Und man dafür zu bestimmten Teilen auch SSE nutzen kann?

[SentinelBorg]

Mit WGF 2.0 kommen doch schon die ersten Shader in diese Richtung, z.B. welche, für Kollisionsabfragen.

Sentinel

[Demirug]

Stimme des leidenden Entwicklers aus dem Hintergund: "Nicht noch ein Chip den man syncronisieren muss."

nVidia hatte die Idee auch schon und nennt sowas PPU für "physics processing unit". Das war aber wohl mehr ein Gedankenspiel.

Wenn zukünftige APIs eine bessere zwei Wege Kommunikation mit den Grafikkarten erlauben sehe ich eher das man sich dort etwas Leistung für die Physik holt. Physik die nur Auswirkung auf die Darstellung hat kann man ja auch heute schon auf die Grafikkarte auslagern.

[anddill]

Wozu? Unsere heutigen x86-CPUs sind doch Physikprozessoren. Dazu wurden sie jedenfalls mal entwickelt, bevor sie zum Spielen und für Multimedia mißbraucht wurden.

[Coda]

Mit WGF 2.0 kommen doch schon die ersten Shader in diese Richtung, z.B. welche, für Kollisionsabfragen.
Richtig wäre, dass man welche dafür schreiben könnte. Wie effizient das ist sei dahingestellt.

[Trap]

Im Gegensatz zur Grafikbeschleunigung gibt es bei der Physikberechnung keine allgemein anwendbaren/angewendeten Verfahren die man durch eine Spezialcpu beschleunigen könnte. Jede Anwendung benutzt andere Verfahren und ist irgendwie anders implementiert.
Dagegen gibt es bei 3d-Beschleunigung nur 1 Verfahren das beschleunigt wird.

[micki]

es würde reichen wenn die x86 dinger mal ne vernünftige extension bekämen die man nutzen kann z.b. für dot, cross, mat*mat, swizzling und so ca 32 bis 128 register.
das wäre viel besser als das oft nutzlose SSE,SSE2 (3dNow! ist von dem befehlssatz noch OK, aber dafür nervt der registershare mit der fpu, auf die ich aber auch komplett verzichten könnte, wenn die SIMD vernünftig wäre)

MfG
micki

[Höhnangst]

Nagut, also halten wir bisher fest:

Dedizierte Physikhardware (z.B. als zusätzliche Steckkarte) wird's wohl nicht geben. Jedoch kann ich mich auch mit der Idee anfreunden, dass man die Grafikkarte als kleinen, unterstützenden Rechenknecht in Zukunft einsetzen könnte (siehe Demirug). Außerdem gefällt mir der Vorschlag mit neuen, effizienteren und potenteren CPU-Extensions, die man zur Physikberechnung heranziehen könnte (siehe micki).

[Gast]

wenn sich die dualcore bzw. n-core cpus durchsetzen, habt iht euren dedizierten "physikprozessor"....

[Gabber[CH]]

Bringt doch definitiv nicht viel, es ist ja nicht so, dass da spezielle Berechnungen gemacht werden müssten.

Ich glaube kaum, dass Entwickler einen Core einer DCo-CPU zu einer "PPU" degradieren werden.
Denn so muss man die App wieder umschreiben, wenn dann QCo's kommen.

[M²]

Hi!

@ huha:

"Was dagegen spricht: Die [...] Physikprozessor einbaust? Ich nicht."

Hm, dazu nur eine Frage:
War das nicht damals mit den 3D-Beschleunigern nicht auch der Fall?
Kann mich erinnern, dass bestimmte Spiele ohne entsprechende Grafikhardware erst garnicht liefen. Von den Spielen die auf einmal MMX oder eine CPU aus einer bestimmten Serie dringend zum Starten benötigten mal ganz abgesehen.

Außerdem könnte man ja sowas als nette Dreingabe anfangs implementieren: z.B. mit PPU gibt's halt realistisch fliegende Einzelteile bei einem Crash in einem Rennspiel - ohne halt nur Standard.
Oder in einem Ego-Shooter wird eben ein Faß realistisch umkippen, gegen die Wand krachen usw. - ohne eben nur nach vorbestimmten Abläufen.

Hat sich die PPU mal in breiter Masse durchgesetzt kann man sie ja für Effekte nutzen ohne die das Spiel nicht spielbar wäre (z.B. man muss einen Enterhaken genau einrasten lassen, ein Fass mit Wasser anschießen um eine darunterstehende Wache abzulenken...)

Oder ist das jetzt auch kompletter Essig?

Mal abgesehen davon, dass es für den Konsumenten dann schwer wird:
Ich habe CPU A GraKa B und PPU C und welche Kombination verträgt sich? Welche brauche ich für das Spiel X?

MfG
M²

[huha]

Sagen wir' so: Heute ist der Markt recht gut mit Rechnern gesättigt, früher (beim Aufkommen der 3d-beschleuniger) war das noch nicht so extrem. Ergo muß heute viel mehr Rücksicht auf alle mögliche ältere Hardware genommen werden.
Physikprozessoren für Effekte wären nett, allerdings gilt es dann hier wieder, das Ganze so zu implementieren, daß es nicht spielbeeinflussend ist. Und ob diese Dinger dann so eine große Marktdurchdringung erhalten, wage ich zu bezweifeln.

-huha

[Coda]

es würde reichen wenn die x86 dinger mal ne vernünftige extension bekämen die man nutzen kann z.b. für dot, cross, mat*mat, swizzling und so ca 32 bis 128 register.
das wäre viel besser als das oft nutzlose SSE,SSE2 (3dNow! ist von dem befehlssatz noch OK, aber dafür nervt der registershare mit der fpu, auf die ich aber auch komplett verzichten könnte, wenn die SIMD vernünftig wäre)
1. Hat AMD beim A64 simuliert ob sich 32 GPR gelohnt hätten. Du darfst nicht vergessen dass der Befehlssatz dadurch auch größer wird und die Prozessoren intern eh viel mehr zur Verfügung haben.
2. SSE/SSE2 ist ziemlich nützlich.
3. SSE3 hat horizontale Instructions mit denen sich ein Dot Product schnell erledigen lässt.

[Gast]

Gehen wir mal weg vom Prozessor und hin zum Grafikchip.

Wie könnte heute ein NV40 mit "Physik-Extensions", OGL und SLI mal vorrausgesetzt, entsprechend eingesetzt werden?

"Wieviel" Physik kann der NV40 mal rein von den verbauten Einheiten her überhaupt? Gibt es überhaupt die Möglichkeit Grafikchipeinheiten mit Physik zu belästigen, sie zum "Fremdgehen" zu bewegen? Mit Audio geht es schon oder soll gehen habe ich mal gelesen?

SLI deshalb, da so, neben der theoretischen optimalen 50%igen Lastverteilung mal ohne AA/AF betrachtet, noch genuegend Leistung für andere Dinge, in diesem Fall "Physik", brachliegt.

Ob es Sinn macht oder nicht, einen Markt für entsprechende "Physik-Extensions" könnte ich mir vorstellen. Eine Quadro kostet ja auch nicht wegen eines komplett anderen Chips so viel mehr. Ein Großteil des Preises dürften auch die angepassten Treiber, neben dem natürlich obligatorischen Proffeschinälzuschlach, ausmachen.

So eine dedizierte PPU ist für PC vielleicht Käse, für Konsolen vielleicht in Hinblick auf HD-TV interessant?

[Coda]

"Physik" ist viel zu vielschichtig das man dedizierte Einheiten oder Extensions dafür bauen könnte.

Im Prinzip kann NV40 als general purpose Prozessor benützt werden, das Problem an der Sache ist nur das jeder Readback ziemlich üble Auswirkungen auf die Performance hat.

Das ganz lässt sich wohl erst gut einsetzen wenn der Grafikchip anhand von Daten selber Geometrie erzeugen kann (WGF 2.0)

[Gast]

Schade, dachte gerade OGL wäre für Physikaufgaben schon heute geeignet da jeder Hersteller da seine eigenen Süppchen kochen kann.

[Coda]

Ich weiß eh nicht was ihr habt, ich könnte mir keine Aufgabe vorstellen für das die CPU besser geeignet wäre als für die Physik.
Das ist keine Aufgabe für einen dedizierten Streamprozessor, genauso wie KI. Die Aufteilung die wir jetzt haben passt eigentlich ziemlich gut.

[Gast]

Rumspielen hat noch nie geschadet :)

Die massive Power von heutigen Karten ist für popelige Grafik eigentlich viel zu schade :)

Muss ja nicht was sein wo der Readback die kritische Komponente darstellt. Falls eine komplette Aufgabe in den Grafikspeicher passen würde, könnte die Power für die Aufgabe genutzt werden, das Ergebnis muss ja nicht unbedingt "sofort" vorliegen.

Nehmen wir mal SETI, könnte das, auf einer GPU ausgeführt, profitieren?

Und ja, selbst wenn die CPU für allen möglichen Krempel besser geeignet ist, einfach mal just for fun rumspielen ist nicht verboten. Der C64 wurde auch für alles mögliche missbraucht.

[Coda]

Die massive Power von heutigen Karten ist für popelige Grafik eigentlich viel zu schade
Die massive Power als Streamprozessor. Physik ist nunmal überhaupt nicht geradlinig, das ist ein recht schlechter Anwendungsfall für die GPU.

Nehmen wir mal SETI, könnte das, auf einer GPU ausgeführt, profitieren?
Gibt's eine SSE/SSE2 optimierte Version davon? Falls das zutrifft ja.

[huha]

SETI für GPUs wäre denkbar, da SETI immer nur die gleichen mathematischen Aufrufe benutzt und die selbe Rechnung immer und immer wieder wiederholt.

Mit Physik sieht's anders aus: Physik ist ziemlich vielschichtig und man kann's auf verschiedene Arten implementieren. Wenn man nur mal Kollisionsabfragen nimmt, sind ja etliche Möglichkeiten denkbar, wie das zu realisieren wäre.

Es wäre sicher ganz nett, bestimmte optische Spielereien der Physik auf die Graphikkarte auszulagern. Gerade Partikeleffekte oder sowas könnten eventuell von einer sehr schnellen Anbindung eines eigenen Effektprozessors, der die Physik dieser Partikel berechnet, an die GPU start profitieren. Allerdings sehe ich da keinen wirklichen Kauf- und Entwicklungsgrund, da durch sowas die Karte recht warm werden würde (wieder ein Hochleistungschip mehr, wieder muß mehr gekühlt werden etc.pp.) und zweitens niemand sowas braucht.

-huha

[Gast]

Branching kann da zB nicht abhelfen? Ich verlange ja nicht das Strömungsphysik oder Astrophysik und weiss der Geier noch alles berechnet werden kann. Für eher kleine "Probleme" und sei es nur aus Spass kann man eine GPU doch sicher benutzen.

Alleine schon die Möglichkeit eine GPU für Musik zu missbrauchen wäre normalerweise als unmöglich/bescheuert/Ressourcenverschwendung angesehen worden. Aber es geht anscheinend. Jetzt mal völlig unabhängig davon, das es keine komplizierten Sprünge, Readbacks oder sonstigen Kram gibt, wo die GPU nicht so flexibel wie eine CPU ist. Sowas zeigt doch, das da nicht nur gesagt wird, dass das entweder nur mit Soundchip oder eben CPU geht. Für umsonst und für die Katz entwickeln Leute sowas auch nicht.

Ich habe von programmieren null Plan aber soweit ich verstanden habe, können doch eben mit OGL durch die Techdemos von den Herstellern schon Sachen gezeigt werden, die vielleicht erst in ein paar Jahren in Spielen auftauchen. Klar, die Techdemos stellen natürlich kein komplettes Spiel dar. Aber, zB bei D3 verwendet Carmack ja nur einen Renderpfad für NV4x und R3xx/4xx. So, was wäre denn aber nun, neben reiner Beschleuningung, noch möglich an technischen Schmankerln und Spielereien möglich, die durch diesen "Universalpfad" halt gar nicht möglich sind?

Verstehe mich nicht falsch, ich möchte da jetzt keine Träumereien ausbreiten, aber die Hersteller bringen ja nun nicht umsonst Extensions die mehr können als der Standard OGL 1.5 (oder sind sie schon bei 2.0?). Ansonsten brauchen sie auch gar nichts zu bringen sondern einfach nur Speed, Speed, Speed.

[Coda]

OpenGL ist eine Grafik API und daran wird sich auch nix ändern.
Ich verstehe auch nicht was du für Sachen als Extensions haben willst, die Grafikkarte ist über Fragment und Vertexprogramme eh schon voll programmierbar.
Strömungsphysik ist übrigens z.B. etwas was sich ziemlich gut berechnen ließe.
Aber so Sachen wie fallende Boxen etc. sind nix für einen Streamprozessor.

[Gast]

Gut, nehmen wir mal die Audiogeschichte als gegeben an. Wie können die Audiodaten dann auf einer Grafikkarte laufen bzw berechnet werden?

Es muss also Software existieren, womit Audiodaten in Grafikkarten kompatible Daten umgewandelt worden sind. Was wenn diese Software so flexibel wäre, dass auch "andere" Daten, Programme oder wie immer sie bezeichnet werden könnten, in Grafikkartendaten umgewandelt werden können? Eben auch Sachen aus der Physik? Finde ich klasse das es anscheinend mehr als nur Grafik auf einer Grafikkarte geben kann.

Huha meint, SETI könnte auf einer Grafikkarte funktionieren. Gibt es so ein Programm schon? Wenn ja, geil, wo? Wenn nein, wer traut sich? :)
Du meinst, Strömungsphysik müsste gut funktionieren. So, da haben wir schon mal Physik. Allein schon die Erwähnung das es funktioniern könnte, müsste, sollte finde ich faszinierend. Schreib doch mal was. Just for fun falls es nicht zu umfangreich ist, keine Ahnung.

Wenn ich den Gedanken weiterspinne, wie könnte zB Strömungsphysik in Spiele einfliessen? Wieviel Power benötigt das?

Ok, ich war mit OpenGL auf dem falschen Dampfer. Da wollte ich aber noch was zu schreiben. Nicht mehr heute, müsste längst pennen.

Gute Nacht :)

[Vasco]

Brauch man dafür net einfach nur nen FPGA welches ein Approximationsverfahren wie Runge-Kutta oder Adams-Bashfort (statt einfachem Euler) in Hardware durchläuft?

Für Physik ist doch einfach nur numerische Vorwärtsintegration notwendig, oder nit?

Und zur Berechnung der Collision Response einfach nen massiv parallelen LGS Solver... o O


Just my 10ct,
Vasco

[Coda]

Gut, nehmen wir mal die Audiogeschichte als gegeben an. Wie können die Audiodaten dann auf einer Grafikkarte laufen bzw berechnet werden?Audioberechnungen sind ideal für einen Streamprozessor, das funktioniert gut auf einer Grafikkarte.

Es muss also Software existieren, womit Audiodaten in Grafikkarten kompatible Daten umgewandelt worden sind.Grafikkarte rechnen mit ganz normalen Floating Point Werten, da muss nicht viel umgewandelt werden.

Du meinst, Strömungsphysik müsste gut funktionieren. So, da haben wir schon mal Physik. Allein schon die Erwähnung das es funktioniern könnte, müsste, sollte finde ich faszinierend. Schreib doch mal was. Just for fun falls es nicht zu umfangreich ist, keine Ahnung.Ich wollte damit eigentlich nur klarstellen dass sowas wie "Physik Extensions" eher unwahrscheinlich sind. Die GPU ist so schon programmierbar. Entweder eine Aufgabe lässt sich gut darauf lösen (ohne Readback am besten) oder nicht.

[Trap]

Brauch man dafür net einfach nur nen FPGA welches ein Approximationsverfahren wie Runge-Kutta oder Adams-Bashfort (statt einfachem Euler) in Hardware durchläuft?

Für Physik ist doch einfach nur numerische Vorwärtsintegration notwendig, oder nit?

Und zur Berechnung der Collision Response einfach nen massiv parallelen LGS Solver... o O
Welches Integrationsverfahren man verwenden kann hängt davon ab was man simulieren will. Außerdem braucht man für die Integration Funktionswerte und es kann durchaus sein, das die Kosten für das Integrationsverfahren gegen die Kosten der Berechnung der Funktionswerte klein sind.

LGS solver könnte nützlich sein, hab aber keine Ahnung wieviel Zeit in der Physikberechnung für Lösung von LGS draufgeht. Wenn es nur 10% bringt es im Ergebnis nix, auch wenn die Hardware 1000 mal so schnell ist.

[Vasco]

LGS solver könnte nützlich sein, hab aber keine Ahnung wieviel Zeit in der Physikberechnung für Lösung von LGS draufgeht. Wenn es nur 10% bringt es im Ergebnis nix, auch wenn die Hardware 1000 mal so schnell ist.

Mit nem LGS Solver in HW könnte man auch die Berechnung der Formfaktoren bei der Radiosity durchführen.


Cheers,
Vasco

[Gast]

so eine durschnittliche berechnung von strömungssimulationen, die auch mehr oder weniger realistisch sein soll, dauert übrigens für so einen pc mit 2ghz und 2gb ram ca. einen halben tag...

[micki]

1. Hat AMD beim A64 simuliert ob sich 32 GPR gelohnt hätten. Du darfst nicht vergessen dass der Befehlssatz dadurch auch größer wird und die Prozessoren intern eh viel mehr zur Verfügung haben.
tja, andere prozis haben 32 und mehr und es lohnt sich auf jeden fall, aber es kommt auch immer auf den befehlssatz an, ist der zu starr, dann kann man mit vielen registern auch nichts an performance gewinnen, weil dinge wie z.b. shuffle zuviel overhead bringen


2. SSE/SSE2 ist ziemlich nützlich.
SEE ja, wenn mon SOA hat, aber das ist oft nicht der fall, wenn man nicht gerade extra daten anlegt dafür, was ja wieder overhead ist und man abwegen muss ob es am ende deswegen nicht sogar weniger performance gibt (immerhin doppelte daten oder dauernde umwandlung)



3. SSE3 hat horizontale Instructions mit denen sich ein Dot Product schnell erledigen lässt.
tja, und auch das ist nur ne scheinlösung, ein dot hat man deswegen trotzdem nicht und gerade für phsic und graphic ist das eine der gründlegensten funktionen die ein physic oder graphicproz haben muss.

MfG
micki

[Gabber[CH]]

Ich weiß eh nicht was ihr habt, ich könnte mir keine Aufgabe vorstellen für das die CPU besser geeignet wäre als für die Physik.

ACK.

Wieso man dafür die GPU's nehmen will leuchtet mir nicht ein, die ist doch voll auf den BildAufbau spezialisiert.

[Coda]

tja, andere prozis haben 32 und mehr und es lohnt sich auf jeden fall, aber es kommt auch immer auf den befehlssatz an, ist der zu starr, dann kann man mit vielen registern auch nichts an performance gewinnen, weil dinge wie z.b. shuffle zuviel overhead bringenEs hat sich eben nicht gelohnt, der Overhead hätten den Gewinn wettgemacht. Du vergisst die virtuellen Register.

tja, und auch das ist nur ne scheinlösung, ein dot hat man deswegen trotzdem nicht und gerade für phsic und graphic ist das eine der gründlegensten funktionen die ein physic oder graphicproz haben muss.Kennst du denn einen anderen Prozessor der eine dot Instruction hat?
Ich glaube das müsste eh per Microcode implementiert werden und würde nicht schneller sein als die SSE3 Sequenz.

[Hauwech]

Wie sieht eigentlich das Verhältnis Rechenleistung von FP zwischen CPU und GPU aus? Sagen wir mal Athlon64 2GHz und NV40 400MHz.

Allerdings frage ich mich, warum man für diese Audiogeschichte eine GPU bemüht wenn eine CPU es doch auch könnte. Spielerei oder ernshafte Anwendung? Irgendwelche Vorteile dadurch?

Wenn ich mir den Inside nvidia NV40 Artikel so durchlese und mal auf Seite 5 unter Vertexshader 3.0 auf den 3. Absatz verweisen darf, ist der Punkt Physikberechnungen auf einer GPU in Zukunft vielleicht ja doch nicht so aus der Luft gegriffen.

[Gast]

Die Physik kann auch immernoch gut die main CPU übernehmen.
Wenn diese in Zukunft noch schneller wird kann sie auch immer mehr physikalische Berechnungen durchführen und die Grafikkarte trotzdem auslasten.
Wenn die Grafikkarte alle Funktionen der CPU übernimmt ist sie ja bald fast unterfordert *fg*

Und apropos einfach... versucht ihr mal eine perfekte Physik zu simulieren wenn das Universum sich ausdehnt ;)

Greetz Masta

[zeckensack]

tja, und auch das ist nur ne scheinlösung, ein dot hat man deswegen trotzdem nicht und gerade für phsic und graphic ist das eine der gründlegensten funktionen die ein physic oder graphicproz haben muss.

MfG
mickiDann nimm halt 3DNow! :)
;Skalarprodukt zweier 4-float-Vektoren
MOVQ mm0,[a]
MOVQ mm1,[a+8]
PFMUL mm0,[b]
PFMUL mm1,[b+8]
PFACC mm0,mm1
PFACC mm0,mm0
MOVD [result],mm0Latenz 12 Takte ... ohne i/o ;(

Batch, batch, batch ...
;viele Skalarprodukte
;ESI:=Zeiger zu Vektoren-Array "links"
;EDI:=Zeiger zu Vektoren-Array "rechts"
;EDX:=Zeiger zum Ergebnis-Array
;ECX:=Größe der Arrays
MOV EBX,ECX
AND ECX,-4
JZ .no_loop
LEA ESI,[ESI+8*ECX]
LEA EDI,[EDI+8*ECX]
LEA EDX,[EDX+4*ECX]
NEG ECX
.loop_4:
MOVQ mm0,[ESI+8*ECX]
MOVQ mm1,[ESI+8*ECX+8]
MOVQ mm2,[ESI+8*ECX+16]
MOVQ mm3,[ESI+8*ECX+24]
PFMUL mm0,[EDI+8*ECX]
PFMUL mm1,[EDI+8*ECX+8]
PFMUL mm2,[EDI+8*ECX+16]
PFMUL mm3,[EDI+8*ECX+24]
MOVQ mm4,[ESI+8*ECX]
MOVQ mm5,[ESI+8*ECX+8]
MOVQ mm6,[ESI+8*ECX+16]
MOVQ mm7,[ESI+8*ECX+24]
PFMUL mm4,[EDI+8*ECX]
PFMUL mm5,[EDI+8*ECX+8]
PFACC mm0,mm1
PFACC mm2,mm3
PFMUL mm6,[EDI+8*ECX+16]
PFMUL mm7,[EDI+8*ECX+24]
PFACC mm4,mm5
PFACC mm5,mm6
PFACC mm0,mm2
PFACC mm4,mm6
MOVQ [EDX+4*ECX],mm0
MOVQ [EDX+4*ECX+8],mm4

ADD ECX,4
JNZ .loop_4
AND EBX,3
JZ .done
LEA ESI,[ESI+8*EBX]
LEA EDI,[EDI+8*EBX]
LEA EDX,[EDX+4*EBX]
NEG EBX
.loop_1:
MOVQ mm0,[ESI+8*EBX]
MOVQ mm1,[ESI+8*EBX+8]
PFMUL mm0,[EDI+8*EBX]
PFMUL mm1,[EDI+8*EBX+8]
PFACC mm0,mm1
PFACC mm0,mm0
MOVD [EDX+4*EBX],mm0
INC EBX
JNZ .loop_1
.done:20 Takte für vier, inklusive i/o. Fünf Takte pro Stück. 2,8GFlop/s @ 2,0GHz :tongue:

[diedl]

Wie sieht eigentlich das Verhältnis Rechenleistung von FP zwischen CPU und GPU aus? Sagen wir mal Athlon64 2GHz und NV40 400MHz.

Allerdings frage ich mich, warum man für diese Audiogeschichte eine GPU bemüht wenn eine CPU es doch auch könnte. Spielerei oder ernshafte Anwendung? Irgendwelche Vorteile dadurch?

Wenn ich mir den Inside nvidia NV40 Artikel so durchlese und mal auf Seite 5 unter Vertexshader 3.0 auf den 3. Absatz verweisen darf, ist der Punkt Physikberechnungen auf einer GPU in Zukunft vielleicht ja doch nicht so aus der Luft gegriffen.

Habe leider keine Ahnung ob, und wenn wie viel schneller eine GPU Audiodaten berechnen kann.
Aus der Praxis weis ich aber dass beim Rendern von midis in wave in einer
guten bis sehr guten Qualität, Rechenzeiten selbst auf einen flotten PC
von 1 zu 60 entstehen können. (1min Musik 60min Rechenzeit).
Wenn ich davon ausgehe das eine GPU diese Daten genauso viel
schneller berechnen kann wie Grafikdaten im Verhältnis zur CPU, ist dieser
Anwendungsbereich durchaus sinnvoll.

mfg diedl

[Avalox]

Es gibt doch Soundkarten mit vielen tausend Mips die so was übernehmen.
Wenn jemand fürs Signalprozessing die CPU rechnen lässt, ist es doch seine eigene Entscheidung seine CPU Rechenzeit halt dafür zu nutzen, schlechten Sound zu haben, aber dafür ein paar Euros für einen Soundcontroller zu sparen.
Viele Ansätze und Verfahren sind auch Patentrechtlich geschützt. Eine zusätzliche Hürde, da der typische Grafikkarten Hersteller nicht grade viel mit Soundprozessing bisher am Hut hat.

@Topic

Das mit dem Physik Prozessor finde ich allerdings interessant.
Der Gedanke knüpft ja an einer Art von 4D Beschleuniger. Also eine Hardwareunterstützung nicht nur um nette 3D Einzelbilder zu berechnen, sondern auch eine Hardwareunterstützung für die Animationsabläufe.
Es fehlt heute die Zeit, die Interaktion als Komponente.

[Avalox]

...

[Gast]

Es gibt doch Soundkarten mit vielen tausend Mips die so was übernehmen.
Wenn jemand fürs Signalprozessing die CPU rechnen lässt, ist es doch seine eigene Entscheidung seine CPU Rechenzeit halt dafür zu nutzen, schlechten Sound zu haben, aber dafür ein paar Euros für einen Soundcontroller zu sparen.
Viele Ansätze und Verfahren sind auch Patentrechtlich geschützt. Eine zusätzliche Hürde, da der typische Grafikkarten Hersteller nicht grade viel mit Soundprozessing bisher am Hut hat.

@Topic

Das mit dem Physik Prozessor finde ich allerdings interessant.
Der Gedanke knüpft ja an einer Art von 4D Beschleuniger. Also eine Hardwareunterstützung nicht nur um nette 3D Einzelbilder zu berechnen, sondern auch eine Hardwareunterstützung für die Animationsabläufe.
Es fehlt heute die Zeit, die Interaktion als Komponente.

Naja, solange der Grafikchiphersteller nur die Hardware zur Verfügung stellt die sich so universal verhält, dass darauf nicht nur Grafik ausgeführt werden kann, dann hat er doch mit Patenten, Lizenzen, Rechten aus anderen Gebieten, zB Audio, doch gar nichts am Hut solange er da selber nicht dran rumfummelt.

Hält sich eigentlich immer noch das Gerücht von einer nvidia Soundkarte? :D

Was hat Physik mit Zeit zu tun? Meines Wissens nach ist doch in keiner Physikformel die Zeit überhaupt drin. Hardwareunterstützung für Animationen hat doch mit Zeit gar nichts zu tun.

[Avalox]

Die Physik in einem Spiel dient nur einen Zweck. Diese soll eine Interaktion des Systems ermöglichen.

Da die einzige Schnittstelle des Systems zum Spieler die Grafikausgabe (Sound O.K.) ist, ist es also Ziel der simulierten Physik Bewegungsvektoren zu generieren.

Aus dem Bewegungsvektor lässt sich mit Hilfe der Zeit eine Basis für eine Animation erstellen.

Ohne Zeit keine Bewegung, ergo keine Animation.

[Coda]

Was hat Physik mit Zeit zu tun? Meines Wissens nach ist doch in keiner Physikformel die Zeit überhaupt drin.Schau mal in deine Physik Formelsammlung, falls du sowas hast.
Da hat ja wohl jede 3. Formel ein t drin ;-)

[Hauwech]

Hmm zumindest für Bereiche wie Distributed Computing und Programmen wie SETI oder Folding@Home? wäre die zusätzliche Nutzung der GPU doch gut.

Klar, ist mit Sicherheit einiger Aufwand, aber da steht zumindest ein vernünftiger Beweggrund hinter. Auch wenn das eigentlich nix mit Physik zu tun hat, interessant wäre es trotzdem und Schaden würde es auch keinen verursachen.

[diedl]

Es gibt doch Soundkarten mit vielen tausend Mips die so was übernehmen.
Wenn jemand fürs Signalprozessing die CPU rechnen lässt, ist es doch seine eigene Entscheidung seine CPU Rechenzeit halt dafür zu nutzen, schlechten Sound zu haben, aber dafür ein paar Euros für einen Soundcontroller zu sparen.
Viele Ansätze und Verfahren sind auch Patentrechtlich geschützt. Eine zusätzliche Hürde, da der typische Grafikkarten Hersteller nicht grade viel mit Soundprozessing bisher am Hut hat.



Meine Sprache war von Soundfiles in guter (für manche extreme Qualität).
Nenn mir mal eine (zumindest bezahlbare) Hardwaresoundlösung mit
unbegrenzter Polyphony, AA bis 200 und natürlich min. 24bit/96khz. :rolleyes:
Eine Grafikkarte hat dagegen jeder im PC. :wink:
Für "normale" Soundberechnungen reicht dagegen natürlich (meistens)
deine vorgeschlagene Soundkarte.

mfg diedl

[micki]

Es hat sich eben nicht gelohnt, der Overhead hätten den Gewinn wettgemacht. Du vergisst die virtuellen Register.

tja, schade dass es das in der x86 nicht lohnt und woanders schon.


Kennst du denn einen anderen Prozessor der eine dot Instruction hat?
Ich glaube das müsste eh per Microcode implementiert werden und würde nicht schneller sein als die SSE3 Sequenz.
der xbox2 soll es können(????)
und jede gpu kann es ;)

[micki]

Dann nimm halt 3DNow! :)
Latenz 12 Takte ... ohne i/o ;(

nein danke, das register gekotze vergessen wir mal lieber, für lange optimierte berechnungen ist es vielleicht ok, aber wenn mal eben ein dot möchte ohne wegen irgendwelchem overhead...


Batch, batch, batch ...
viele Skalarprodukte

wie gesagt, ist nervig.
stell dir vor man hätte bei der einführung der fpu gesagt, dass sie fließkomma zahlen kann, aber keine umwandlung von int->float und reverse davon. und dazu muss man dann noch das vorzeichen als ein flag einladen und dabei natürlich xor-en.

so krank find ich das zur zeit, intel und co brauche SIMD prozzis für irgendwelche atomtest usw. und nennen es multimediablablub damit wir normalos es kaufen, damit es sich wirtschaftlicher fährt, aber grundlegende, wirklich nützliche befehle sind nicht drinne.

für 3d gibt es nunmal dinge wie :
dot, cross, mat*mat (oder zumindestens transponieren wenn dot vorhanden ist), was ewig viel berechnungen kostet. ganz zu schweigen vom transponieren. auf ner gpu (ja ich weiß, ganz andere architektur) bekommt man das normalisieren von nem vector in einem takt geschenkt, wie lange hängen wir dafür mit SSE?

dazu kommt, dass SSE vielleicht 4muls gleichzeitig durchdrücken kann, abr soweit ich weiß, hat der athlon(opteronklasse) nur 2mul-werke? das ist irgendwie suboptimal?

und wie ewig lange hat es gedauert bis die es geschaft haben eine fpu instruktion einzubauen um c++ konform float->int machen zu können?

die arbeiten einfach an den bedürfnissen vorbei. Jedenfalls an meinen :D, es hätte viel länger gedauert bis sich T&L und vertexshader durchsetzen können, wenn die fpu (und ihre extensions) vernünftig gemacht worden wären finde ich.

MfG
micki

[Gast]

Man, man, jeder drittklassige Taschenrechner rechnet heute mit 3-Variablen,
also wenn ein Flugzeig im Spiel abstürzt, kann ich an Hand momentaner Geschwindigkeit, Flugwinkel, Fallbeschleunigung, Luftwiderstand etc. unter Berücksichtigung der Zeit, die Parabel errechnen wo das Flugzeug (incl. mir ;) ) einschlägt. Das macht jede CPU, ohne auch nur warm zu werden.
Jeder Spieleprogrammierer wird abgenervt abwinken
==> mehr Entwicklungszeit, mehr Bugs. Ich könnte mir auch keinen Chiphersteller vorstellen, der solch eine Fehlinvestition finanziert.

kaki

[Gabber[CH]]

Meines Wissens nach ist doch in keiner Physikformel die Zeit überhaupt drin.
:ulol3:

z.B. : s=int(v,t)
oder a = dv/dt

[SentinelBorg]

Oder der Klassiker: v = s * t :P

Sentinel

[Legolas]

Oder der Klassiker: v = s * t :P

Sentinel

es heißt aber v = s / t :)

[SentinelBorg]

ups, äh... tippfehler :D

[Coda]

tja, schade dass es das in der x86 nicht lohnt und woanders schon.Das liegt nicht an x86, sondern an der Tatsache das Register Renaming sehr erfolgreich zu sein scheint und die Codevergrößerung eher einen gegenteiligen Effekt hätte.
Es ist eigentlich inzwischen völlig egal wie der Code vor dem Decoder aussieht, später ist es so oder so RISC ähnlich.
x86 ist sicherlich nicht die Bremse für die es manche halten.

der xbox2 soll es können(????)
und jede gpu kann es Die XBox 2 CPU ist ein PowerPC, der hat auch keine DOT Instruction.
Und GPUs haben eine deutlich tiefere Pipeline, das kann man überhaupt nicht vergleichen.