WGF 2.0 Stand: WinHEC 2005

[Demirug]

Windows Graphics Foundation 2.0

http://img3.picsplace.to/img3/2013/thumbs/WGF2.PNG (http://img3.picsplace.to/img3/2013/WGF2.PNG)

Supported in Longhorn
-Proposed Gold Logo requirement

Major improvements in Hardware consistency
-Clearest, most detailed specification
-Elimination of capability bits

Programmer expressiveness
-Unified shader programming model
-More capable shader unit
-Flexible memory model
-New pipeline stages

LDDM + WGF 2.0 are fundamental improvement to the Windows Gaming Platform

Performance improvements
-Applications limited by state change performance
-LDDM helps by eliminating extra processing
-WGF 2.0 refactors state for efficient management

Enable GPU processing without CPU intervention
-More flexible memory model
-Stream output from middle of pipeline
-Feedback to front of pipeline, with predication

Efficiency improvements
-Multiple samples from textures, integer addressing
-Compact surface formats (scenario-specific): HDR, normal map compression, ...
-Arrayed resources

Geometry shader stage
-"Sees" entire primitive (3 vertices of triangle)
-Can have adjacent vertices too (6 vertices total)

Limited amplification
-Extrude edges, expand points, generate shells, ...

Per-primitive processing
-Generate extra per-primitive constant data for pixel shaders
-Constant colors, normals, etc
-Compute plane equations, barycentric parameters, etc.

Combine with stream output or arrayed resources
-Render to cube map
-Render multiple shadow maps

Interesant ist das nur noch von einem "Unified shader programming model" gesprochen wird. Vor einem Jahr waren es noch "Unified shader". mit dem Zusatz Load Balencing. Scheinbar fordert MS dieses Detail nicht mehr explizit.

Die Fähigkeiten des "Geometry shader" werden hier nun etwas genauer ausgeführt. Scheinbar lässt er sich nicht als Ersatz für den ersatzloss gestrichenen Tesselator einsetzten. Allerdings könnte der "Feedback to front of pipeline, with predication" da helfen.

Aus Sicht der Spielekompatibilität dürfte die Aussage "Elimination of capability bits" wichtig sein. Damit wäre sichergestellt das ein Spiel auf jeder WGF 2.0 Karte gleich aussieht. Kein Ärger mehr wegen Shadermodelen und Co.

[Ailuros]

Interesant ist das nur noch von einem "Unified shader programming model" gesprochen wird. Vor einem Jahr waren es noch "Unified shader". mit dem Zusatz Load Balencing. Scheinbar fordert MS dieses Detail nicht mehr explizit.

Verstehe ich das jetzt falsch, oder ist die Implementierung dem IHV ueberlassen? Die alte Definition klingt nach einer Vorraussetzung von vereinten Einheiten, waehrend mir die neue eher danach klingt dass es egal ist ob die Einheiten getrennt sind oder nicht, solange die Architektur mit einem vereinigten shader Programmierungs-Modell zurecht kommt. :confused:

Die Fähigkeiten des "Geometry shader" werden hier nun etwas genauer ausgeführt. Scheinbar lässt er sich nicht als Ersatz für den ersatzloss gestrichenen Tesselator einsetzten. Allerdings könnte der "Feedback to front of pipeline, with predication" da helfen.

Zaehlt "per primitive processing" da auch noch dazu oder ist das total irrelevant? Wie sieht es eigentlich genau mit geometry texturing aus? Ausser ich hab Dich falsch verstanden ist Latenz fuer vertex texturing kein Kopfschmerz mehr bei "unified shaders". GS klingt mir aber als getrennte Einheit; wenn ja wird da jeglicher "Texturen-Zugriff" des GS nicht auch etwas Latenz mit sich bringen?

Bitte die dummen Laien-Fragen zu entschuldigen ;)

[mapel110]

Aus Sicht der Spielekompatibilität dürfte die Aussage "Elimination of capability bits" wichtig sein. Damit wäre sichergestellt das ein Spiel auf jeder WGF 2.0 Karte gleich aussieht. Kein Ärger mehr wegen Shadermodelen und Co.

