PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Direct3D 10 als allgemeine API für SIMD Prozessoren?


Demirug
2006-07-02, 22:25:49
Das für Direct3D 10 verwendete ShaderModel 4 wurde ja bekanntermaßen noch einmal kräftig erweitert. Durch ungefilterte Speicherzugriffe, Integer Berechnungen, größere Programmlängen wird es dadurch auch für GPGPU Anwendungen interessanter. Dazu gehören Berechnungen im Bereich der Physik aber auch Neuronale Netzwerke für eine KI wären denkbar.

Nun werden Spieler die über ein Quad CPUs, Multi GPU, PPU System verfügen aber nicht unbedingt darüber glücklich sein wenn ein Spiel einseitig alles zu den GPUs schaufelt.

Hätte man nun allerdings entsprechenden D3D10 Treiber für die PPU und die CPU Cores (Dank SSE ja in gewiesser Weiße auch SIMD Prozessoren) könnte man einzelne SIMD Jobs die nicht zwingend etwas mit Grafik zu tun haben viel besser verteilen ohne für jede Art von Prozessor neuen Code schreiben zu müssen.

BlackBirdSR
2006-07-02, 22:33:31
Demirug[/POST]']Das für Direct3D 10 verwendete ShaderModel 4 wurde ja bekanntermaßen noch einmal kräftig erweitert. Durch ungefilterte Speicherzugriffe, Integer Berechnungen, größere Programmlängen wird es dadurch auch für GPGPU Anwendungen interessanter. Dazu gehören Berechnungen im Bereich der Physik aber auch Neuronale Netzwerke für eine KI wären denkbar.

Nun werden Spieler die über ein Quad CPUs, Multi GPU, PPU System verfügen aber nicht unbedingt darüber glücklich sein wenn ein Spiel einseitig alles zu den GPUs schaufelt.

Hätte man nun allerdings entsprechenden D3D10 Treiber für die PPU und die CPU Cores (Dank SSE ja in gewiesser Weiße auch SIMD Prozessoren) könnte man einzelne SIMD Jobs die nicht zwingend etwas mit Grafik zu tun haben viel besser verteilen ohne für jede Art von Prozessor neuen Code schreiben zu müssen.

Beinhaltet das also auch Coprozessoren dir man an einen K8 anbindet?
Solange man einen D3D 10 Treiber dafür hat, versteht sich.

Demirug
2006-07-02, 22:36:23
BlackBirdSR[/POST]']Beinhaltet das also auch Coprozessoren dir man an einen K8 anbindet?
Solange man einen D3D 10 Treiber dafür hat, versteht sich.

Klar die Idee würde auch dafür funktionieren. Wenn jemand einen passenden Treiber schreibt könnte man auch diese teuren ClearSpeed Karten nutzen oder auch einen Cell.

BlackBirdSR
2006-07-02, 22:38:05
Demirug[/POST]']Klar die Idee würde auch dafür funktionieren. Wenn jemand einen passenden Treiber schreibt könnte man auch diese teuren ClearSpeed Karten nutzen oder auch einen Cell.

Ich sehe teure Zeiten auf uns zukommen :/

Da wir uns im "könnte, hätte, würde" bereich bewegen... wie realisitisch ist dieses Szenario der frei verteilten SIMD-Resourcen?

Demirug
2006-07-02, 22:45:23
BlackBirdSR[/POST]']Ich sehe teure Zeiten auf uns zukommen :/

Da wir uns im "könnte, hätte, würde" bereich bewegen... wie realisitisch ist dieses Szenario der frei verteilten SIMD-Resourcen?

D3D10 unterstützt „headless Adapter“. Auf Nachfrage wurde mir bestätigt das Microsoft zum einen an der Verwendung von D3D10 als API für SIMD Aufgaben und zum anderen auch an Treibern für nicht GPU Chips interessiert ist. Das Thema D3D10 für CPU Cores kam dabei nicht zur Sprache aber dafür braucht man Microsoft sowieso nicht.

paul.muad.dib
2006-07-02, 22:50:35
BlackBirdSR[/POST]']Ich sehe teure Zeiten auf uns zukommen :/

Da wir uns im "könnte, hätte, würde" bereich bewegen... wie realisitisch ist dieses Szenario der frei verteilten SIMD-Resourcen?

Ohne dass ich jetzt viel von der Materie verstehe, sehe ich hiern doch eher die Schwelle zum professionellen Bereich überschritten. Falls MS hier Interesse hätte, hier mit DX10 bzw. D3D10 mitzumischen - und damit evtl. Unix Workstations auszubooten, wäre das wohl hierzu eine interessante Angelegenheit.

Für Privatanwender und Spiele wird das wohl erstmal nicht realisierbar sein, weil die Schere zu den Konsolen doch nicht zu weit aufgehen sollte und die Kosten solcher Rechenleistung in keinem Verhältnis mehr zum Nutzen stünden.

