Was gibts mit D3D10 für neue Effekte, die eine X1900 nicht kann?

[sd]

Wird man mit einer X1900 zb bei Crysis alle Effekte darstellen können ?

2.Frage siehe Topic.

Danke.

[Rente]

sd[/POST]']Wird man mit einer X1900 zb bei Crysis alle Effekte darstellen können ?

2.Frage siehe Topic.

Danke. 1. Es gibt kein DirectX 10, nur Direct3D10 und zwar für Windows Vista
2. Nein, nicht in der angekündigten Vista-Version, zumindestens wenn man den Aussagen der Entwickler Glauben schenken darf
3. Es wird zuerst nur eine DX9-Version (mit D3D9) von CrySis geben, da sollte eine X1900 alle Effekte darstellen können

Btw. kommen mit D3D10 überhaupt neue Möglichkeiten Effekte zu erzeugen dazu?

[AnarchX]

Ob-1[/POST]']
Btw. kommen mit D3D10 überhaupt neue Möglichkeiten Effekte zu erzeugen dazu?

Geometry-Shader... ;)

[Rente]

AnarchX[/POST]']Geometry-Shader... ;) Danke für die Hilfe. ;)
Eine ganz interessante Präsentation was bei D3D10 neu sein wird: http://download.microsoft.com/download/5/b/9/5b97017b-e28a-4bae-ba48-174cf47d23cd/PRI022_WH06.ppt

[Gast]

AnarchX[/POST]']Geometry-Shader... ;)

Wie und das wars schon ?

[Rente]

Gast[/POST]']Wie und das wars schon ? Die Hauptbestandteile sind laut der Präsentation massive Vereinfachungen, Vereinheitlichungen und Beschleunigungen, zumindestens habe ich das so verstanden.

[Monger]

Ob-1[/POST]']Die Hauptbestandteile sind laut der Präsentation massive Vereinfachungen, Vereinheitlichungen und Beschleunigungen, zumindestens habe ich das so verstanden.
Hab ich da tatsächlich einen Hinweis auf ein neues, verbindliches Kompressionsformat gesehen?
Irgendwas mit Gleitkomma, oder?


Für mich waren diese Folien jetzt schon überraschend. Da ist zum Beispiel die Rede von standardisierten MSAA und SSAA Filtern die Rede. Von Kommentaren wie "nur skalieren über die Performance, aber nicht über die Features", was für mich frei übersetzt so viel heißt, dass ATI und nVidia kaum noch mit eigenen, zusätzlichen Features glänzen können.

[Rente]

Monger[/POST]']Hab ich da tatsächlich einen Hinweis auf ein neues, verbindliches Kompressionsformat gesehen?
Irgendwas mit Gleitkomma, oder?


Für mich waren diese Folien jetzt schon überraschend. Da ist zum Beispiel die Rede von standardisierten MSAA und SSAA Filtern die Rede. Von Kommentaren wie "nur skalieren über die Performance, aber nicht über die Features", was für mich frei übersetzt so viel heißt, dass ATI und nVidia kaum noch mit eigenen, zusätzlichen Features glänzen können. Naja, es steht ja da "Optional Format Support", also ist FP32 (was du sicherlich meinst) nicht verbindlich.

Die Sachen mit MSAA und SSAA sind erst für D3D10.1 gedacht und ich denke es sind eher Vorgaben/Ideen die umgesetzt werden könnten. Alleine die Aussage "Boost image quality: Improved anti-aliasing" ist ohne Entwicklungen seitens ATi und nVidia wohl kaum machbar.

Außerdem kommt D3D10.1 laut der Folie ja erst "Next" also nach Anfang 2007 (Vista), wann genau weiß Microsoft wahrscheinlich selber noch nicht so genau (von denen stammt diese Präsi. ja).

[Gast]

Nix Effekte.

Verfahren!

Wenn du als Entwickler die Wahl hast, ein Verfahren bsw. für im Wind wiegende Blätter einzubauen, für den Performance-Hit aber auf so gut wie alles andere verzichten müsstest, läßt du es eben sein.

D3D10 verschiebt diesen Performance-Hit um einiges (zusammen mit dann verfügbaren, stärkeren GPUs) und sorgt so dafür, dass sich mehr Entwickler dafür entscheiden werden, bestimmte Effekte dann auch wirklich in ein Spiel zu integrieren.

Q

[Gast]

Gast[/POST]']Nix Effekte.

Verfahren!

Wenn du als Entwickler die Wahl hast, ein Verfahren bsw. für im Wind wiegende Blätter einzubauen, für den Performance-Hit aber auf so gut wie alles andere verzichten müsstest, läßt du es eben sein.

D3D10 verschiebt diesen Performance-Hit um einiges (zusammen mit dann verfügbaren, stärkeren GPUs) und sorgt so dafür, dass sich mehr Entwickler dafür entscheiden werden, bestimmte Effekte dann auch wirklich in ein Spiel zu integrieren.

Q
WElche Serie kann das jetzt schon besser X1900 oder 7900 ?

[Gast]

seltsam, FP32-blending wird als required aufgeführt, FP32-rendertarget aber optional, nur für was brauch ich das eine ohne das andere?

[Gast]

Gast[/POST]']WElche Serie kann das jetzt schon besser X1900 oder 7900 ?

garkeine.

die eingesparten rendercalls kommen auch vom neuen treiber- und api-design in vista und weniger durch die hardware selbst.

keine aktuelle hardware kann die D3D10-anforderungen erfüllen. bei D3D10 gibt es auch keine "bessere" oder "schlechtere" unterstützung mehr, entweder man kann es oder eben nicht.

[Coda]

Monger[/POST]']Da ist zum Beispiel die Rede von standardisierten MSAA und SSAA Filtern die Rede.
Antialiasing ist kein Filter.

Monger[/POST]']was für mich frei übersetzt so viel heißt, dass ATI und nVidia kaum noch mit eigenen, zusätzlichen Features glänzen können.
D3D10 hat (sogut wie) keine Caps mehr. Alle Karten müssen das gleiche können - und das ist gut so.

[aths]

Coda[/POST]']Antialiasing ist kein Filter.Aber benötigt einen Filter.

[tokugawa]

Effekte kommen nicht mit einer API, sondern mit den Ideen der Forscher und Entwickler, daher ist die Frage ganz falsch gestellt.

D3D10 wird sicher einige neue Algorithmen auf der GPU möglich machen.