Wie wollen sich die IHV dann noch voneinader abgrenzen?! Nurnoch AA, AF und LOD-Spielereien?! =(
Bleibt dann nurnoch Opengl um was zu zeigen, was andere nicht können?! Bin ja gespannt, wie das wird.
/edit
hm, dann machen ATI-Smartshadereffekte wohl wieder Sinn *scnr*

[Demirug]

Verstehe ich das jetzt falsch, oder ist die Implementierung dem IHV ueberlassen? Die alte Definition klingt nach einer Vorraussetzung von vereinten Einheiten, waehrend mir die neue eher danach klingt dass es egal ist ob die Einheiten getrennt sind oder nicht, solange die Architektur mit einem vereinigten shader Programmierungs-Modell zurecht kommt. :confused:

Ja, es sieht so aus als könnte man es implementieren wie man möchte. Wahrscheinlich hat sich ein IHV quergestellt.

Zaehlt "per primitive processing" da auch noch dazu oder ist das total irrelevant? Wie sieht es eigentlich genau mit geometry texturing aus? Ausser ich hab Dich falsch verstanden ist Latenz fuer vertex texturing kein Kopfschmerz mehr bei "unified shaders". GS klingt mir aber als getrennte Einheit; wenn ja wird da jeglicher "Texturen-Zugriff" des GS nicht auch etwas Latenz mit sich bringen?

Bitte die dummen Laien-Fragen zu entschuldigen ;)

Per Primitive Processing ist eine Fähigkeit des Geometry Shaders.

Die Latenzen beim Texturezugriff sind ja implementierungsabhängig. Da nun scheinbar jeder selber entscheiden kann was er macht können alle 3 Shadertypen einzelne physikalische Einheiten sein oder man wirft alles zu einem Pool zusammen. Mit Latenzen muss man aber immer rechnen weil zum Beispiel der Speicher nicht immer nachkommt.

[Demirug]

