Archiv verlassen und diese Seite im Standarddesign anzeigen : WGF Chips = Stream + X Prozessoren?
Demirug
2004-11-05, 20:12:48
Die Anforderungen für WGF Chips sind ja bekanntermassen sehr hoch. Ein Stream Prozessor könnte aufgrund seiner freien Programierbarkeit diese relative leicht erfüllen. Allerdings haben Versuche gezeigt das ein Stream Prozessor einer GPU stellenweise unterlegen ist (zum Teil aber auch überlegen). Nun könnte man die Schwächen des Streamprozessor aber durch zusätzliche Schaltkreise aus dem GPU Bereich ausgleichen. Zum einen die ALUs mit Zusatzfunktionen wie eine TMU ausstatten (Texturefilterung ist eine der grossen Schwächen von Stream Prozessoren) zum anderen bestimmte Kernels (Ein Programm wird bei Stream Prozessor als Kernel bezeichnet) als feste Funktion hinterlegen. Zum Beispiel einen Rasterisierer Kernel.
Hier wird sich kaum eine sinnvolle Diskussion ergeben können, weil du so ziemlich der einzige sein dürftest der die WGF Spezifikation schonmal gesehen hat :rolleyes:
Heißt das ganze man könnet auch einen Raytracer mittels WGF realisieren?
Demirug
2004-11-05, 20:24:39
Hier wird sich kaum eine sinnvolle Diskussion ergeben können, weil du so ziemlich der einzige sein dürftest der die WGF Spezifikation schonmal gesehen hat :rolleyes:
Heißt das ganze man könnet auch einen Raytracer mittels WGF realisieren?
Die entgültige Spec habe ich auch noch nicht gesehen. Es gibt aber eine gute Übersicht: http://download.microsoft.com/download/1/8/f/18f8cee2-0b64-41f2-893d-a6f2295b40c8/TW04079_WINHEC2004.ppt
Sehe ich richtig; die ganzen Altlasten werde mitgeschleppt?
GDI, DX7-9 in WGF?
Vielleicht auch in anderen Bereichen -> Kein Wunder, dass Longhorn so groß wird.
Wäre es nicht praktisch, Altlasten zu deaktivieren und bei Bedarf zu aktivieren?
Demirug
2004-11-05, 22:05:55
Sehe ich richtig; die ganzen Altlasten werde mitgeschleppt?
GDI, DX7-9 in WGF?
Vielleicht auch in anderen Bereichen -> Kein Wunder, dass Longhorn so groß wird.
Wäre es nicht praktisch, Altlasten zu deaktivieren und bei Bedarf zu aktivieren?
Kompatibilität muss sein. Es wäre ja blöd wenn die alten Spiele mit Longhorn plötzlich nicht mehr laufen würden.
WGF und D3D sind aber streng getrennt. Eine D3D Anwendung wird keine Teile von WGF laden und umgekehrt.
Was ich noch nicht ganz verstehe sind Aussagen wie "Previous fixed-function is re-cast as programmable where possible". Heißt das, aus FF T&L wird ein Vertexshader (bzw. in WGF einfach Shader) gemacht?
Exxtreme
2004-11-05, 23:00:03
Interessant finde ich, daß die Grafikkarten-Treiber im Usermode laufen werden. Unter Unix/Linux ist das schon seit vielen Jahren üblich. Vorteil ist, daß wenn der Grafikkarten-Treiber absemmelt, daß dann nicht die ganze Kiste freezt. Leider ist der Usermode deutlich langsamer als der Kernelmode. ;(
Also ich hab mir WGF bisher so vorgestellt dass man sich praktisch wieder den Rasterizer selber schreiben muss. Ist das richtig?
Ok, nach dem Paper sind die Änderungen doch weniger Umfangreich als ich dachte. Naja man kann ja auch mal träumen ;)
Demirug
2004-11-06, 11:02:04
Was ich noch nicht ganz verstehe sind Aussagen wie "Previous fixed-function is re-cast as programmable where possible". Heißt das, aus FF T&L wird ein Vertexshader (bzw. in WGF einfach Shader) gemacht?
Das bezieht sich auf die DX Kompatibilität von Longhorn. Die DX-Runtime wird einfach wenn man FF HT&L nutz das in einen Shader umsetzten bevor es zum Treiber geht. Im Moment machen das die Treiber selbst.
Demirug
2004-11-06, 11:06:27
Also ich hab mir WGF bisher so vorgestellt dass man sich praktisch wieder den Rasterizer selber schreiben muss. Ist das richtig?
Ok, nach dem Paper sind die Änderungen doch weniger Umfangreich als ich dachte. Naja man kann ja auch mal träumen ;)
Warum sollte man einen Rasterizerer selbst schreiben wollen? Theoretisch sollte man sowas machen können. Allerdings würde dieser nicht die gleiche Leistung wie der normale erreichen.
WGF ist primär immer noch eine 3D API. Allerdings sollte sich Brook sehr gut auf der WGF Basis implementieren lassen.
Demirug
2004-11-06, 11:08:34
Interessant finde ich, daß die Grafikkarten-Treiber im Usermode laufen werden. Unter Unix/Linux ist das schon seit vielen Jahren üblich. Vorteil ist, daß wenn der Grafikkarten-Treiber absemmelt, daß dann nicht die ganze Kiste freezt. Leider ist der Usermode deutlich langsamer als der Kernelmode. ;(
Bei DX wird die neue Usermode Variante schneller als die alte Kernelmode Version sein.
Kompatibilität muss sein. Es wäre ja blöd wenn die alten Spiele mit Longhorn plötzlich nicht mehr laufen würden.
WGF und D3D sind aber streng getrennt. Eine D3D Anwendung wird keine Teile von WGF laden und umgekehrt.
Dennoch wäre es praktisch, wenn man GDI und DX deaktivieren bzw. später ganz entfernen kann.
Die Frage ist, ob man aus den rund 2 GB vom Longhorn ein Longhorn Lite draus machen kann.
Demirug
2004-11-08, 07:34:37
Dennoch wäre es praktisch, wenn man GDI und DX deaktivieren bzw. später ganz entfernen kann.
Die Frage ist, ob man aus den rund 2 GB vom Longhorn ein Longhorn Lite draus machen kann.
Primär belegen diese Dinge ja erst mal nur Platz auf der Festplatte bis sie von einem Programm benötigt werden. Bei Longhorn wird DX aber sehr früh benötigt weil der neue Window-Manager DX benutzt. Jede aktuelle Applikationen braucht zudem das GDI.
Juerg
2004-11-08, 09:06:25
Interessant finde ich, daß die Grafikkarten-Treiber im Usermode laufen werden. Unter Unix/Linux ist das schon seit vielen Jahren üblich. Vorteil ist, daß wenn der Grafikkarten-Treiber absemmelt, daß dann nicht die ganze Kiste freezt. Leider ist der Usermode deutlich langsamer als der Kernelmode. ;(Mal was Historisches: ;) Bis und mit NT 3.51 (also bis 1995) ist der Grafikkartentreiber im User Mode "gelaufen". Wurde aus Performancegründen dann mit NT 4.0 in den Kernelmodus geschoben. Gab eine "Riesen"-Aufschrei vonn wegen geopferte Stabilität für Kompat. und Perf. usw. usw.
Wenn er jetzt wieder dorthin geht woher er kommt dann kann das als sehr vernünftig betrachtet werden.
Gohan
2004-11-08, 09:20:15
Kompatibilität muss sein. Es wäre ja blöd wenn die alten Spiele mit Longhorn plötzlich nicht mehr laufen würden.
WGF und D3D sind aber streng getrennt. Eine D3D Anwendung wird keine Teile von WGF laden und umgekehrt.
Das sehe ich nicht so. Als Apple von OS9 zu OS X gewechselt ist, liefen 100% der third Party Software nur über emulation.
Microsoft wagt diesen Schritt seit nun mehr als 10 Jahren nicht und schleppt unheimlich viele Altlasten mit sich mit, die u.A. auch für die vielen Sicherheitslücken und Mängel verantwortlich sind, weile immer auf eine gewisse Rückwärtskompatibilität geachtet werden muss. Ein richtiger Technologie-Fortschritt findet somit nicht statt.
Just my two cents.
Für den Benutzer ist es angenehmer, wenn die "Emulation" integriert ist. Für D3D < 9 werden Longhorn Wrapper auf D3D9 beiliegen - sowas ist klein und stört nicht. Die ideale Lösung meiner Meinung nach. Man braucht das auch nur einmal zu programmieren, dann hat man keine Sorgen mehr damit.
OSX basiert übrigens auf einem Unix, das ist echt mal eine Altlast ;)
marco42
2004-11-08, 13:34:06
Ok, Microsoft schafft es auf OpenGL 1.2 zu updaten? Und was heisst necessary extensions? multitexturing? was sind eigentlich streams? ich habe da mal was in zusammenhang mit dem Direct3D gegenstueck zu VBO's gehoert. Also, so viel stand da fuer mich nicht drin, klang eher nach marketing.
Demirug
2004-11-10, 13:59:18
Das sehe ich nicht so. Als Apple von OS9 zu OS X gewechselt ist, liefen 100% der third Party Software nur über emulation.
Microsoft wagt diesen Schritt seit nun mehr als 10 Jahren nicht und schleppt unheimlich viele Altlasten mit sich mit, die u.A. auch für die vielen Sicherheitslücken und Mängel verantwortlich sind, weile immer auf eine gewisse Rückwärtskompatibilität geachtet werden muss. Ein richtiger Technologie-Fortschritt findet somit nicht statt.
Just my two cents.
Die primäre neue API für Longhorn ist WinFX. Die gesamte Win32 API liegt aber weiterhin bei und ist zum Teil wirklich nur Emulation. Nur warum sollte man Win32 Funktionen die sowieso direkt auf Kernelfunktionen zugreifen erst nochmal über WinFX umleiten?
Windows (NT) war ja sowieso schon immer als OS ausgelegt das mehr als nur eine API/Platform gleichzeitig hosten kann.
Demirug
2004-11-10, 14:02:12
Ok, Microsoft schafft es auf OpenGL 1.2 zu updaten? Und was heisst necessary extensions? multitexturing? was sind eigentlich streams? ich habe da mal was in zusammenhang mit dem Direct3D gegenstueck zu VBO's gehoert. Also, so viel stand da fuer mich nicht drin, klang eher nach marketing.
Was du meinst sind Vertexstreams die es bei D3D. Das ist im Prinzip nicht mehr als das ein kompelter Vertex aus Daten welche in unterschiedlichen Speicherbereichen liegen zusammen gesetzt werden kann. Für GI braucht man das auch.
Ein Streamprozessor ist aber wieder was anders. Dazu schreibe ich dann aber später noch was ausführlicheres.
Die Anforderungen für WGF Chips sind ja bekanntermassen sehr hoch. Ein Stream Prozessor könnte aufgrund seiner freien Programierbarkeit diese relative leicht erfüllen. Allerdings haben Versuche gezeigt das ein Stream Prozessor einer GPU stellenweise unterlegen ist (zum Teil aber auch überlegen). Nun könnte man die Schwächen des Streamprozessor aber durch zusätzliche Schaltkreise aus dem GPU Bereich ausgleichen. Zum einen die ALUs mit Zusatzfunktionen wie eine TMU ausstatten (Texturefilterung ist eine der grossen Schwächen von Stream Prozessoren) zum anderen bestimmte Kernels (Ein Programm wird bei Stream Prozessor als Kernel bezeichnet) als feste Funktion hinterlegen. Zum Beispiel einen Rasterisierer Kernel.
Um auf Deine Aussage zu kommen. Gibt es irgendwo benches davon?
Die jetzigen GPUs sind doch auch eher Stream-Prozessoren.
Du meinst eher Stream-Prozessoren in Form von DSPs, oder?
Demirug
2004-11-10, 17:50:36
Um auf Deine Aussage zu kommen. Gibt es irgendwo benches davon?
Die jetzigen GPUs sind doch auch eher Stream-Prozessoren.
Du meinst eher Stream-Prozessoren in Form von DSPs, oder?
Richtige Benches gibt es nicht. In Stanford hat man damit aber mal experimentiert.
Der VS und der PS sind Streamprozessoren allerdings mit vielen Begrenzungen. DSPs gehen durchaus auch in die richtig stream prozessor. Allerdings sind DSPs in der Defintion ja schon sehr spezialisiert.
Hier gibt es ein aktueller Artikel über GPU:
http://www.ece.ucdavis.edu/~jowens/talks/owens-hpec04-gpgpu.pdf
marco42
2004-11-12, 01:17:54
Richtige Benches gibt es nicht. In Stanford hat man damit aber mal experimentiert.
Der VS und der PS sind Streamprozessoren allerdings mit vielen Begrenzungen. DSPs gehen durchaus auch in die richtig stream prozessor. Allerdings sind DSPs in der Defintion ja schon sehr spezialisiert.
meinst du pixelflow? ich habe dazu nie ein paper durchgelesen. sie haben nach, dem was ich mal in einer zusammenfassung gelesen habe, wirklich eine sehr interessante architectur gehabt. bloss war das nicht stanford.
Demirug
2004-11-12, 07:39:19
Pixelflow ist ein "normaler" Rasterisiere. Das Design weicht zwar von dem heute üblichen ab aber es bleibt trotzdem Spezialhardware.
Echte Stream Prozessoren sind Imagine (http://cva.stanford.edu/imagine/) oder der neue Merrimac (http://merrimac.stanford.edu)
marco42
2004-11-12, 14:06:50
Pixelflow ist ein "normaler" Rasterisiere. Das Design weicht zwar von dem heute üblichen ab aber es bleibt trotzdem Spezialhardware.
Echte Stream Prozessoren sind Imagine (http://cva.stanford.edu/imagine/) oder der neue Merrimac (http://merrimac.stanford.edu)
Hmm, sieht so aus, als ob image based rendering sehr gut unterstuetzt.
Pixelflow ist ein "normaler" Rasterisiere. Das Design weicht zwar von dem heute üblichen ab aber es bleibt trotzdem Spezialhardware.
Echte Stream Prozessoren sind Imagine (http://cva.stanford.edu/imagine/) oder der neue Merrimac (http://merrimac.stanford.edu)
Wenn ich mir das Blockschaltbild von Imagine anschaue, dann sieht es ungefähr so aus wie bei einer GPU von Nvida oder ATI:
http://cva.stanford.edu/imagine/images/imagine_block.gif
Nur die Komponenten sind leicht anders angeordnet.
Daten Imagine:
>10 GFlops
10 Watt Verbrauch
0,15 µm Prozess
21 Mio Transistoren
16x16 mm
Bandbreite:
http://cva.stanford.edu/imagine/images/bandwidth_hierarchy.gif
Performance von Imagine:
http://cva.stanford.edu/imagine/project/im_perf.html
MPeg2 Encoding: "320x288 24-bit color at 287 fps"
Wenn ich mir das ganze anschaue, dann schaut es so aus, als ob man die Grafik-Hardware modifiziert hat, um es mehr einzusetzen.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.