Bevor es weder API noch Hardware gibt können die Entwickler allerdings noch wenig machen (mit dem Reference Rasterizer macht's keinen Spaß).

[Coda]

aths[/POST]']Aber benötigt einen Filter.
Hm ja, so könnte das sogar Sinn ergeben.

[Gast]

sd[/POST]']Wird man mit einer X1900 zb bei Crysis alle Effekte darstellen können ?Kommt darauf an wieviel Geld MS an Crytek zahlt.
2.Frage siehe Topic.Gar keine. Die Hardware unterstützt möglicherweise eine einzige neue Fähigkeit (Geometry Shader). Obwohl, wahrscheinlich eher nicht.
Die einzige Funktion von Direct3D dabei ist es den Zugriff auf diese neue Fähigkeit derart einzuschränken, dass ein Verkaufsargument für Windows Vista entsteht.

-zecki

[aths]

Gast[/POST]']Kommt darauf an wieviel Geld MS an Crytek zahlt.Vermutlich gar keins. Crytek will sein Spiel verkaufen. Wenn MS einen Vista-"Systemseller" braucht, müssten sie dann schon Crytek kaufen. Also komplett aufkaufen.
Gast[/POST]']Gar keine. Die Hardware unterstützt möglicherweise eine einzige neue Fähigkeit (Geometry Shader). Obwohl, wahrscheinlich eher nicht.
Die einzige Funktion von Direct3D dabei ist es den Zugriff auf diese neue Fähigkeit derart einzuschränken, dass ein Verkaufsargument für Windows Vista entsteht.Das hätte ich gerne genauer erklärt.

Die Hardware unterstützt auch neue Funktionen wie Bitoperationen.

[DaBrain]

AnarchX[/POST]']Geometry-Shader... ;)

Werden die von OpenGL eigentlich auch schon unterstützt?


Ich hoffe der API Trend bei Spieleb geht wieder zurück zu OpenGL, weil ich nicht viel von Vista halte...

[Demirug]

DaBrain[/POST]']Werden die von OpenGL eigentlich auch schon unterstützt?

Es gibt noch keine Extension dafür. Mit etwas Glück einigen sich nVida und ATI schnell auf eine gemeinsame Variante sobald die Karten auf dem Markt sind.

DaBrain[/POST]']Ich hoffe der API Trend bei Spieleb geht wieder zurück zu OpenGL, weil ich nicht viel von Vista halte...

Davon würde ich derzeit nicht ausgehen. Wenn man sich für OpenGL 3.0 nicht zu einem klaren Schnitt durchringen kann sehe ich eher noch größere Abwanderungstendenzen zu D3D10.

Unabhängig davon ob man Microsoft nun mag oder nicht sie bieten derzeit einfach das vollständigere Packet. Vielleicht wird die Situation bei OpenGL aber besser nachdem SGI die Kontrolle abgegeben hat.

[john carmack]

Ob-1[/POST]']Danke für die Hilfe. ;)
Eine ganz interessante Präsentation was bei D3D10 neu sein wird: http://download.microsoft.com/download/5/b/9/5b97017b-e28a-4bae-ba48-174cf47d23cd/PRI022_WH06.ppt




toller link!!!!!!!!!!!!!!!

wird denn eine mögliche "ATI X2800 pro" oder eine "GeForce 8800GT" D3D10.1 unterstützen oder nur 10.0???

dieses DisplacementMappig geht ja voll ab!!!!!!!!!!!!!! der fisch sieht geil aus!

[Neomi]

john carmack[/POST]']wird denn eine mögliche "ATI X2800 pro" oder eine "GeForce 8800GT" D3D10.1 unterstützen oder nur 10.0???

Hardware-Support für D3D 10.1 wird etwas länger dauern, wenn ich mir die Anforderungen dafür so ansehe. Ich rechne frühestens ein Jahr nach D3D 10.0 damit.

[StefanV]

Öhm, was ist D3D 10.1 und was 10.0? :|

[Seraf]

StefanV[/POST]']Öhm, was ist D3D 10.1 und was 10.0? :|

Präsentation nicht gelesen?
10.1 bringt MSAA als Pflichtfeature.


Auszug:

Direct3D 10.1 Goals

Guarantee WDDM 2.1-level capability to developers and end-users
Lower CPU overhead
Massive datasets
Increase capability and performance
“Complete” Direct3D 10
Boost image quality: Improved anti-aliasing


Direct3D 10.1 FeaturesFull anti-aliasing control

Application control over:
Multi-sample AA (smooth edges)
or
Super-sample AA (smooth edges and interior)
Selecting sample patterns
Pixel coverage mask
High-quality vegetation, motion blur, particles…
Minimum of 4 samples/pixel required



Direct3D 10.1 FeaturesIncreased pipeline and shader capability

Improved shader resource access
Greater control over MSAA readback
Custom downsample filters
Improved shadow filtering
Float32 filtering requirement
Better HDR
Enhanced blending
Independent blend modes per-rendertarget
New blend-able rendertarget formats
Increased pipeline precision


Direct3D 10.1 FeaturesPerformance enhancements

Enable applications to further exploit multicore for rendering
Fewer API calls for reflections and refractions
Support for indexable, generalized cubemap arrays


Aber bis D3D10.1 kommt dauert es ja noch ein wenig:

Direct3D 10 and WDDM for 2007
Direct3D 10.1 and WDDM 2.1 for “next”

[Demirug]

Wobei die WDDM 2.1 Sache dabei wohl am wichtigsten ist.

Direct3D 10.1 ist übrigens nur ein Codename es kann durchaus sein das man den aus Marketing Gründen noch anpaßt.

[john carmack]

kennt ihr die TechDemos von Crysis??

da ist doch immer von "Volumenetrische wolken" (oder so ähnlich) die rede

ein D3D10.0 effekt? oder noch DX9.0c Shader 3.0?



http://www.crysis-hq.de/

oder

http://crysis.4thdimension.info/modules.php?name=Downloads&d_op=getit&lid=8

Content:
- Volumetric Clouds
- Realtime Ambient Maps
- Soft Shadows
- Depth of Field
- Motion Blur
- Tree Physic
- Big Monster


das spiel braucht wohl Monster anforderungen ist ja auch ein "DX10" spiel

[Neomi]

john carmack[/POST]']ein D3D10.0 effekt? oder noch DX9.0c Shader 3.0?

das spiel braucht wohl Monster anforderungen ist ja auch ein "DX10" spiel

Es wird kein DirectX 10 geben, sondern "nur" Direct3D 10. Crysis wird ein D3D9-Spiel, das dann je nach Release-Zeitpunkt direkt oder später per Patch einen D3D10-Pfad zusätzlich bekommt, der erstmal nur für eine Beschleunigung (z.B. durch Passreduktion) sorgt. Alles, was du bisher von Crysis gesehen hast, ist D3D9.

Durch den effizienteren Umgang mit Ressourcen werden echte D3D10-Spiele sogar niedrigere Anforderungen haben als gleich aussehende D3D9-Spiele, abgesehen vom Featureset der Hardware natürlich.

[Gast]

john carmack[/POST]']kennt ihr die TechDemos von Crysis??

da ist doch immer von "Volumenetrische wolken" (oder so ähnlich) die rede

ein D3D10.0 effekt? oder noch DX9.0c Shader 3.0?




alles was du bisher von crysis gesehen hast ist D3D9

[john carmack]

wie kein DX10???

lest mal hier!
http://www.pcgames.de/?article_id=481124

[Gast]

john carmack[/POST]']wie kein DX10???



das ändert nichts daran dass alles bisher gezeigte D3D9 ist.

schon möglich dass mit D3D10 noch zusätzliche effekte dazukommen.

[Coda]

Was hat jetzt Hellgate mit Crysis zu tun?

Die Screenshots und Videos von Crysis bisher sind alle D3D9.

[Rente]

john carmack[/POST]']wie kein DX10???

lest mal hier!
http://www.pcgames.de/?article_id=481124 Die Adresse der News sollte doch klarstellen warum sie das schreiben...

Kein DX10, zumindestens gibt es keine Pläne dazu es jemals fortzusetzen. Der nächste Schritt ist Direct3D10, mehr nicht.

[Neomi]

john carmack[/POST]']wie kein DX10???

lest mal hier!
http://www.pcgames.de/?article_id=481124

Genau deshalb muß man das ja immer wieder richtigstellen. Überall, auch auf vielen Hardwareseiten, liest man von DirectX 10, aber richtig wird es dadurch nicht. Microsoft selbst redet auch nur von Direct3D 10.

Wäre D3D10 abwärtskompatibel zu D3D9, würde es D3D9 ersetzen und mit allen anderen Komponenten (auch wenn die nicht weiterentwickelt wurden) zusammen DX10 ergeben. D3D10 ist aber nicht abwärtskompatibel und ersetzt deshalb nicht D3D9, es ist eigenständig. Deshalb gibt es auch kein DX10, sondern DX9 und D3D10 zusammen unter Vista.

[Kinman]

john carmack[/POST]']toller link!!!!!!!!!!!!!!!

wird denn eine mögliche "ATI X2800 pro" oder eine "GeForce 8800GT" D3D10.1 unterstützen oder nur 10.0???

dieses DisplacementMappig geht ja voll ab!!!!!!!!!!!!!! der fisch sieht geil aus!

Displacement Mapping gibts doch seit DX9 bzw. der Prahelia, oder?

mfg Kinman

[StefanV]

Kinman[/POST]']Displacement Mapping gibts doch seit DX9 bzw. der Prahelia, oder?

mfg Kinman
Theoretisch schon, praktisch scheints a bisserl defekt zu sein, bei der Parhelia...

Und das, was die parhelia eigentlich können sollte, kann (leider) kein anderer CHip...

[tokugawa]

john carmack[/POST]']kennt ihr die TechDemos von Crysis??

da ist doch immer von "Volumenetrische wolken" (oder so ähnlich) die rede

ein D3D10.0 effekt? oder noch DX9.0c Shader 3.0?



http://www.crysis-hq.de/

oder

http://crysis.4thdimension.info/modules.php?name=Downloads&d_op=getit&lid=8

Content:
- Volumetric Clouds
- Realtime Ambient Maps
- Soft Shadows
- Depth of Field
- Motion Blur
- Tree Physic
- Big Monster


das spiel braucht wohl Monster anforderungen ist ja auch ein "DX10" spiel

Der Effekt ist leicht mit vorhandener Hardware möglich, etwa über Depth Impostors: http://www.iit.bme.hu/~szirmay/felhos_link.htm

[sloth9]

Neomi[/POST]']Genau deshalb muß man das ja immer wieder richtigstellen. Überall, auch auf vielen Hardwareseiten, liest man von DirectX 10, aber richtig wird es dadurch nicht. Microsoft selbst redet auch nur von Direct3D 10.

Wäre D3D10 abwärtskompatibel zu D3D9, würde es D3D9 ersetzen und mit allen anderen Komponenten (auch wenn die nicht weiterentwickelt wurden) zusammen DX10 ergeben. D3D10 ist aber nicht abwärtskompatibel und ersetzt deshalb nicht D3D9, es ist eigenständig. Deshalb gibt es auch kein DX10, sondern DX9 und D3D10 zusammen unter Vista.

Leider haben "Spielredakteure" schon traditionell keine Ahnung.
Die können fast immer null C, von Shadern ganz zu schweigen. Was muss man für ein Gamemag überhaupt können? Schreiben offensichtlich wohl auch nicht... :|

[Gast]

sloth9[/POST]']Was muss man für ein Gamemag überhaupt können?

spielen ;)

was ja auch garnicht mal so falsch ist, nur sollten sie ihre hardwaretests etwas kompetenteren leuten überlassen ;)

[Demirug]

Die Kollegen mal etwas in Schutz nehmen. Auf der ATI Pressveranstaltung zu Direct3D 10 hat der ATI Mitarbeiter (Richard Huddy) auch ständig von DirectX 10 gesprochen. nVidia hat das auch in einigen Slides benutzt. Sie sollten es eigentlich besser wissen aber DirectX ist nun der bekanntere Begriff als Direct3D.

[Gast]

sloth9[/POST]']Leider haben "Spielredakteure" schon traditionell keine Ahnung.
Die können fast immer null C, von Shadern ganz zu schweigen. Was muss man für ein Gamemag überhaupt können? Schreiben offensichtlich wohl auch nicht... :|