Wie wollen sich die IHV dann noch voneinader abgrenzen?! Nurnoch AA, AF und LOD-Spielereien?! =(
Bleibt dann nurnoch Opengl um was zu zeigen, was andere nicht können?! Bin ja gespannt, wie das wird.
/edit
hm, dann machen ATI-Smartshadereffekte wohl wieder Sinn *scnr*

Wie grenzen sich den AMD und Intel voneinander ab? Bei den CPUs muß man sich ja auch an das "Featureset" halten wenn man mal die SSE Sache aussen vor lässt.

[robbitop]

Ja, es sieht so aus als könnte man es implementieren wie man möchte. Wahrscheinlich hat sich ein IHV quergestellt.



Das deutete sich ja schon leicht an, als B3D beide IHV's mal zu Unified Shadern befragte.
Warum strich man die Tesslationseinheit?
Somit verschiebt sich dieses tolle Feature mal wieder ewig.

[Coda]

Was kann der Geometry Shader eigentlich? Und wieso ist er nach dem Vertex Shader?

Oh, es steht ja drin. Er "sieht" das ganze Dreieck...
Fragt sich für was das so dringend benötigt wird?

[Demirug]

Das deutete sich ja schon leicht an, als B3D beide IHV's mal zu Unified Shadern befragte.
Warum strich man die Tesslationseinheit?
Somit verschiebt sich dieses tolle Feature mal wieder ewig.

Das Problem mit der Tesslationseinheit war wohl schon damals das nicht jeder mitmachen wollte. Das hat sich aber nun mit dem Wunsch "No more Caps" nicht vertragen. IMHO wäre das Teil sowieso nicht benutzt worden wenn es eine Option gewesen wäre.

[Neomi]

Oh, es steht ja drin. Er "sieht" das ganze Dreieck...
Fragt sich für was das so dringend benötigt wird?

Da gibt es verschiedene Möglichkeiten.

- Wenn man die Vertices eines Dreiecks einen Pixel (im Screenspace logischerweise) nach außen schiebt und alles mit konstanter Farbe zeichnet, kann man nachher ein (nicht transparentes) Objekt normal drüberzeichnen und hat eine Umrandung von einem Pixel breite. Das geht zwar auch jetzt schon mit ein paar Tricks, aber eben nicht in der Performance.

- Wenn man die fehlenden Vertices der Dreiecke, die mit dem aktuellen eine Kante teilen, mit hinzunimmt, kann man sehr gut Kanten finden. Für Cellshading kann das ein recht großer Vorteil sein.

- Effekte pro Dreieck werden viel einfacher möglich. Ein Editor z.B., der selektierte Dreiecke eingefärbt zeichnen will, muß jetzt entweder in einem zweiten Pass transparente, einfarbige Dreieckt drüberzeichnen oder die betroffenen Dreiecke mit einem zusätzlichen Drawcall zeichnen. Eine weitere Möglichkeit ist, Daten per Vertex mitzugeben und die Vertices, die von selektierten und unselektierten Dreiecken genutzt werden, doppelt abzulegen. Das könnte simpler werden.

Das sind erstmal die Dinge, die mir konkret einfallen. Es gibt bestimmt noch andere interessante Einsatzmöglichkeiten.

[Demirug]

Was kann der Geometry Shader eigentlich? Und wieso ist er nach dem Vertex Shader?

Oh, es steht ja drin. Er "sieht" das ganze Dreieck...
Fragt sich für was das so dringend benötigt wird?

Wenn ich es richtig verstanden habe kann man damit Schattenvolumen effektiv in der GPU rechnen lassen. Zudem soll er auch etwas mit der Fähigkeit eine Cubemap in einem Zug zu rendern zu tun haben.

[mapel110]

Wie grenzen sich den AMD und Intel voneinander ab? Bei den CPUs muß man sich ja auch an das "Featureset" halten wenn man mal die SSE Sache aussen vor lässt.
Quasi nur durch Performance?! Aber da gibts doch das Problem, dass die IHV praktisch vom verfügbarem Speicher abhängig sind. Da ist nicht viel Spielraum, was Performance angeht.

[Demirug]

Quasi nur durch Performance?! Aber da gibts doch das Problem, dass die IHV praktisch vom verfügbarem Speicher abhängig sind. Da ist nicht viel Spielraum, was Performance angeht.

Wenn das Featureset mal fest ist kann man ja die Pipelines auf Leistung trimmen. Da in Zukunft die Rechenleistung immer wichtiger wird sehe ich da durchaus einiges an Spielraum.

[robbitop]

Das Problem mit der Tesslationseinheit war wohl schon damals das nicht jeder mitmachen wollte. Das hat sich aber nun mit dem Wunsch "No more Caps" nicht vertragen. IMHO wäre das Teil sowieso nicht benutzt worden wenn es eine Option gewesen wäre.
Ist es denn denkbar, dass dies mittelfristig mal in die Spec kommt (WGF3??)? Denn Jahre lang sah es so aus, als bekämen wir endlich Tesslation.

[Coda]

Fragt sich ob wir das durch Dual Core und Co. überhaupt noch brauchen?

[Ailuros]

Die Latenzen beim Texturezugriff sind ja implementierungsabhängig. Da nun scheinbar jeder selber entscheiden kann was er macht können alle 3 Shadertypen einzelne physikalische Einheiten sein oder man wirft alles zu einem Pool zusammen. Mit Latenzen muss man aber immer rechnen weil zum Beispiel der Speicher nicht immer nachkommt.

Waere ein "Shader-Pool" der aus PS/VS/GS besteht aber eine ideale Loesung?Ich hab irgendwie den Eindruck dass IHVs die auf vereinte Architekturen zuerst setzen werden, den GS wohl doch getrennt implementieren werden. Wenn ja gibt es irgend einen besonderen Grund dafuer?

[robbitop]

Fragt sich ob wir das durch Dual Core und Co. überhaupt noch brauchen?
Eine CPU ist ziemlich lahm in Sachen Tesslation ggü einer dedizierten Einheit AFAIK.
Wenn Tesslation zwingend in der WGF Spec wäre, würde es sicher auch mal genutzt werden (ich sehne das seit dem NV30 herbei [ursprünglich sollte er das ja schon können]).

[robbitop]

Waere ein "Shader-Pool" der aus PS/VS/GS besteht aber eine ideale Loesung?Ich hab irgendwie den Eindruck dass IHVs die auf vereinte Architekturen zuerst setzen werden, den GS wohl doch getrennt implementieren werden. Wenn ja gibt es irgend einen besonderen Grund dafuer?
Aber bevor das passiert, scheinen sie die Shader noch getrennt realisieren zu dürfen (ich nehme an, NV hat sich da quergestellt...das Gefühl hab ich seit dem B3D Interview).

Wäre es denkbar, dass NV CineFX WGF2 compliant bekommt? Hauptsächlich müsste ein Geometrieshader hinein und die Fähigkeit unendlich lange Instruktionen auszuführen, oder sehe ich das falsch?

[Gast]

Wie sieht das eigentlich aus, wenn Entwickler Wünsche ggü den IHvs äussern? Können die dann überhaupt irgendwie berücksichtigt werden? Was passiert, wenn zB dieser Physik Prozessor ein Erfolg wird, müssen da eventuell Aufrufe oder sowas umgeleitet werden? Dieser RayTracing Chips der auf der CeBit vorgestellt wurde, der scheint ja ziemlich gut zu sein und es besteht zumindest von Nvidia Interesse an dem wenn ich mich recht erinnere. Wenn Nvidia den benutzen will, was passiert dann bei WGF?

Sorry für die vielen teils spekulativen Fragen aber rein neben mehr Takt, schnelleren Speicher und mehr Recheneinheiten klingt das alles für mich ein bisschen schon zu absolut, also als wenn sich da in den nächsten Jahren nicht mehr viel tun wird irgendwie.

[Demirug]

Physik Processor = neue API
RayTracing Chip = neue API (OpenRT)

WGF ist und bleibt für GPUs. Abhängig davon wie WGF 2.0 dann entgültig aussehen wird brauchen wir für die nächsten Jahre auch keine neue API mehr.

[Chris Lux]

Physik Processor = neue API
RayTracing Chip = neue API (OpenRT)

WGF ist und bleibt für GPUs. Abhängig davon wie WGF 2.0 dann entgültig aussehen wird brauchen wir für die nächsten Jahre auch keine neue API mehr.

*hust* OpenGL *hust*

ogl mag zwar stellenweise veraltet sein, aber denoch sehe ich keine not für eine neue API ;) und WGF sehe ich nur im game markt ausschlaggebend!