RoKo
2006-07-03, 00:28:09
Jo, die Idee kommt mir bekannt vor. Ich hatte mir gedacht, man nehme einfach Brook mit verschiedenen Backends (gibt's ja schon, inklusive D3D9 und OGL) und fertig. Bräuchte man nur noch Zugriff auf die PPU, um dafür ein Backend schreiben zu können. Aber nein, darf man ja aus markttechnischen Gründen nicht.

Demirug
2006-07-03, 08:09:04
Hinter Brook dürfte derzeit leider nicht genügend Druck stehen. Da viele Entwickler aber sowieso D3D10 nutzen werden sehe ich hier die Möglichkeit das ein gewisser Druck auf Ageia entstehen könnte.

RoKo
2006-07-03, 19:16:57
Ja, Ageia muß mal jemand ganz fest drücken ;)
Ein bißchen problematisch wäre das mit D3D10 doch aber schon, da dann einiges Zeugs implementiert werden muß, was es abseits eines Grafikchips nicht gibt und dann nur den Programmierer stört - Sampler, Rasterisierung, überhaupt die Unterschiede zwischen VS, GS und PS und was mir sonst noch gerade alles nicht einfällt. Bräuchte man doch eigentlich eine Art abgespeckte D3D10-Api oder zumindest eine entsprechende Treiber-Api. Oder hat man bei der Unterstützung für headless-Adapter schon so weit gedacht?

Demirug
2006-07-03, 19:26:40
Implementieren muß man es eigentlich schon komplett. Wobei das gar nicht mal so hektisch ist. Der Würfel (http://gpu-fun.spaces.msn.com/blog/cns!FB5EEACE075E1350!115.entry) aus dem SDK Tutorial 04 dreht sich bei mir schon.

Für GPGPU Anwendungen wird man aber wohl häufig nur den Vertex Shader und die StreamOut Funktion nutzen. Im Prinzip könnte man also für solche Anwendungen durchaus auch nur ein Subset implementieren.

RoKo
2006-07-03, 20:03:12
Eben. Einfach ein Subset von D3D10 als DirectPhysics bezeichnen und fertig ;)
Dein Blog ist aber lustig. 2.7.: First post 3.7.: Finally I have something to show. :D Darfst Du mir übernächstes Wochenende mal vorführen. Das ist dann also ein virtueller Headless-D3D10-Treiber, was Du da machst? Und wirklich mit "Shader JIT"? Ich sehe gerade gar nicht, wie man da just in time kompilieren soll, gibt doch ein explizites D3D10CompileShader (wo ich gerade D3D10_SUPER_MARIO statt D3D10_SHADER_MACRO gelesen habe :hammer: ).

Demirug
2006-07-03, 20:10:14
Ich weiß noch nicht ob ich das Vista fähige Notebook mitnehmen kann. Zeigen kann man aufgrund der Geschwindigkeit sowieso kaum etwas.

Einen echten Treiber kann ich im Moment noch nicht schreiben weil das WDK nicht auf dem gleichen Stand wie die Vista Version ist. Aktuell habe ich einfach die entsprechenden D3D10 Objekte und Interfaces implementiert.

D3D10CompileShader übersetzt in einen Bytecode. Jiten bedeutet dann aus diesem Bytecode SSE Anweisungen zu machen. Im Moment nutze ich aber noch einen Interpreter.

RoKo
2006-07-03, 20:33:58
Ahso. Ich dachte, CompileShader wird vom Treiber implementiert und übersetzt gleich in irgendwas natives, eidiweil das ja auch aus D3DX zu D3D gewandert ist. Aber dann kann man doch immer noch ganz normal in CreateIrgendwasShader kompilieren. Worauf ich hinaus will, die ganze Problematik eines JIT-Compilers, die ihn von einem normalen Compiler unterscheidet (Codeblöcke cachen, bei einer Jump-Instruktion den neuen Block kompilieren,...) ist doch da nicht nötig und man kann einfach alles was reinkommt komplett kompilieren, oder?

Demirug
2006-07-03, 20:39:39
RoKo[/POST]']Ahso. Ich dachte, CompileShader wird vom Treiber implementiert und übersetzt gleich in irgendwas natives, eidiweil das ja auch aus D3DX zu D3D gewandert ist. Aber dann kann man doch immer noch ganz normal in CreateIrgendwasShader kompilieren.

Die Idee dem Treiber direkt HLSL zu servieren wurde allgemein nicht sehr wohlwollend aufgenommen. Deswegen immer noch Bytecode.

RoKo[/POST]']Worauf ich hinaus will, die ganze Problematik eines JIT-Compilers, die ihn von einem normalen Compiler unterscheidet (Codeblöcke cachen, bei einer Jump-Instruktion den neuen Block kompilieren,...) ist doch da nicht nötig und man kann einfach alles was reinkommt komplett kompilieren, oder?

Ich habe das ganze jetzt als JIT bezeichnet weil die einzelnen Shaderprogramme ja erst zur Laufzeit in SSE Anweisungen übersetzt werden. Natürlich wird man sinnvoller weiße immer einen ganzen Shader am Stück übersetzten. JITer übersetzten in der Regel ja auch immer ganze Funktionen.