Warum sollten Spieleredakteure "C" beherrschen? Michael Schumacher hat ja auch keinen Dipl.-Ing. in Maschinenbau.

[StefanV]

Gast[/POST]']Warum sollten Spieleredakteure "C" beherrschen? Michael Schumacher hat ja auch keinen Dipl.-Ing. in Maschinenbau.
Nein, ist aber gelernter KFZ Mechaniker :devil:
Er kann also keinen Motor bauen, er könnt ihn aber reparieren, theoretisch.

[Gast]

StefanV[/POST]']Nein, ist aber gelernter KFZ Mechaniker :devil:
Er kann also keinen Motor bauen, er könnt ihn aber reparieren, theoretisch.
Musst du meine Metapher kaputtmachen? :)

[sloth9]

Gast[/POST]']spielen ;)

was ja auch garnicht mal so falsch ist, nur sollten sie ihre hardwaretests etwas kompetenteren leuten überlassen ;)

Gast[/POST]']Warum sollten Spieleredakteure "C" beherrschen? Michael Schumacher hat ja auch keinen Dipl.-Ing. in Maschinenbau.

Dann sollten sie sich aber auf ein "Das Spiel macht Spaß, weil..." und einem nicht ständig was von Shadern und Grafiktechniken erzählen.
Geil auch Tuning-Tipps wie "Ohne Schatten läuft's schneller". Sinn?

Als Autotester ohne Kenntnisse über die Funktionsweise eines Otto-Motors etc. sollte ich die Crashtests auch anderen überlassen und mich auf ein "fährt sich nett" beschränken.

[tokugawa]

Gast[/POST]']Warum sollten Spieleredakteure "C" beherrschen? Michael Schumacher hat ja auch keinen Dipl.-Ing. in Maschinenbau.

Das mit "C" war nur beispielhaft metaphorisch.

Es ging prinzipiell darum dass Spieleredakteure in Bezug auf Grafiktechnologien tendenziell sehr wenig Ahnung haben.

[The_Invisible]

tokugawa[/POST]']Das mit "C" war nur beispielhaft metaphorisch.

Es ging prinzipiell darum dass Spieleredakteure in Bezug auf Grafiktechnologien tendenziell sehr wenig Ahnung haben.

ist halt eh quasi wie mechaniker und C :D (will hier aber niemanden was unterstellen)

mfg

[MechWOLLIer]

Demirug[/POST]']Die Kollegen mal etwas in Schutz nehmen. Auf der ATI Pressveranstaltung zu Direct3D 10 hat der ATI Mitarbeiter (Richard Huddy) auch ständig von DirectX 10 gesprochen. nVidia hat das auch in einigen Slides benutzt. Sie sollten es eigentlich besser wissen aber DirectX ist nun der bekanntere Begriff als Direct3D.

Da frage ich mich aber auch überhaupt, ob der Huddy da überhaupt selber noch richtig durchblickt. Ich habe ihn extra mal genau nach der Bezeichnung gefragt, und er hat mir gesagt, dass die ganz fest bei DirectX 10 ist. Von Direct3D wollte er nichts wissen.

[Coda]

Ist Huddy der mit dem kranken Akzent?

[MechWOLLIer]

Mh, eher der oldschool classic Brite mit recht wenigen Haaren, hat aber keinen kranken Akzent.

[Gast]

:|aths[/POST]']Das hätte ich gerne genauer erklärt.

Die Hardware unterstützt auch neue Funktionen wie Bitoperationen.Ok, nochmal anders:
Weder Microsoft noch eine Direct3D-Version haben jemals ursächlich dazu geführt dass eine Grafikhardware ein neues Feature bekommen hat. Und es ist absolut naiv jetzt zu erwarten dass sich das ändern wird. Und auch wenn's OT ist, es geht mir auf den Sack dass Microsoft immer soviele Vorschussloorberen und hohlen Respekt bekommt obwohl diese Firma zum technischen Fortschritt nie beiträgt.

Microsoft hat im Prinzip null Plan von Grafik. Die Features die Microsoft selbst einführen wollte sind schlicht an der Realität gescheitert: kubische Texturfilter zB gibt's seit D3D 5 oder so, "vertex texture fetch" dürfte dir auch noch ein Begriff sein, und ich muss ganz klar sagen dass weder Bitoperationen noch ein Geometry Shader in eine Grafikhardware hineingehören. Das ist sinnloses Säbelgerassel und wird aller Wahrscheinlichkeit nach wieder genau so enden wie "vertex texture fetch", nämlich mit erschummelten Pseudo-Implementierungen und praktischer Irrelevanz.

Ohne ATI und NVIDIA könnte Microsoft Direct3D gar nicht mehr machen. Ohne ATI und NVIDIA kann es keine neuen Hardware-Features im Windows-Grafikmassenmarkt geben. So herum sind die Machtverhältnisse. Wer denkt Microsoft könnte da irgendetwas steuern hat salopp gesagt nicht mehr alle Tassen im Schrank.

-zecki

[Neomi]

Natürlich geht es nicht ohne ATI und nVidia, aber unabhängig davon ist D3D10 schon ein ein sehr guter Schritt. Was stört dich denn z.B. am Geometry Shader? Wenn die Performance stimmt (und das ist nur eine Frage der Implementierung), kann man einige recht nette Sachen machen, die jetzt nur mit erheblichem Mehraufwand gehen.

[Coda]

Gast[/POST]']Microsoft hat im Prinzip null Plan von Grafik.
Das ist gelogen. Microsoft hat einige sehr fähige Leute in der Grafikabteilung.

Gast[/POST]']kubische Texturfilter zB gibt's seit D3D 5 oder so
Ich glaube das war später. Features werden nur eingeführt wenn ein IHV danach verlangt. Die Intel GMA-Chips können es.

Gast[/POST]']"vertex texture fetch" dürfte dir auch noch ein Begriff sein
Ja und? Was ist daran falsch?

Gast[/POST]']und ich muss ganz klar sagen dass weder Bitoperationen noch ein Geometry Shader in eine Grafikhardware hineingehören.
Gibts dafür auch Begründungen? Ich bin äußerst froh über beides.

Gast[/POST]']Ohne ATI und NVIDIA könnte Microsoft Direct3D gar nicht mehr machen. Ohne ATI und NVIDIA kann es keine neuen Hardware-Features im Windows-Grafikmassenmarkt geben. So herum sind die Machtverhältnisse. Wer denkt Microsoft könnte da irgendetwas steuern hat salopp gesagt nicht mehr alle Tassen im Schrank.
Richtig. Und alle von dir genannten Features wurden von den IHVs bei Microsoft "bestellt" und nicht andersrum

Gast[/POST]']-zecki
Irgendwie zweifel ich daran bei solch einem Post.

[Gast]

Coda[/POST]']Irgendwie zweifel ich daran bei solch einem Post.Nicht nur du. Das ist wohl der "r@w."-Troll oder ein Trittbrettfahrer.

[Demirug]

Coda[/POST]']Richtig. Und alle von dir genannten Features wurden von den IHVs bei Microsoft "bestellt" und nicht andersrum

Müssen nicht zwingend IHVs sein. Es gibt etwa alle 6 Monate bei Microsoft ein Treffen zudem neben den IHVs auch Vertreter von den großen Entwicklern eingeladen werden. Die dürfen da auch Wünsche äußern. Die Sache mit dem reduzierten Drawcall Overhead kam maßgeblich aus dieser Richtung.

[Coda]

Demirug[/POST]']Die Sache mit dem reduzierten Drawcall Overhead kam maßgeblich aus dieser Richtung.
Würde ich jetzt nicht als "Feature" bezeichnen sondern eher als Verbesserung.

[zeckensack]

Neomi[/POST]']Natürlich geht es nicht ohne ATI und nVidia, aber unabhängig davon ist D3D10 schon ein ein sehr guter Schritt. Was stört dich denn z.B. am Geometry Shader? Wenn die Performance stimmt (und das ist nur eine Frage der Implementierung), kann man einige recht nette Sachen machen, die jetzt nur mit erheblichem Mehraufwand gehen.Die korrekte Lösung für GS ist eine GP-CPU. Jeder PC hat eine solche. Noch eine weitere GP-CPU in die GPU zu integrieren ist Verschwendung, da die Leistung dann nur für GS-Aufgaben genutzt werden kann und ansonsten (=meistens) brachliegt.

Das ist wieder so ein Performance-Workaround für Direct3D <=9. Wenn man eine API benutzt mit der man sich dynamische Geometrie leisten kann, wie etwa D3D9L, D3D10 oder OpenGL, braucht man sowas einfach nicht.

Genau so wie man auf Linux kein NCQ braucht, weil die Aufgabe da von genau der Komponente erledigt wird die dafür auch zuständig ist: von der Software.

[Coda]

zeckensack[/POST]']Die korrekte Lösung für GS ist eine GP-CPU. Jeder PC hat eine solche.
Der GS sitzt hinter dem VS. Readbacks von Vertexdaten kannst du vergessen.

Hast du dir überhaupt mal angeschaut für was man das Ding überhaupt verwenden kann oder bist du einfach mal generell dagegen?