aber zurück zum thema. hat jemand eine idee, was der stream buffer nach dem gp beinhalten kann? wie ich das sehe soll ja der speicherbereich in dem bild allgemein nutzbar sein (superbuffers lassen grüßen), dies würde bedeuten, dass man den inhalt des streambuffers wieder nutzen kann als eingabe für den gp. doch da kommen mir andere fragen: welchen nutzen hat der gp wirklich, ausser für die shadowvolume erzeugung, denn er wird ja sicher auch nach dem 1:1 stream prinzip funktionieren. also was kann man damit machen? ich denk mal vertexattribute ändern äbhängig von adjazenten (sp) ist zwar möglich, bringt aber wieder ein konsistenzproblem mit sich... also mal ehrlich was soll dieser gp eigentlich? den tri setup macht er nicht programmierbar, den rasterizer auch nich...

[Coda]

Wäre es denkbar, dass NV CineFX WGF2 compliant bekommt? Hauptsächlich müsste ein Geometrieshader hinein und die Fähigkeit unendlich lange Instruktionen auszuführen, oder sehe ich das falsch?Wäre sehr gut denkbar. Unendlich lange ausführen kann NV40 eh, das ist nur eine Limitation von DX9.

[Ailuros]

Wäre sehr gut denkbar. Unendlich lange ausführen kann NV40 eh, das ist nur eine Limitation von DX9.

Unified shaders oder nicht, koennte es nicht auch sein dass sich auch NVIDIA quasi vom "quad-Konzept" loest in zukuenftigen Generationen? Falls sich seit der Zeit vom "DX-Next" auch nichts im I/O Modell geaendert hat, hab ich das Gefuehl dass da auch noch extra Logik dazukommen muss.

Selbst wenn das was ich gerade hier aufreihe nur Quark ist, bezweifle ich dass es sich nur um kleinere Aenderungen handeln koennte so in der Art NV40+GS. Bei einer hypothetischen WGF2.0 Architektur wo es noch getrennte PS/VS gibt, hab ich es so verstanden dass der Datenstrom durch den geometrie shader die pixel sowie auch die vertex shader beinflusst.

[robbitop]

Warum eine völlig neue Architektur schaffen, wenn CineFX noch immer genügt? MS verlangt keine Unified Shader mehr. Ich schätze, dass man den Datenstrom vom GS auf beide Shader schon umlegen könnte.

Ist jetzt aber auch nur ein Gedankengang von mir.

[Demirug]

Ein GS hat ganz andere Anforderungen. Das Teil liegt auf der Ebene des Trisetups.

Ich würde mich auch nicht so sehr an dem Festklammern was Kirk gesagt hat. Er hat ja lediglich gesagt was sowieso jeder schon wusste. Allerdings hat er nichts dazu gesagt wie das die weitere Entwicklung beeinflusst. Wenn man bei nVidia immer die spezialisierten Einheiten den allgemeinen vorgezogen hätte gäbe es in deren Chips heute noch keinen Shader.

Ich vermute mal eher das sich Intel quergestellt hat was die Unified shader angeht.

[Ailuros]

Ein GS hat ganz andere Anforderungen. Das Teil liegt auf der Ebene des Trisetups.

Ich würde mich auch nicht so sehr an dem Festklammern was Kirk gesagt hat. Er hat ja lediglich gesagt was sowieso jeder schon wusste. Allerdings hat er nichts dazu gesagt wie das die weitere Entwicklung beeinflusst. Wenn man bei nVidia immer die spezialisierten Einheiten den allgemeinen vorgezogen hätte gäbe es in deren Chips heute noch keinen Shader.

Ich vermute mal eher das sich Intel quergestellt hat was die Unified shader angeht.


Kann sein; ein weiterer aber um einiges weniger bedeutender IHV der vielleicht nicht auf vereinte Einheiten gezwungen werden wollte koennte auch PowerVR sein (unter der Vorraussetzung dass sie ueberhaupt eine Stimme haben). Ich hab zwar weder eine Ahnung ob sie ueberhaupt noch fuer den PC weiterentwickeln bzw. forschen oder ob vereinte Shader in einer theoretischen Roadmap der Firma stehen koennte. Nach deren Aussagen der Vergangenheit haben sie dank TBDR vereinte Einheiten nicht unbedingt noetig.