zeckensack[/POST]']Das ist wieder so ein Performance-Workaround für Direct3D <=9. Wenn man eine API benutzt mit der man sich dynamische Geometrie leisten kann, wie etwa D3D9L, D3D10 oder OpenGL, braucht man sowas einfach nicht.
Einfach nur Schwachsinn. Wie willst du denn bitte Displacement-Mapping mit Textur-Fetches auf statische Vertexbuffer in der CPU machen? Oder Verteilung der Geometrie auf mehrere Rendertargets zur Cubemap-Generation?

Und da fängts noch lange nicht an, allein Stencil-Volumes lassen sich mit dem GS um einiges schneller berechnen.

[Demirug]

zeckensack[/POST]']Die korrekte Lösung für GS ist eine GP-CPU. Jeder PC hat eine solche. Noch eine weitere GP-CPU in die GPU zu integrieren ist Verschwendung, da die Leistung dann nur für GS-Aufgaben genutzt werden kann und ansonsten (=meistens) brachliegt.

Dafür gibt es ja gemeinsam genutzte Shader im Chip. Eine Idee für die ich übrigens hier vor einer halben Ewigkeit mal böse geschlagen wurde.

zeckensack[/POST]']Das ist wieder so ein Performance-Workaround für Direct3D <=9. Wenn man eine API benutzt mit der man sich dynamische Geometrie leisten kann, wie etwa D3D9L, D3D10 oder OpenGL, braucht man sowas einfach nicht.

Das ist aber ein Wiederspruch weil man mit D3D9 den GS ja gar nicht nutzen kann. Zudem solange die Leistung der GPUs schneller steigt als die Leistung der CPUs bin ich um alles froh was ich auslagern kann.

[zeckensack]

Coda[/POST]']Das ist gelogen. Microsoft hat einige sehr fähige Leute in der Grafikabteilung.Sind das die Leute die erst jetzt so langsam beginnen zu kapieren wie man Texturkoordinaten sinnvollerweise definiert?
(dh: in D3D10 ist's endlich richtig)

Sind das die gleichen Leute die die ultimative Idee hatten: hey, packen wir den kompletten Treiber doch in den Kernel und wandeln 50% der Rechenleistung auf diesem Planeten in Wärme um!

Sind das die gleichen Leute die bis DX7 alles zusammengeklaut haben was sie finden konnten, ohne allerdings zu verstehen was sie da eigentlich klauen?
(diverse Horrorfeatures von Glide, wie zB Locks insbesondere auf den Z-Buffer, Chroma Key)

Sind das die gleichen Leute die sich zwecks WinHEC diese ganzen cleveren Performance-Workarounds ausdenken, die's gar nicht gäbe wenn sie fähig wären und etwas zu sagen hätten?

Mal ganz davon abgesehen dass Microsoft dank des nicht-öffentlichen Treibermodells und der sonstigen Zusammenarbeit mit echten Grafikexperten reichlich Chancen hatte ein paar Brocken hier und da aufzuschnappen.

Du hast viel Vertrauen in Microsoft's Fähigkeiten. Ich nicht. Ich bin der Meinung dass Microsoft eine von der Öffentlichkeit ziemlich überschätzte Firma ist, und vor allem damit außerordentlich viel Geld verdient.
Ich glaube das war später. Features werden nur eingeführt wenn ein IHV danach verlangt. Die Intel GMA-Chips können es.GMA900? Nein, definitiv früher. D3D7 allerspätestens, wahrscheinlich D3D6. Müsste ich mal buddeln gehen.
Ja und? Was ist daran falsch?ATI hat MS verarscht. NVIDIA hat MS auch verarscht, nur nicht ganz so offensichtlich. NVIDIA hat MS eine 2D indexed constant storage gebaut, mit den schlimmsten Beschränkungen die du dir vorstellen kannst. Es ist nicht sinnvoll einsetzbar, und so weit ich den Markt überschauen kann wurde es außerhalb von Werbe-Aktionen auch nie eingesetzt.
Gibts dafür auch Begründungen? Ich bin äußerst froh über beides.Hatte ich gerade schon.
Richtig. Und alle von dir genannten Features wurden von den IHVs bei Microsoft "bestellt" und nicht andersrumUnd das heißt jetzt was? Dass Microsoft die Hardware-Features erfunden hat?
Haben sie nämlich nicht.

[Raff]

Auch wenn mir der Tonfall missfällt: Redet ruhig weiter, klingt interessant. :)

MfG,
Raff

[Gast]

blöde frage: können ng konsolen dx10 - nein
warum sollte man es dann vor 2010 in Spielen einsetzen

[Coda]

zeckensack[/POST]']Sind das die Leute die erst jetzt so langsam beginnen zu kapieren wie man Texturkoordinaten sinnvollerweise definiert?
Das ist effektiv doch völlig egal.

zeckensack[/POST]']Sind das die gleichen Leute die die ultimative Idee hatten: hey, packen wir den kompletten Treiber doch in den Kernel
Nö. Das war eine Entscheidung der NT4-Zeit wo es sinnvoll war um keine X11-Performance zu erhalten.

zeckensack[/POST]']und wandeln 50% der Rechenleistung auf diesem Planeten in Wärme um!
Ich komme nicht mit.

zeckensack[/POST]']Sind das die gleichen Leute die bis DX7 alles zusammengeklaut haben was sie finden konnten, ohne allerdings zu verstehen was sie da eigentlich klauen?
(diverse Horrorfeatures von Glide, wie zB Locks insbesondere auf den Z-Buffer, Chroma Key)
Nein. Microsoft hat erst vor DX8 dann endlich mal Leute beschafft die sich damit auch auskennen.

http://research.microsoft.com/graphics/

Jim Blinn sollte dir ein Begriff sein :tongue:

zeckensack[/POST]']Sind das die gleichen Leute die sich zwecks WinHEC diese ganzen cleveren Performance-Workarounds ausdenken, die's gar nicht gäbe wenn sie fähig wären und etwas zu sagen hätten?
kA, wird mit D3D10 ja eh anders. Mit XP hätte man das Treibermodell zwar auch schon umschmeißen können tut es aber jetzt erst.

zeckensack[/POST]']NVIDIA hat MS eine 2D indexed constant storage gebaut, mit den schlimmsten Beschränkungen die du dir vorstellen kannst. Es ist nicht sinnvoll einsetzbar, und so weit ich den Markt überschauen kann wurde es außerhalb von Werbe-Aktionen auch nie eingesetzt.
Das ist sie aber nicht. Ich habe dir schon mehrmals gesagt, dass es viel höhere Latenzen als der Zugriff auf das Registerfile hat und außerdem nebenläufig ist.

Ja, es war ein Fehler das in SM3 als Pflichtfeature aufzunehmen.

Das es nie eingesetzt wurde hat wohl stark damit zu tun dass es ATI mit keiner D3D9-GPU unterstützt.

zeckensack[/POST]']Und das heißt jetzt was? Dass Microsoft die Hardware-Features erfunden hat?
Haben sie nämlich nicht.
Nein. Genau das Gegenteil. Ließt du was ich schreibe?

Gast[/POST]']blöde frage: können ng konsolen dx10 - nein
warum sollte man es dann vor 2010 in Spielen einsetzen
Sehr witzig. Warum gabs dann DX9-Spiele vor der Xbox 360?

[Demirug]

Gast[/POST]']blöde frage: können ng konsolen dx10 - nein
warum sollte man es dann vor 2010 in Spielen einsetzen

Aus dem gleichen Grund aus dem D3D9 in PC Spielen genutzt wurde obwohl die Konsolen bestenfalls auf D3D8 Level waren?

[zeckensack]

Demirug[/POST]']Dafür gibt es ja gemeinsam genutzte Shader im Chip. Eine Idee für die ich übrigens hier vor einer halben Ewigkeit mal böse geschlagen wurde.Es geht mir nicht um die Nutzung der ALUs, sondern um die nicht streaming-kompatible Aufgabenstellung. Ein GS wird sich nicht mal eben so massiv parallel implementieren lassen wie der Rest einer typischen GPU. Ich glaube nicht dass die Performance irgendjemanden begeistern wird @Coda, wenn wir das überhaupt noch in Hardware erleben.

Die Klasse der Aufgaben im Geometriebereich die sich für massiv parallele Arbeit eignen werden schon längst von der Hardware erledigt, nennt sich "vertex shader".
Das ist aber ein Wiederspruch weil man mit D3D9 den GS ja gar nicht nutzen kann.Es ist kein Widerspruch. Wenn du die GS-Arbeit mit der CPU machst, und die Ergebnisse in einen dynamischen Vertex Buffer schreibst, hast du doch den Ersatz für dieses fehlende Feature. Bitte beachten dass ich mit D3D9L die Version für Vista meinte, wo die Performance dann auch akzeptabel sein sollte, wenn an den Vorabmeldungen was dran ist.
Zudem solange die Leistung der GPUs schneller steigt als die Leistung der CPUs bin ich um alles froh was ich auslagern kann.Das ist mein Argument: GS-Leistung wird keineswegs zufriedenstellend skalieren, weil das Problem eben relativ schwer zu parallelisieren ist, und die GPU-Bauer sowas noch nie gemacht haben.

Frag' mal bei ATI an wo das programmierbare Blending bleibt. Gleiches Problem, nur viel weniger schlimm.

[Coda]

zeckensack[/POST]']Ein GS wird sich nicht mal eben so massiv parallel implementieren lassen wie der Rest einer typischen GPU.
Du hast die Spec wirklich nicht gelesen (eigentlich bin ich jetzt ziemlich sauer, aber ich behersch mich noch). Das Ding läuft auf R600 auf den genau gleichen ALUs wie PS und VS. Und sehr wohl parallel.

zeckensack[/POST]']Die Klasse der Aufgaben im Geometriebereich die sich für massiv parallele Arbeit eignen werden schon längst von der Hardware erledigt, nennt sich "vertex shader".
Schön. Mit einem 1zu1 Verhältnis Input/Output kommen wir aber leider nicht weiter.

zeckensack[/POST]']Es ist kein Widerspruch. Wenn du die GS-Arbeit mit der CPU machst, und die Ergebnisse in einen dynamischen Vertex Buffer schreibst, hast du doch den Ersatz für dieses fehlende Feature.
Ganz großes Kino. Und wenn wir transformierte Daten für den GS brauchen dann machen wir das auf der CPU auch noch nebenbei. Ach wieso lassen wir dann den VS nicht auch gleich weg und gehen wieder zu den reinen Rasterizern zurück. Leute gibts...

Ach und Texturfilterung ist auf der CPU ja auch so unglaublich schnell - ich vergaß.

zeckensack[/POST]']Das ist mein Argument: GS-Leistung wird keineswegs zufriedenstellend skalieren, weil das Problem eben relativ schwer zu parallelisieren ist, und die GPU-Bauer sowas noch nie gemacht haben.
Das zusammenfällt wie ein Kartenhaus weil es einfach nicht stimmt.

[zeckensack]

Coda[/POST]']Das ist effektiv doch völlig egal.

Nö. Das war eine Entscheidung der NT4-Zeit wo es sinnvoll war um keine X11-Performance zu erhalten.

Ich komme nicht mit.

Nein. Microsoft hat erst vor DX8 dann endlich mal Leute beschafft die sich damit auch auskennen.
Du wolltest mir erzählen dass Microsoft "einige sehr fähige Leute" hat. Vor dem Hintergrund finde ich nicht dass es egal ist was diese Leute schon alles grob falsch gemacht haben. Da fehlt's an absoluten Grundlagen, oder man trifft die Entscheidungen da wo die "sehr fähigen Leute" nichts mitzureden haben.
http://research.microsoft.com/graphics/[/url]

Jim Blinn sollte dir ein Begriff sein :tongue:Das Ergebnis ist das gleiche. Ein "Kompetenzteam Grafik" darf nicht drei Major-Versionen und ~6 Jahre brauchen um die Grundlagen hinzukriegen.
kA, wird mit D3D10 ja eh anders. Mit XP hätte man das Treibermodell zwar auch schon umschmeißen können tut es aber jetzt erst.Zweifelsfrei ein Kaufanreiz für Vista, davon gibt's ja nicht so besonders viele, und alleine deswegen wird es für XP nicht kommen.
Das ist sie aber nicht. Ich habe dir schon mehrmals gesagt, dass es viel höhere Latenzen als der Zugriff auf das Registerfile hat und außerdem nebenläufig ist.Dadurch wird es auch nicht nützlicher.
Ja, es war ein Fehler das in SM3 als Pflichtfeature aufzunehmen.

Das es nie eingesetzt wurde hat wohl stark damit zu tun dass es ATI mit keiner D3D9-GPU unterstützt.Ich denke mal es ergibt einfach keinen großen Sinn ohne zumindest bilinearen Filter, und selbst wenn man den hat muss man sich doch fragen warum man nicht einen zusätzlichen Vertex Stream nutzt.

Welche geometrischen Effekte sind denn bitte von der Kameraposition oder sowas abhängig? Bei Wellen (dem berüchtigten Demomaterial; zeitabhängig) kann man's ja noch irgendwie einsehen, bis man dann auf den Trichter kommt einfach das komplette Mesh zu bewegen, und nicht die "Textur" ...

Sag' mir was du damit vorhast, und ich sage dir warum du ohne VTF besser (schneller) dran bist. Zu 99%.

Nein. Genau das Gegenteil. Ließt du was ich schreibe?Jawoll. Du hast mir gesagt die IHVs haben Features bei Microsoft bestellt. Ich habe dich gefragt was du mir damit sagen wolltest. Das ist mir jetzt auch noch nicht klar.
Die IHVs müssen, da ja die Könige 1)Kunde und 2)verwöhnter Developer von Welt davon überzeugt wurden dass Direct3D relevant ist, mit Microsoft zusammenarbeiten, damit die Features die sie sowieso wollen und einbauen werden auch über diese API offengelegt werden können. Microsoft freut's, weil man nochmal so richtig schön einen auf dicke Hose machen kann.

Ich gehe davon aus dass das irgendwie mit meiner These zu tun haben soll dass Microsoft nicht an der Neufindung relevanter Hardware-Features im Grafikbereich beteiligt ist. Ich weiß nicht inwiefern, habe nur gemerkt dass du wohl anderer Meinung bist.

[Coda]

zeckensack[/POST]']Sag' mir was du damit vorhast, und ich sage dir warum du ohne VTF besser (schneller) dran bist. Zu 99%.
Ist wohl auch so, nur ist da wohl eher nVIDIA dran schuld. ATI hatte da sehr wohl ein Mitspracherecht (frag Demirug) und sie haben sich nicht dagegen gewehrt dass Tex-Befehle in VS3 Pflicht werden - wohl ganz einfach aus dem Grund weil sie da noch dachten sie würden R500 marktreif bekommen, der als unified Shader das Ganze ohnehin gekonnt hätte.

zeckensack[/POST]']Ich gehe davon aus dass das irgendwie mit meiner These zu tun haben soll dass Microsoft nicht an der Neufindung relevanter Hardware-Features im Grafikbereich beteiligt ist. Ich weiß nicht inwiefern, habe nur gemerkt dass du wohl anderer Meinung bist.
Nein bin ich nicht.

Ich bin nur nicht so schrecklich arrogant und nehme an das sich die Personalverhältnisse bei Microsoft nicht (was offensichtlich ist) grundlegend geändert haben. Sonst hätten sie kein D3D8-10 auf die Beine stellen können. Das sind alles solide APIs.

[Neomi]

zeckensack[/POST]']... Ein GS wird sich nicht mal eben so massiv parallel implementieren lassen wie der Rest einer typischen GPU. ...

Eigentlich schätze ich deine Meinung ja sehr hoch ein, im Bezug auf den GS scheint mir die aber sehr... sagen wir mal "uninformiert" zu sein.

1. Der GS läßt sich wunderbar parallelisieren, genau wie der VS schon. Wenn jede Instanz an einem einzelnen vollständigen Primitive arbeitet, hat sie keinen Kontakt mit einer anderen Instanz, die an einen anderen vollständigen Primitive arbeitet. Eventuell muß der Output noch serialisiert werden, aber das ist auch mit kleinen Buffern zu schaffen. Und das ist auch nur dann nötig, wenn die Reihenfolge der ausgespuckten Primitives strikt eingehalten werden muß.

2. Eine Pipelinestufe in der GPU dürfte, egal wie langsam in den ersten Implementierungen, trotzdem noch mindestens eine Größenordnung schneller sein als deine Lösung. Rücktransport zur CPU, Bearbeitung der Daten (evtl. inklusive Nutzung von gefilterten Texturen, die auch über den Bus müssen oder lokal ebenfalls vorhanden sein müssen), zurück über den Bus zur GPU, das kann nicht wirklich schnell sein.

3. Sicher läßt sich die reine Funktionsweise eines GS per CPU nachbilden, aber das kann man mit VS und PS ebenfalls. Es geht aber weniger um ein Gesamtsystem, das mit so wenig Transistoren wie möglich alles kann, egal in welcher Zeit.

[Coda]

Neomi[/POST]']Und das ist auch nur dann nötig, wenn die Reihenfolge der ausgespuckten Primitives strikt eingehalten werden muß.
Muss sie das eigentlich? Genau das ging mir vorhin durch den Kopf deswegen.

[Neomi]

Coda[/POST]']Muss sie das eigentlich? Genau das ging mir vorhin durch den Kopf deswegen.

Ich sehe zumindest keinen wirklichen Grund, warum sie das sollte. Bei transparenter Darstellung und sich selbst überlappender Geometrie kann eine unterschiedliche Reihenfolge zu einem unterschiedlichen Endergebnis führen, da ist das vielleicht sinnvoll. Und wenn es nur deshalb ist, um Flimmern zu vermeiden, was bei oft wechselnder Reihenfolge (durch Cachemisses z.B.) passieren könnte.

Ich denke mal, die kleinste Einheit sind die zusammenhängenden Strips, von denen ein GS ja durchaus mehrere raushauen kann.

[Demirug]

Ich würde davon ausgehen das es in Order bleiben muß aber ich kann ja mal nachfragen. Dauert aber in der Regel immer etwas bis ich eine Antwort bekomme.

[zeckensack]

Coda[/POST]']Du hast die Spec wirklich nicht gelesen (eigentlich bin ich jetzt ziemlich sauer, aber ich behersch mich noch). Das Ding läuft auf R600 auf den genau gleichen ALUs wie PS und VS. Und sehr wohl parallel.

Schön. Mit einem 1zu1 Verhältnis Input/Output kommen wir aber leider nicht weiter.Und die ALUs laufen auch alle mit voller Auslastung, ja?
Das was ich gefettet habe ist das Problem bei der Parallelisierung. Punkt. Ich weiß dass du das auch weißt. Wenn es dafür eine naheliegende Lösung gäbe hätten wir sie schon von AMD und Intel gesehen. Ich bleibe dabei dass GS ein GP-Problem ist. Ja, man muss auch rechnen, aber das ist eben nicht der Flaschenhals.