Mal ein anderer Gedanke: waere es nicht moeglich theoretisch den GS und VS zu vereinigen und PS immer noch getrennt zu halten? So eine These wuerde mich bei NVIDIA auch nicht unbedingt wundern; Basis-Unterstuetzung eben fuer den Anfang und Leistung dann erst spaeter. Oder ist das eher Quark?

***edit: ganz so nebenbei irgendwo Ende 2002 wurde ich von einem engineer indirekt gewarnt mit der Hoffnung fuer volle PPPs vorsichtig zu sein was DX-Next betraf. Die genaue Aussage war in etwa dass es doch wohl etwas an "Programmierbarkeit" fehlen wird. Koennte sein dass er damals die Streichung der Tesselations-Einheit andeutete. Ich fragte warum es so weit gekommen waere und er sagte dass den IHVs der Platz zu knapp wird fuer zukuenftige Designs.

[Demirug]

Bei einem TBDR sehe ich eigentlich mehr Vorteile den Nachteile durch vereinte Einheiten.

GS und VS würden sich wohl zusammenfassen lassen.

Die Tesselationseinheit in DX-Next war scheinbar wirklich als fixed Einheit vorgesehen. nVidia hat mal angedeutet das sie keine neuen Fixed Einheiten mehr einbauen wollen. Die Begründung war das man am Ende doch nicht das getan hat was die Entwickler wollen und man damit dann unnötig Transitoren verschwendet hat.

[Ailuros]

Bei einem TBDR sehe ich eigentlich mehr Vorteile den Nachteile durch vereinte Einheiten.

Kurze Erklaerung vielleicht fuer den Laien?

GS und VS würden sich wohl zusammenfassen lassen.

Koennte aber einen "lahmen" GS bedeuten?

Die Tesselationseinheit in DX-Next war scheinbar wirklich als fixed Einheit vorgesehen. nVidia hat mal angedeutet das sie keine neuen Fixed Einheiten mehr einbauen wollen. Die Begründung war das man am Ende doch nicht das getan hat was die Entwickler wollen und man damit dann unnötig Transitoren verschwendet hat.

Das klingt dann schon eher nach einer genauen Deutung von dem was ich damals las. Und eine "fixed-function" Tesselations-Einheit klingt auch verdaechtig nach ATI.

Komischerweise hatte ich den Eindruck dass auch die Tesselations-Einheit programmierbar war und dass man das ganze entweder durch einen Topologie-Prozessor (ie GS) und einer Tesselations-Einheit oder einem "universalem" PPP haette loesen koennen.

[Gast]

kann es der api nicht eigentlich egal sein ob die hardware einheitliche shader-einheiten besitzt oder nicht?

im prinzip übergibt die api dem treiber doch nur die shaderprogramme. wie, und vor allem auf welchen hardware-recheneinheiten dann gerechnet wird kann der api doch egal sein oder nicht?

[Demirug]

Ein TBDR könnte mit vereinten Shadern die Recheleistung dann immer dem Teil zuschieben der gerade mehr braucht. Also dem Binning State oder dem Pixelprocessing. Dadurch könnte man in einem ersten Schritt auch alles fürs Binning nutzen um dann im zweiten Schritt alle Einheiten dem Pixelprocessing zuzuordenen.

Die nVidia Vertexshader sollten technisch gesehen nach ein paar kleinen erweiterungen auch gute GS abgeben. Allerdings würde man dann dort auf jeden Fall einen Scheduler brauchen der die rechenwerke dann jeweils einem Primtives oder einem Vertex zuweist.

Wie gesagt die Tesselationseinheit war bei der DX-Next Geschichte immer etwas schwammig formuliert.

Der reinen API könnte die Implementierung egal sein. Allerdings ist WGF keine reine API Spec sondern stellt weitergehenden Forderungen vorallem im Bereich der Geschwindigkeit.

[Coda]

Ist schon bekannt wieviel Texturen man verwenden kann pro Pass? Weil für geordnete Transparenz wäre es ja z.B. ganz hilfreich nicht die ganze Zeit die Texturen wechseln zu müssen :rolleyes:

[Demirug]

Ist schon bekannt wieviel Texturen man verwenden kann pro Pass? Weil für geordnete Transparenz wäre es ja z.B. ganz hilfreich nicht die ganze Zeit die Texturen wechseln zu müssen :rolleyes:

Wenn die alte Forderung noch gültig ist: Unendlich. Der Treiber muss sich darum kümmern das es funktioniert.

Ich erwarte dann aber Devguides von den IHVs in denen dann steht wie viele Texturen man höchstens pro Pass nutzen soll.

[Gast]

Wg. Geometry Shader. Nach meinen Infos kann das Ding tatsächlich unter anderem drei wichtige Dinge:

- Tris löschen. Soll sehr schnell gehen.
- Neue Tris einfügen. Geht, ist aber relativ langsam.
- Tris duplizieren und an verschiedene RenderTargets schicken. Dazu wird ein Array of RenderTargets definiert, die jeweils vom GS mit __verschiedenen__ Tris gefüttert werden, bzw. wird ein Tri auf 3 von 6 Targets geschickt. Dadurch kann eine komplette Cubemap in nur einem Pass aufbauen. Das gibt gute Shadowmaps für Pointlights!

[Ailuros]

Wg. Geometry Shader. Nach meinen Infos kann das Ding tatsächlich unter anderem drei wichtige Dinge:

- Tris löschen. Soll sehr schnell gehen.
- Neue Tris einfügen. Geht, ist aber relativ langsam.
- Tris duplizieren und an verschiedene RenderTargets schicken. Dazu wird ein Array of RenderTargets definiert, die jeweils vom GS mit __verschiedenen__ Tris gefüttert werden, bzw. wird ein Tri auf 3 von 6 Targets geschickt. Dadurch kann eine komplette Cubemap in nur einem Pass aufbauen. Das gibt gute Shadowmaps für Pointlights!

Waere "2" aber nicht eher abhaengig von der Implementierung?

[Xmas]

Der reinen API könnte die Implementierung egal sein. Allerdings ist WGF keine reine API Spec sondern stellt weitergehenden Forderungen vorallem im Bereich der Geschwindigkeit.
Warum sollte Geschwindigkeit bei getrennten Shadern ein Problem sein?

[Demirug]

Warum sollte Geschwindigkeit bei getrennten Shadern ein Problem sein?

Wenn die Forderungen so ausgelegt sind das dabei davon ausgegangen wird das die gesamte Rechenleistung einem Shadertype zugeordnet werden könnte das durchaus zum Problem werden. Wenn die Tests für Vertexprocessing und Pixelprocessing getrennt laufen muss bei unified Shadern ja eine höhere Leistung erwartet werden als bei getrenten.

[Coda]

Wg. Geometry Shader. Nach meinen Infos kann das Ding tatsächlich unter anderem drei wichtige Dinge:

- Tris löschen. Soll sehr schnell gehen.
- Neue Tris einfügen. Geht, ist aber relativ langsam.
- Tris duplizieren und an verschiedene RenderTargets schicken. Dazu wird ein Array of RenderTargets definiert, die jeweils vom GS mit __verschiedenen__ Tris gefüttert werden, bzw. wird ein Tri auf 3 von 6 Targets geschickt. Dadurch kann eine komplette Cubemap in nur einem Pass aufbauen. Das gibt gute Shadowmaps für Pointlights!So wie es da steht kann das Ding eigentlich nur abhängig von den Daten des ganzen Primitives andere Konstanten setzen für die Pixelshader. Aber ich lasse mich gerne vom Gegenteil überzeugen.

[Chris Lux]

So wie es da steht kann das Ding eigentlich nur abhängig von den Daten des ganzen Primitives andere Konstanten setzen für die Pixelshader. Aber ich lasse mich gerne vom Gegenteil überzeugen.
sag ich ja. aber aus dem einen bild kann man nicht viel raus interpretieren. ich warte lieber bis die IHVs ihre ideen genauer ausbreiten und hoffe immer noch auf einen PPP.

[Coda]

Wieso die IHVs? Microsoft hat das sagen bzgl. der WGF 2.0 Specs. Die Vendors können zwar eine Tesselationseinheit einbauen, nur wird die dann nur unter OpenGL funktionieren.

Die Spec dürfte inzwischen ziemlich final sein, weil ja die Chipdesigns von den Grundzügen schon lange fertig sein müssen.

[Chris Lux]

Wieso die IHVs? Microsoft hat das sagen bzgl. der WGF 2.0 Specs. Die Vendors können zwar eine Tesselationseinheit einbauen, nur wird die dann nur unter OpenGL funktionieren.

Die Spec dürfte inzwischen ziemlich final sein, weil ja die Chipdesigns von den Grundzügen schon lange fertig sein müssen.
wie ich das so sehe ist WGF2.0 dann eher eine technologiebremse (keine unified shader, kein ppp) und von den letzten versprechen was radikales design (speicherverwaltung...) angeht sehe ich auch nichts mehr, ist viel zu konventionell geworden (wieder rein von dem bild zu schliessen). ich meine mit meiner aussage, dass die IHVs hoffentlich die initiative übernehmen und MS wieder zwingen nachzulegen in ihrer spec (WGF3.0? ;)). so aber reitzt mich recht wenig an WGF2.0.

[robbitop]