*seufz*
... Sony hat zB ungefähr das richtige gebaut. Eine SPE taugt IMO sehr gut für GS-Aufgaben, eben weil so ein Ding noch einigermaßen GP-tauglich ist, aber es ist eben auch für andere Zwecke einsetzbar.

Wir werden uns hier wohl kaum einig werden, aber reib's mir gerne nochmal unter die Nase wenn wir Techdemos und Benchmarks auf Hardware haben.Ganz großes Kino. Und wenn wir transformierte Daten für den GS brauchen dann machen wir das auf der CPU auch noch nebenbei.Jaha, wenn ...
Vielleicht ist der Grund dass beim MS-Modell der GS hinter dem VS sitzt nicht der dass es so am nützlichsten ist, sondern weil NVIDIA und ATI die andere Idee schon grinsend abgewunken haben?

Ja, ich weiß auch was das soll: dynamisches LOD durch HOS. Und da war dann jemand der Meinung dass das nur nach der Kameratransformation funktionieren kann. Behalte mir trotzdem vor das für Unsinn zu halten, denn das geht auch weniger kompliziert. Brauchst nur W ausrechnen, ergo ein Skalarprodukt; nix mit transformieren.Ach wieso lassen wir dann den VS nicht auch gleich weg und gehen wieder zu den reinen Rasterizern zurück. Leute gibts...

Ach und Texturfilterung ist auf der CPU ja auch so unglaublich schnell - ich vergaß.ncDas zusammenfällt wie ein Kartenhaus weil es einfach nicht stimmt.Wie gesagt, erinnere mich ruhig daran wenn die Messergebnisse eingetroffen sind.

[StefanV]

Wie schauts eigentlich mit Displacement Mapping a la Parhelia (naja, das was die können sollte) aus??
Wird sowas mit D3D10 möglich sein und vorallendingen ist das auch brauchbar??

[Coda]

zeckensack[/POST]']Und die ALUs laufen auch alle mit voller Auslastung, ja?
Ja.

zeckensack[/POST]']Ich bleibe dabei dass GS ein GP-Problem ist. Ja, man muss auch rechnen, aber das ist eben nicht der Flaschenhals.
Das Ding ist nicht GP (wenn auch deutlich mehr geht als nur mit einem VS). Schau dir doch bitte mal die Spec an.

zeckensack[/POST]']Ja, ich weiß auch was das soll: dynamisches LOD durch HOS. Und da war dann jemand der Meinung dass das nur nach der Kameratransformation funktionieren kann.
Du kannst die komplette Transformation auch im GS machen und einen "Null-Vertexshader" laden. Das erzeugt auch keine andere Last.

[Neomi]

zeckensack[/POST]']Wir werden uns hier wohl kaum einig werden, aber reib's mir gerne nochmal unter die Nase wenn wir Techdemos und Benchmarks auf Hardware haben.Jaha, wenn ...

Auch wenn die erste Generation keinen sonderlich performanten GS hat (wovon ich mal ausgehe, weil es bisher bei vielen Dingen so war in der ersten Generation), heißt das noch lange nicht, daß das Konzept schlecht sei. Sollten Benchmarks mit allem vor der zweiten Generation (Refreshes natürlich nicht als Generation mitgezählt) andeuten, daß der GS nicht praktisch nutzbar sei (was ich nicht glaube), dann laß dich bitte nicht zu verfrühten Urteilen hinreißen.

zeckensack[/POST]']Vielleicht ist der Grund dass beim MS-Modell der GS hinter dem VS sitzt nicht der dass es so am nützlichsten ist, sondern weil NVIDIA und ATI die andere Idee schon grinsend abgewunken haben?

Der VS kann vor dem GS die Ergebnisse von mehrfach genutzten Vertices cachen. Wäre der VS nach dem GS, ginge das dank möglicherweise geänderten Daten (trotz ursprünglich identischem Index) logischerweise nicht mehr. Deshalb müßte man alle Berechnungen, die ein VS nach einem GS machen könnte, für jede neue Nutzung des ursprünglichen Vertex wiederholen, womit die Berechnungen auch gleich im GS ausgeführt werden können. Ein VS nach dem GS wäre absolut sinnlos, vor dem GS kann er eine Menge Redundanz vermeiden.

Coda[/POST]']Du kannst die komplette Transformation auch im GS machen und einen "Null-Vertexshader" laden. Das erzeugt auch keine andere Last.

Nicht ganz, aber so in etwa. Durch einen fehlenden VS würde insgesamt mehr Last entstehen, wenn Vertices mehrfach verwendet werden. Eben dadurch, daß Berechnungen redundant ausgeführt werden müßten. Aber natürlich kann die Transformation auch vollständig im GS geschehen. Zumindest die Projektion muß ja schon zwingend im GS geschehen, wenn man in einem Pass in eine Cubemap rendern will.

[Xmas]

zeckensack[/POST]']Es geht mir nicht um die Nutzung der ALUs, sondern um die nicht streaming-kompatible Aufgabenstellung. Ein GS wird sich nicht mal eben so massiv parallel implementieren lassen wie der Rest einer typischen GPU. Ich glaube nicht dass die Performance irgendjemanden begeistern wird @Coda, wenn wir das überhaupt noch in Hardware erleben.
Es wird wahrscheinlich nie Hardware geben die sich nur dem GS widmet.

Es ist kein Widerspruch. Wenn du die GS-Arbeit mit der CPU machst, und die Ergebnisse in einen dynamischen Vertex Buffer schreibst, hast du doch den Ersatz für dieses fehlende Feature.
Nur deutlich langsamer und verbraucht unnötig Speicherplatz und Bandbreite.

Frag' mal bei ATI an wo das programmierbare Blending bleibt. Gleiches Problem, nur viel weniger schlimm.
Warum muss es ausgerechnet ATI sein? ;)
Programmierbares Blending ist dazu ein völlig anderes Problem.

Demirug[/POST]']Ich würde davon ausgehen das es in Order bleiben muß aber ich kann ja mal nachfragen. Dauert aber in der Regel immer etwas bis ich eine Antwort bekomme.
Muss konzeptionell in Order bleiben, was die Implementierung real tut ist wie immer egal.


zeckensack[/POST]']... Sony hat zB ungefähr das richtige gebaut. Eine SPE taugt IMO sehr gut für GS-Aufgaben, eben weil so ein Ding noch einigermaßen GP-tauglich ist, aber es ist eben auch für andere Zwecke einsetzbar.
Die SPEs haben absolut nichts was sie für GS-Aufgaben besser geeignet macht als Unified Shader in einer GPU. Das einzige Problem des GS, die Serialisierung des Outputs, wird gar nicht angegangen (und es ist auch gar nicht so wichtig, das ist eher eine Frage der verwendeten Datenstrukturen).

[Gast]

Xmas[/POST]']Die SPEs haben absolut nichts was sie für GS-Aufgaben besser geeignet macht als Unified Shader in einer GPU. Das einzige Problem des GS, die Serialisierung des Outputs, wird gar nicht angegangen (und es ist auch gar nicht so wichtig, das ist eher eine Frage der verwendeten Datenstrukturen).
Aber die SPEs kann man auch für andere Sachen nutzen und auslasten.

[Xmas]

Gast[/POST]']Aber die SPEs kann man auch für andere Sachen nutzen und auslasten.
Unified Shader, von denen ich schrieb, ebenso.

[zeckensack]

Xmas[/POST]']Es wird wahrscheinlich nie Hardware geben die sich nur dem GS widmet.Meine These war: ATI und NVIDIA werden sich große Mühe geben so wenig Transistoren wie möglich für GS zu verbrauchen, egal wie.
Nur deutlich langsamer und verbraucht unnötig Speicherplatz und Bandbreite.Wir haben seit einiger Zeit 16x PCIe-Slots standardmäßig für die Grafik. Irgendwann sollte das auch mal jemand benutzen.
Der Speicherplatz ist sowieso weg, ob nun statisch oder dynamisch, irgendwo muss man parken. Und wenn das nächste Stichwort "Kompression" lautet, kommt von mir "Schattenvolumen".
Warum muss es ausgerechnet ATI sein? ;)
Programmierbares Blending ist dazu ein völlig anderes Problem.Es ist viel überschaubarer, weil ein Pixel entweder überschrieben wird oder eben nicht, also nur zwei mögliche Abläufe zu berücksichtigen sind.
Es ist ähnlich weil bei Überlappungen die ursprüngliche Reihenfolge eingehalten werden muss.
Es ist ähnlich weil die Latenz nicht gut vorhersehbar ist.

Ich weiß ja nicht was ihr da oben wieder gezaubert habt, aber NVIDIA und ATI machen wenig Anstalten das zu unterstützen (ich weiß dass 3DLabs es hatte, aber 3DLabs ... war immer sehr ambitioniert, und ist nun nicht mehr relevant, fürchte ich).
Die SPEs haben absolut nichts was sie für GS-Aufgaben besser geeignet macht als Unified Shader in einer GPU. Das einzige Problem des GS, die Serialisierung des Outputs, wird gar nicht angegangen (und es ist auch gar nicht so wichtig, das ist eher eine Frage der verwendeten Datenstrukturen).SPEs haben vollständige Flusskontrolle. Cell-SPEs implementieren eine komplette PPC-ISA (plus Erweiterungen) und sind dadurch vollwertige general purpose-Maschinchen mit Einschränkungen einzig im Speichermodell. Local store eben. Random access ist aber immerhin gewährleistet, und voller Zugriff auf den restlichen Systemspeicher ist über die anhängige DMA-Hardware auch möglich.

[Coda]

zeckensack[/POST]']Meine These war: ATI und NVIDIA werden sich große Mühe geben so wenig Transistoren wie möglich für GS zu verbrauchen, egal wie.
Bei R600 sind VS, GS und PS ein und dasselbe, bei G80 VS/GS zusammen und PS wohl getrennt.

An welcher Stelle willst du denn sparen? Mir fällt nichts ein was nicht auch die Funktionalität beschneiden würde.

zeckensack[/POST]']Es ist ähnlich weil bei Überlappungen die ursprüngliche Reihenfolge eingehalten werden muss.
Was für "Überlappungen"?

zeckensack[/POST]']Es ist ähnlich weil die Latenz nicht gut vorhersehbar ist.
Es geht um interne Caches, da ist das ziemlich schnurz.

zeckensack[/POST]']SPEs haben vollständige Flusskontrolle.
SM4 auch.

[Quasar]

Wurden nicht gerade Shadowvolumes gern als Anwendungsbeispiel für GS angeführt, da diese dann quasi komplett inklusive extrudierter Geometrie auf der GPU laufen könnten, ohne die CPU weiter zu belasten?

Für problematisch halte ich dann allerdings wieder den "US"-Ansatz: Dabei hast du wieder die Wahl: Mache ich mit der zur Verfügung stehenden Leistung lieber Shadowvolumes oder tue ich etwas sinnvolles, wie schöne Pixel zu berechnen anstatt schwarze? ;) Wenn ich nun dedizierte GS-Einheiten habe, die ich nicht für Pixel- oder Vertexoperationen anderweitig nutzen kann, fiele mir die Wahl als Entwickler wieder leichter, glaube ich.

Ich weiß, ist im moment nicht so ganz passend zum Thema, fiel mir aber gerade so ein.

[zeckensack]

Coda[/POST]']Bei R600 sind VS, GS und PS ein und dasselbe, bei G80 VS/GS zusammen und PS wohl getrennt.

An welcher Stelle willst du denn sparen? Mir fällt nichts ein was nicht auch die Funktionalität beschneiden würde.An der Stelle die die GS-Hardware von aktueller VS-Hardware unterscheidet? :rolleyes:
Was für "Überlappungen"?Zwei aufeinanderfolgende Dreiecke können sich (im screen space) überlappen. Egal ob sie aus einem Draw Call kommen oder nicht.

"Normalerweise" ist's w0rscht, aber viele handelsübliche Blending-Modi sind nicht assoziativ, und wenn du den Z-Test mal aus irgendeinem Grund ausschaltest sollte das Ergebnis auch noch korrekt sein.
Es geht um interne Caches, da ist das ziemlich schnurz.Ja wenn das alles so einfach ist, warum gibt's das dann deiner Meinung nach nicht in Hardware? Bedarf gibt's reichlich.SM4 auch."SM4" ist keine Hardware und hat keine messbare Performance. Ein SPE ist und hat. Der Vergleich ist mir zu dünn.
Bei "SM3" waren auch nicht alle theoretischen Möglichkeiten mit maximaler Effizienz implementiert. Skepsis ist hier nicht unvernünftig IMO.

[Gast]

Quasar[/POST]']Wurden nicht gerade Shadowvolumes gern als Anwendungsbeispiel für GS angeführt, da diese dann quasi komplett inklusive extrudierter Geometrie auf der GPU laufen könnten, ohne die CPU weiter zu belasten?

Für problematisch halte ich dann allerdings wieder den "US"-Ansatz: Dabei hast du wieder die Wahl: Mache ich mit der zur Verfügung stehenden Leistung lieber Shadowvolumes oder tue ich etwas sinnvolles, wie schöne Pixel zu berechnen anstatt schwarze? ;) Wenn ich nun dedizierte GS-Einheiten habe, die ich nicht für Pixel- oder Vertexoperationen anderweitig nutzen kann, fiele mir die Wahl als Entwickler wieder leichter, glaube ich.

Ich weiß, ist im moment nicht so ganz passend zum Thema, fiel mir aber gerade so ein.
Vor der Wahl stehen die Entwickler, aber besser Flexibilität für die jeweiligen Projekte, als den Entwicklern deren Lastaufteilung vorzuschreiben.

[aths]

Gast[/POST]']:|Ok, nochmal anders:
Weder Microsoft noch eine Direct3D-Version haben jemals ursächlich dazu geführt dass eine Grafikhardware ein neues Feature bekommen hat. Und es ist absolut naiv jetzt zu erwarten dass sich das ändern wird. Und auch wenn's OT ist, es geht mir auf den Sack dass Microsoft immer soviele Vorschussloorberen und hohlen Respekt bekommt obwohl diese Firma zum technischen Fortschritt nie beiträgt.

Microsoft hat im Prinzip null Plan von Grafik. Die Features die Microsoft selbst einführen wollte sind schlicht an der Realität gescheitert: kubische Texturfilter zB gibt's seit D3D 5 oder so, "vertex texture fetch" dürfte dir auch noch ein Begriff sein, und ich muss ganz klar sagen dass weder Bitoperationen noch ein Geometry Shader in eine Grafikhardware hineingehören. Das ist sinnloses Säbelgerassel und wird aller Wahrscheinlichkeit nach wieder genau so enden wie "vertex texture fetch", nämlich mit erschummelten Pseudo-Implementierungen und praktischer Irrelevanz.Mit Bitoperationen lassen sich endlich eigene Texturformate implementieren.

Wenn man C-Code auf einer GPU ausführen möchte, ist man mit Bitoperationen auch viel flexibler. Wahrscheinlich fragst du dich genauso wie ich, warum zum Geier man versuchen sollte, C auf GPU laufen zu lassen, wo es längst auf CPUs läuft. Ich finde, man sollte dann einfach mal gucken, was man damit sinnvolles machen kann.

Gast[/POST]']Ohne ATI und NVIDIA könnte Microsoft Direct3D gar nicht mehr machen. Ohne ATI und NVIDIA kann es keine neuen Hardware-Features im Windows-Grafikmassenmarkt geben. So herum sind die Machtverhältnisse. Wer denkt Microsoft könnte da irgendetwas steuern hat salopp gesagt nicht mehr alle Tassen im Schrank.Hätte es ohne Microsoft diese einheitliche SM3-Definition (zumindest auf dem Papier) gegeben? Ohne MS würden ATI und NV vermutlich lustig weiter ihre Smartshader bzw. CineFX-Shader weiterentwickeln und absichtlich inkompatible Features schaffen oder mit Verweisen auf Patente darauf achten, dass der Konkurrenz ja nicht Feature XYZ anbietet.

[aths]

zeckensack[/POST]']Sag' mir was du damit vorhast, und ich sage dir warum du ohne VTF besser (schneller) dran bist. Zu 99%.Ist mit VTF Vertex-Texturing gemeint? Ich finde es gut, wenn man vom VS aus Texturen samplen kann – wobei mir eingebaute trilineare Filterung natürlich lieber wäre, als Pointsampling mit MIP-Mapping. Ich finde es deshalb gut, weil man es dann einfach machen kann – ob ein Effekt damit nun schneller wird oder nicht.

zeckensack[/POST]']Jawoll. Du hast mir gesagt die IHVs haben Features bei Microsoft bestellt. Ich habe dich gefragt was du mir damit sagen wolltest. Das ist mir jetzt auch noch nicht klar.
Die IHVs müssen, da ja die Könige 1)Kunde und 2)verwöhnter Developer von Welt davon überzeugt wurden dass Direct3D relevant ist, mit Microsoft zusammenarbeiten, damit die Features die sie sowieso wollen und einbauen werden auch über diese API offengelegt werden können. Microsoft freut's, weil man nochmal so richtig schön einen auf dicke Hose machen kann.Interessanterweise spielen ATI und NV das Spiel mit. Die sagen immer, man solle MS fragen, denn MS definiere die Schnittstelle und so.

[Coda]

Quasar[/POST]']Für problematisch halte ich dann allerdings wieder den "US"-Ansatz: Dabei hast du wieder die Wahl: Mache ich mit der zur Verfügung stehenden Leistung lieber Shadowvolumes oder tue ich etwas sinnvolles, wie schöne Pixel zu berechnen anstatt schwarze? ;) Wenn ich nun dedizierte GS-Einheiten habe, die ich nicht für Pixel- oder Vertexoperationen anderweitig nutzen kann, fiele mir die Wahl als Entwickler wieder leichter, glaube ich.
Dann würde man unglaublich viel Transistoren dafür opfern ALUs einzubauen die nur in manchen Fällen laufen (sowohl für VS als auch GS).

zeckensack[/POST]']An der Stelle die die GS-Hardware von aktueller VS-Hardware unterscheidet? :rolleyes:
Ließ die Spec. Die Ops sind die gleichen, und an den Buffern kann man kaum sparen.

zeckensack[/POST]']Ja wenn das alles so einfach ist, warum gibt's das dann deiner Meinung nach nicht in Hardware?
Man braucht unified shader (zumindest zwischen VS und GS) und einige Transistoren dazu.