wie ich das so sehe ist WGF2.0 dann eher eine technologiebremse (keine unified shader, kein ppp) und von den letzten versprechen was radikales design (speicherverwaltung...) angeht sehe ich auch nichts mehr, ist viel zu konventionell geworden (wieder rein von dem bild zu schliessen). ich meine mit meiner aussage, dass die IHVs hoffentlich die initiative übernehmen und MS wieder zwingen nachzulegen in ihrer spec (WGF3.0? ;)). so aber reitzt mich recht wenig an WGF2.0.
Die IHV's sind doch daran "schuld", wie WGF2 nun aussieht.

[Coda]

keine unified shaderUnified Shader ändern an der API rein gar nichts. Das Konzept hätte man auch schon bei DX9 einsetzen können.

[mapel110]

http://forums.guru3d.com/showthread.php?s=&threadid=136813
Extreme minimum requirements:
1.6 GHz processor
512 MB memory
64 MB videocard
7200 RPM HD 16 MB cache

For the full experience:
4 GHz processor
3 GB memory
1 GB videocard with WFG 2.0 support
15000 RPM HD 1 GB flash memory
:uconf3: :uhammer:

/edit
werd mir den thread dort morgen mal genauer anschauen, aber irgendwie sieht das jetzt schon aus wie ... :|

[Gast]

[url]
/edit
werd mir den thread dort morgen mal genauer anschauen, aber irgendwie sieht das jetzt schon aus wie ... :|
... Technischer Overkill ;)

[Ailuros]

http://forums.guru3d.com/showthread.php?s=&threadid=136813
Extreme minimum requirements:
1.6 GHz processor
512 MB memory
64 MB videocard
7200 RPM HD 16 MB cache

For the full experience:
4 GHz processor
3 GB memory
1 GB videocard with WFG 2.0 support
15000 RPM HD 1 GB flash memory
:uconf3: :uhammer:

/edit
werd mir den thread dort morgen mal genauer anschauen, aber irgendwie sieht das jetzt schon aus wie ... :|

That's where I got a lot of my information.

http://forums.guru3d.com/showthread.php?threadid=136813&perpage=10&highlight=&pagenumber=9

Uebersetzung: "I have a very vivid imagination and I dunno WTF I'm talking about yadda yadda...."

Aus dem extremetech Artikel woraus der ganze Quatsch originieren soll:

So what kind of graphics hardware will you need? The primary driver in graphics performance requirements is desktop composition. Microsoft recommends that you have DirectX 9.0c capable hardware. The minimum support for Aero is 64MB, though 128MB is recommended, and 256MB for 16x12 with full Aero Glass effects.

Wo zum Henker steht hier was von 1GB framebuffer auf GPUs?

Moment ich glaube ich hab's....

Under the hood, the Aero Glass user interface will require 2GB/sec texture update bandwidth, which equates to two HDTV streams running on a pair of 16x12 screens at 60 frames per second.

....four different graphic modes for Longhorn (2GB/256MB/128MB/64MB textures)....


http://www.extremetech.com/article2/0,1558,1791670,00.asp

*seufz* :|

[aths]

Aus Sicht der Spielekompatibilität dürfte die Aussage "Elimination of capability bits" wichtig sein. Damit wäre sichergestellt das ein Spiel auf jeder WGF 2.0 Karte gleich aussieht.Wird für das AF etwa eine Formel und Mindestpräzision angegeben?

[Demirug]

Wird für das AF etwa eine Formel und Mindestpräzision angegeben?

Es gibt noch keinen Draft und auf solche Nebensächlichkeiten (nicht falsch verstehen) geht man bei Presentationen nicht ein.

[Demirug]

http://forums.guru3d.com/showthread.php?s=&threadid=136813
Extreme minimum requirements:
1.6 GHz processor
512 MB memory
64 MB videocard
7200 RPM HD 16 MB cache

For the full experience:
4 GHz processor
3 GB memory
1 GB videocard with WFG 2.0 support
15000 RPM HD 1 GB flash memory
:uconf3: :uhammer:

/edit
werd mir den thread dort morgen mal genauer anschauen, aber irgendwie sieht das jetzt schon aus wie ... :|

Was sich die leute so alles aus den Fingern saugen wenn ihnen langweilig ist.

[Leonidas]

Wie wollen sich die IHV dann noch voneinader abgrenzen?! Nurnoch AA, AF und LOD-Spielereien?! =(




Ist doch aber bei Shader 3.0 nicht anders.

[robbitop]

Ist doch aber bei Shader 3.0 nicht anders.
Man könnte doch nach Bedarf noch eine Tesslationseinheit einsetzen.

[Ailuros]

Man könnte doch nach Bedarf noch eine Tesslationseinheit einsetzen.

Wenn ich mich nicht irre wird solches Zeug bei Xenon auf dessen CPU ausgefuehrt.

[robbitop]

Wenn ich mich nicht irre wird solches Zeug bei Xenon auf dessen CPU ausgefuehrt.
Hui, das wird sicher performant ;)