[Gmax]

Gibt da zwei int. Artikel bei Extremetech.
The People Behind DirectX 10:

Part 1 Microsoft (http://www.extremetech.com/article2/0,1697,1982031,00.asp)

Part 2 ATI's Bob Drebin (http://www.extremetech.com/article2/0,1697,1985149,00.asp)

[ShadowXX]

Coda[/POST]']Dann würde man unglaublich viel Transistoren dafür opfern ALUs einzubauen die nur in manchen Fällen laufen (sowohl für VS als auch GS).

Interesannterweise scheint das nV aber nicht weiter zu stören.

Wenn die Gerüchet halbwegs war sind und wir beim G80 32 PS bekommen und noch dazu 16 VS/GS....

(Mit dieser Konfiguration wird wohl sogar dieser Einwand:

Vor der Wahl stehen die Entwickler, aber besser Flexibilität für die jeweiligen Projekte, als den Entwicklern deren Lastaufteilung vorzuschreiben.

ad acta gelegt.....)

[Coda]

ShadowXX[/POST]']Interesannterweise scheint das nV aber nicht weiter zu stören.
Wieso? GS und VS sind doch unified. :|

[ShadowXX]

Coda[/POST]']Wieso? GS und VS sind doch unified. :|
Ja, aber die PS sind einzeln und dadurch kostet es (wohl) mehr Transistoren, als wenn es vollständig unified wäre.

[Demirug]

ShadowXX[/POST]']Ja, aber die PS sind einzeln und dadurch kostet es (wohl) mehr Transistoren, als wenn es vollständig unified wäre.

Relative und genau das ist ja der Knackpunkt bei der Sache. Es ist davon auszugehen das bei gleicher Chipfläche ohne US Design mehr Rechenleistung auf den Chip gebracht werden kann. Das US Design wird allerdings abhängig von der Situation die Leistung effektiver nutzten.

[Gast]

Demirug[/POST]']Aus dem gleichen Grund aus dem D3D9 in PC Spielen genutzt wurde obwohl die Konsolen bestenfalls auf D3D8 Level waren?

die konnte man vor der 360 mit dem mikroskop und jetzt mit der lupe suchen. die r300 wurde zu xbox-zeiten vielleicht von hl2 und fc genutzt, das wars dann auch schon. die konsolen sind immer der hemmer, da es meist ports gibt. alles drüber ist für techdemos

[Demirug]

zeckensack[/POST]']Frag' mal bei ATI an wo das programmierbare Blending bleibt. Gleiches Problem, nur viel weniger schlimm.

Frag mal nVidia: "We don't talk about unannounced products"

Scheinbar will man dort wegen der Forderung 32 Bit Blending für D3D 10.1 die ROPs loswerden und die Funktion mit in den Shaderkern packen.

[TheGamer]

Coda[/POST]']Das ist gelogen. Microsoft hat einige sehr fähige Leute in der Grafikabteilung.


Ich glaube das war später. Features werden nur eingeführt wenn ein IHV danach verlangt. Die Intel GMA-Chips können es.


Ja und? Was ist daran falsch?


Gibts dafür auch Begründungen? Ich bin äußerst froh über beides.


Richtig. Und alle von dir genannten Features wurden von den IHVs bei Microsoft "bestellt" und nicht andersrum


Irgendwie zweifel ich daran bei solch einem Post.

Hat das jetzt zeckensack geschrieben als gast oder wie?

[Gast]

Gast[/POST]']die konnte man vor der 360 mit dem mikroskop und jetzt mit der lupe suchen. die r300 wurde zu xbox-zeiten vielleicht von hl2 und fc genutzt, das wars dann auch schon. die konsolen sind immer der hemmer, da es meist ports gibt. alles drüber ist für techdemos

für die konsolen brauchst du sowieso einen eigenen renderpfad, da ist die API dann relativ egal.

[Xmas]

zeckensack[/POST]']Meine These war: ATI und NVIDIA werden sich große Mühe geben so wenig Transistoren wie möglich für GS zu verbrauchen, egal wie.
Bei ausreichender Leistung. Genauso wie sie es für PS und VS machen. GS werden mindestens schon mal so schnell sein dass Point Sprites nicht zum Flaschenhals werden.

Wir haben seit einiger Zeit 16x PCIe-Slots standardmäßig für die Grafik. Irgendwann sollte das auch mal jemand benutzen.
Der Speicherplatz ist sowieso weg, ob nun statisch oder dynamisch, irgendwo muss man parken. Und wenn das nächste Stichwort "Kompression" lautet, kommt von mir "Schattenvolumen".
Ich weiß jetzt nicht was du mit letzterem genau meinst. Der Speicherplatz ist nur dann weg wenn der GS-Output nicht mehr in On-Chip-Buffer passt (und bei einem DR spart man bei den Vertex Buffern). Warum sollte man die Geometrie auf der CPU erzeugen wenn der GS das schneller kann?

Es ist viel überschaubarer, weil ein Pixel entweder überschrieben wird oder eben nicht, also nur zwei mögliche Abläufe zu berücksichtigen sind.
Es ist ähnlich weil bei Überlappungen die ursprüngliche Reihenfolge eingehalten werden muss.
Es ist ähnlich weil die Latenz nicht gut vorhersehbar ist.

Ich weiß ja nicht was ihr da oben wieder gezaubert habt, aber NVIDIA und ATI machen wenig Anstalten das zu unterstützen (ich weiß dass 3DLabs es hatte, aber 3DLabs ... war immer sehr ambitioniert, und ist nun nicht mehr relevant, fürchte ich).
Es hat nichts mit Zauberei zu tun im Voraus zu wissen in welcher Reihenfolge Pixel gerendert werden müssen.
Der Unterschied bei Pixeln ist dass jene überschrieben werden, die Triangle-Strips des GS-Outputs jedoch nicht. Die Latenz ist vorhersehbar weil die maximale Anzahl an Ausgabewerten pro GS-Durchlauf bekannt (und limitiert) ist.

SPEs haben vollständige Flusskontrolle. Cell-SPEs implementieren eine komplette PPC-ISA (plus Erweiterungen) und sind dadurch vollwertige general purpose-Maschinchen mit Einschränkungen einzig im Speichermodell. Local store eben. Random access ist aber immerhin gewährleistet, und voller Zugriff auf den restlichen Systemspeicher ist über die anhängige DMA-Hardware auch möglich.
Shader können vollständige Flusskontrolle haben. Das Speichermodell ist üblicherweise eingeschränkt, Random Access gibts nur lesend auf Texturen, aber mehr braucht man für die üblichen Shader-Anwendungen (inklusive GS) ja auch normalerweise nicht.

[PCGH_Carsten]

Demirug[/POST]']Frag mal nVidia: "We don't talk about unannounced products"

Scheinbar will man dort wegen der Forderung 32 Bit Blending für D3D 10.1 die ROPs loswerden und die Funktion mit in den Shaderkern packen.
Langfristig natürlich toll, genauso wie der Ansatz, möglichst homogene Einheiten zu verwenden.

Aber bis dahin dürfte es noch ein weiter Weg sein, oder?

[phil99]

Was haltet ihr von dem Artikel, der besagt, dass D3D10 die nächsten 3 Jahre bestenfalls als Zusatzfeature genutzt wird ?
Der Artikel steht auf der Hauptseite.
ORiginal ist er von einer englischen Seite und wurde übernommen.
Ich frage mich ausserdem, warum ein so kleines Unternehmen wie Crytech, welches nach eigenen Aussagen kein Geld mit Farcry verdient hat nachträglich so viel Sachen einbaut.
Ich habe Farcry 3 mal durchgespielt und ehrlich gesagt hat mir das HDR-Rendering zwar gefallen, aber ich habs 10 min angeschaut und gemerkt, dass ich auf einer hohen Schwierigkeitsstufe davon derart benachteiligt bin, dass ich es nie geschafft hätte auf höchster Stufe mit der ganzen Blenderei.
Und Windows 64bit habe ich nicht extra installiert, weil es ja immer noch zu Schwierigkeiten kommt, ober sind die abgeschafft.
Bin nämlich die ganze Zeit schon am Überlegen das mal zu testen.

[TheGamer]

phil99[/POST]']Was haltet ihr von dem Artikel, der besagt, dass D3D10 die nächsten 3 Jahre bestenfalls als Zusatzfeature genutzt wird ?
Der Artikel steht auf der Hauptseite.
ORiginal ist er von einer englischen Seite und wurde übernommen.
Ich frage mich ausserdem, warum ein so kleines Unternehmen wie Crytech, welches nach eigenen Aussagen kein Geld mit Farcry verdient hat nachträglich so viel Sachen einbaut.
Ich habe Farcry 3 mal durchgespielt und ehrlich gesagt hat mir das HDR-Rendering zwar gefallen, aber ich habs 10 min angeschaut und gemerkt, dass ich auf einer hohen Schwierigkeitsstufe davon derart benachteiligt bin, dass ich es nie geschafft hätte auf höchster Stufe mit der ganzen Blenderei.
Und Windows 64bit habe ich nicht extra installiert, weil es ja immer noch zu Schwierigkeiten kommt, ober sind die abgeschafft.
Bin nämlich die ganze Zeit schon am Überlegen das mal zu testen.

Ich hatte vor nem halben Jahr keine Probleme damit