[mapel110]

Ist doch aber bei Shader 3.0 nicht anders.
Naja, HDR (Float dingens ...) ist zum Beispiel nicht zwigend notwendig für einen SM3-Chip, 3DC auch nicht. :)

[Ailuros]

Hui, das wird sicher performant ;)

http://arstechnica.com/articles/paedia/cpu/xbox360-1.ars

PS3 wird vielleicht auch so manchen Schnickschnack mit Cell anrichten koennen.

Irgendwie hab ich das Gefuehl dass sich IHVs fuer solche Aufgaben eher an die sehr starken CPUs der Zukunft verlassen haben. "Langsam" duerfte die oben beschriebene Loesung sicher nicht sein; obwohl es natuerlich besser auf der GPU aufgehoben waere, im Idealfall auf einem vollbluetigen PPP.

[robbitop]

http://arstechnica.com/articles/paedia/cpu/xbox360-1.ars

PS3 wird vielleicht auch so manchen Schnickschnack mit Cell anrichten koennen.

Irgendwie hab ich das Gefuehl dass sich IHVs fuer solche Aufgaben eher an die sehr starken CPUs der Zukunft verlassen haben. "Langsam" duerfte die oben beschriebene Loesung sicher nicht sein; obwohl es natuerlich besser auf der GPU aufgehoben waere, im Idealfall auf einem vollbluetigen PPP.

Cells Vektor Units sind IMO deutlich performanter für Physics und Tesslation nutzbar als eine gewöhnliche CPU. Allerdings ist die Umsetzung sicher nicht leicht.

[Ailuros]

Cells Vektor Units sind IMO deutlich performanter für Physics und Tesslation nutzbar als eine gewöhnliche CPU. Allerdings ist die Umsetzung sicher nicht leicht.

Als eine gewoehliche CPU sicher, aber offensichtlich nicht schneller als wenn man die Tesselation auf der GPU ausfuehren wuerde.

[Gast]

Windows Graphics Foundation 2.0

http://img3.picsplace.to/img3/2013/thumbs/WGF2.PNG (http://img3.picsplace.to/img3/2013/WGF2.PNG)

Supported in Longhorn
-Proposed Gold Logo requirement

Major improvements in Hardware consistency
-Clearest, most detailed specification
-Elimination of capability bits

Programmer expressiveness
-Unified shader programming model
-More capable shader unit
-Flexible memory model
-New pipeline stages

LDDM + WGF 2.0 are fundamental improvement to the Windows Gaming Platform

Performance improvements
-Applications limited by state change performance
-LDDM helps by eliminating extra processing
-WGF 2.0 refactors state for efficient management

Enable GPU processing without CPU intervention
-More flexible memory model
-Stream output from middle of pipeline
-Feedback to front of pipeline, with predication

Efficiency improvements
-Multiple samples from textures, integer addressing
-Compact surface formats (scenario-specific): HDR, normal map compression, ...
-Arrayed resources

Geometry shader stage
-"Sees" entire primitive (3 vertices of triangle)
-Can have adjacent vertices too (6 vertices total)

Limited amplification
-Extrude edges, expand points, generate shells, ...

Per-primitive processing
-Generate extra per-primitive constant data for pixel shaders
-Constant colors, normals, etc
-Compute plane equations, barycentric parameters, etc.

Combine with stream output or arrayed resources
-Render to cube map
-Render multiple shadow maps

Interesant ist das nur noch von einem "Unified shader programming model" gesprochen wird. Vor einem Jahr waren es noch "Unified shader". mit dem Zusatz Load Balencing. Scheinbar fordert MS dieses Detail nicht mehr explizit.

Die Fähigkeiten des "Geometry shader" werden hier nun etwas genauer ausgeführt. Scheinbar lässt er sich nicht als Ersatz für den ersatzloss gestrichenen Tesselator einsetzten. Allerdings könnte der "Feedback to front of pipeline, with predication" da helfen.

Aus Sicht der Spielekompatibilität dürfte die Aussage "Elimination of capability bits" wichtig sein. Damit wäre sichergestellt das ein Spiel auf jeder WGF 2.0 Karte gleich aussieht. Kein Ärger mehr wegen Shadermodelen und Co.

ist ja nun alles fachchinesisch ,kann mal jemand bsp geben was man dann erwarten kann ?

wird sich an der optik der games viel tun,endlich gute texturen und kein matsch mehr ?
alle games mit dynamischer schatten/licht berechnung ohne große verluste ?

kann man beim AA/AF was erwarten

legt halt mal los

[Coda]

Hochaufgelöste Texturen, AA und AF haben so gut wie nichts mit der API zu tun.