Geometry Shader gestrichen?

[TheCounter]

Hallo auch :)

Grad mal wieder meine Gamestar (;)) bekommen und da ist mir ein kleiner "Artikel" aufgefallen:

Shader Model 4.0 - Kastriert?

Offenbar hat Microsoft das kommende Shader Model 4.0 stark kastriert. In der Ausgabe 02/2005 haben wir berichtet, ein dritter Shader-Typ namens Geometry Shader würde die bekannten Pixel und Vertex Shader ergänzen. Das war auch so geplant - aber nach unseren neusten Informationen strich Microsoft das clevere Feature zum Ärger von ATI und NVIDIA aus den Spezifikationen. Der Geometry Shader wäre die größte technische Neuerung der letzten 3D-Jahre geworden: Mit ihm hätten Spiele-Entwickler Welten dynamisch ändern und endlich Displacement Mapping effizient einsetzen können. Das letzte Wort scheint allerdings noch nicht gesprochen - wir halten Sie auf dem laufenden.

Ist das korrekt das Microsoft das ganze gestrichen hat (Hat also jemand etwas davon gehört)? Oder erzählt die Gamestar nur mal wieder Schmu?

[tombman]

Was soll das denn sein? In Zukunft wird es keine Einteilung mehr geben in vertex und pixel shader, und die Lasten werden dynamisch verteilt, je nachdem was gebraucht wird. Shader sind ja auch nur kleine Programme...

[Coda]

Tombman, Vertexshader können keine neuen Vertices erzeugen sondern nur bestehende verändern.
Der "Geometry Shader" kann auch neue Geometrie erzeugen, das hat nix mit unified shader zu tun.

In Zukunft wird es keine Einteilung mehr geben in vertex und pixel shaderAuf der API Seite wird das sehr wohl so sein, nur die Hardware kann es sich aufteilen.

Ist das korrekt das Microsoft das ganze gestrichen hat (Hat also jemand etwas davon gehört)? Oder erzählt die Gamestar nur mal wieder Schmu?Ich kann's mir irgendwie nicht vorstellen. Außerdem gibt es gar kein "SM 4.0".

[TheCounter]

Ich kann's mir irgendwie nicht vorstellen. Außerdem gibt es gar kein "SM 4.0".

Ja, wurde schon öfters hier erwähnt. Aber der normale Gamestar leser kennt eben nur die Bezeichnung SM4.0 ;)

Die Hauptfrage ist nach wie vor, ist da was dran oder ist es einfach nur ein Märchen...

[Coda]

Vielleicht haben sie das mit WGF 1.0 und 2.0 wieder in den falschen Hals bekommen.
WGF 1.0 hat ja keine "Geometry Shader", weil es einfach nur DX9 für Longhorn ist.

[TheCounter]

Vielleicht haben sie das mit WGF 1.0 und 2.0 wieder in den falschen Hals bekommen.
WGF 1.0 hat ja keine "Geometry Shader", weil es einfach nur DX9 für Longhorn ist.

Das wär ne Möglichkeit. Aber wieso schreiben die dann "nach unseren neusten Informationen strich Microsoft das clevere Feature zum Ärger von ATI und NVIDIA aus den Spezifikationen". Also entweder sie haben bei NVIDIA/ATi nachgefragt oder erfinden einfach was dazu.

[Demirug]

MS selbst hat schon letztes Jahr behauptet das die Hardwarespec "almost crystallized" wäre. Das setzt vorraus das intensive Gespräche mit den IHV geführt wurden. Auch das bestätigt MS: "designed hand-in-hand with IHVs".

Aus diesem Hintergrund erscheint es sehr unlogisch zu schreiben das MS jetzt ein Feature entfernt und gleichzeitig zu behaupten das sich ATI und nVidia darüber ärgern. Es macht aus der Sicht von MS keinen Sinn Features zu entfernen ausser ein IHV sagt das er es auf keinen Fall hinbekommt. Die Frage ist lediglich wie viel Rücksicht nimmt MS auf die Kleinen.

[Tigerchen]

MS selbst hat schon letztes Jahr behauptet das die Hardwarespec "almost crystallized" wäre. Das setzt vorraus das intensive Gespräche mit den IHV geführt wurden. Auch das bestätigt MS: "designed hand-in-hand with IHVs".

Aus diesem Hintergrund erscheint es sehr unlogisch zu schreiben das MS jetzt ein Feature entfernt und gleichzeitig zu behaupten das sich ATI und nVidia darüber ärgern. Es macht aus der Sicht von MS keinen Sinn Features zu entfernen ausser ein IHV sagt das er es auf keinen Fall hinbekommt. Die Frage ist lediglich wie viel Rücksicht nimmt MS auf die Kleinen.

Vielleicht möchte Microsoft Rücksicht auf integrierte Lösungen nehmen und sieht Extra-Grafikkarten nicht mehr als so relevant für mit langfristige Zukunft an. Ist vielleicht ganz sinnvoll die Features mal zu begrenzen. Schon allein damit die IHV's mal liefern können anstatt immer nur zu entwickeln und anzukündigen. Ich bin sehr unzufrieden mit der Situation.

[collapse]

man kans auch so sehen das sie es erst in paar jahren mit dem nachfolger von longhorn bringen wollen da sie es markteschnisch wieder einen kaufzwang hätten :(

[Ailuros]

MS trifft tatsaechlich solche Entscheidungen AFAIK nicht alleine, und schon gar nicht "zum Aerger" von ATI/NVIDIA. Entweder einer der beiden Grossen oder auch beide haben sich vielleicht vor einiger Zeit ueber die Tesselations-Einheit beschwert und daher ist sie wohl auch in den Spezifikationen vorhanden, aber eben als optionale Einheit.

Dass der GS angeblich gestrichen wurde, lese ich zum ersten Mal.

Die Frage ist lediglich wie viel Rücksicht nimmt MS auf die Kleinen.

Wuerden sich alle Kleine darueber beschweren?

[Coda]

Vielleicht möchte Microsoft Rücksicht auf integrierte Lösungen nehmenWGF 2.0 wird so schnell sicherlich von keiner integrierten Lösung unterstützt werden.

Ist vielleicht ganz sinnvoll die Features mal zu begrenzen. Was ein Ranz.

Schon allein damit die IHV's mal liefern können anstatt immer nur zu entwickeln und anzukündigen.Was hat z.B. ATi denn entwickelt in letzter Zeit? :|

Mehr Pipelines hat ja wohl nix mit den Features zu tun.

[Ailuros]

WGF2.0 wird in HW sowieso nicht vor dem 2.Halbjahr 2006 auftauchen. Von dem abgesehen soll WGF2.0 genauso viel aushalten wie DX9.0 (>4 Jahre).

[Demirug]

Vielleicht möchte Microsoft Rücksicht auf integrierte Lösungen nehmen und sieht Extra-Grafikkarten nicht mehr als so relevant für mit langfristige Zukunft an. Ist vielleicht ganz sinnvoll die Features mal zu begrenzen. Schon allein damit die IHV's mal liefern können anstatt immer nur zu entwickeln und anzukündigen. Ich bin sehr unzufrieden mit der Situation.


Das wiederspricht sich jetzt aber ein wenig. Wenn man auch Rücksicht auf integrierte Lösungen Features streicht welche Grafikkarten bringen könnten können diese nicht irrelevant werden. Eine integrierte WGF 2.0 Lösung erwarte ich sowieso nicht so bald. Dort wird man sich auf WGF 1.0 Beschränkungen was für das Longhorn Logo reichen wird.

In wie fern halten API Features die IHVs vom liefern ab? Im Mainstreamsegment kann ich die Karten mit den aktuellen Features doch kaufen? Highend ist problematisch wobei da ja die IHVs behaupten das würde an der ungewöhnlich starken Nachfrage liegen.

WGF steht nun mal in Konkurrent zu OpenGL und da muss MS bemühmt sein die Entwickler bei der Stange zu halten. Das streichen von Features kann daher nur aus zwei Gründen erfolgen. MS kann es nicht implementieren (was bei API designs schwerlich zutreffen wird) oder die Hardwarehersteller machen nicht mit.

[Demirug]

Wuerden sich alle Kleine darueber beschweren?

Der Geometryshader ist ja laut den Unterlagen Plicht in WGF. Jeder IHV der keinen hat hätte auch keine WGF Hardware. Das wäre also durchaus ein Grund sich zu beschweren. Allerdings erscheint es mir merkwürdig das ein IHV erst dermassen spät damit kommt. Das würde bedeuten das da entweder eine Plannung völlig den in die Hose gegangen ist oder das es einen neuen Mitspieler gibt.

[ShadowXX]

.... oder das es einen neuen Mitspieler gibt.

Damit der Text des GS überhaupt einen Sinn ergibt, müsste genau dieser Fall zutreffen.

Denn nur dann würden sich ATI und nV gleichermassen über die Streichung ärgern....Sie haben es und der unbekannte Dritte nicht.

Aber wer zum Teufel sollte das sein, das MS vor ihnen "kuscht" und dazu noch ATI und nV verärgert?

PVR schliesse ich da eigentlich mal aus, da diese wohl nicht "gross" genug für sowas sind.....

Und jemand anders fällt mir überhaupt nicht ein.........

Von dieser Speku mal abgesehen, gehe ich allerdings auch davon aus, das die GS das "WGF1 und WGF2"-Ding in den falschen Hals bekommen haben.

[Birdman]

Als dritter Hersteller könnte ich mir höchstens Intel vorstellen, die ihre onboard Chips sonst nicht auf WGF kriegen und damit ohne "Designed for Windows Longhorn" Logo dastehen würden.

[Demirug]

Als dritter Hersteller könnte ich mir höchstens Intel vorstellen, die ihre onboard Chips sonst nicht auf WGF kriegen und damit ohne "Designed for Windows Longhorn" Logo dastehen würden.

Dafür reicht WGF 1.0 und das sollten aktuelle Intelchipsätze schon erreichen. Zudem dürfte Intel auch bei den Gesprächen zu WGF 2.0 mit am Tisch gewesen sein.

[StefanV]

Als dritter Hersteller könnte ich mir höchstens Intel vorstellen, die ihre onboard Chips sonst nicht auf WGF kriegen und damit ohne "Designed for Windows Longhorn" Logo dastehen würden.
Nein, gibt eigentlich nur 2 weitere Kandidaten:

a) Matrox
b) PowerVR

VIA/S3 und XGI scheiden eigentlich aus, da die bei WGF2.0 schon dabei gewesen sein dürften.

Eine weitere Möglichkeit wäre 'something new'...

[gästehasser]

Nein, gibt eigentlich nur 2 weitere Kandidaten:

a) Matrox
b) PowerVR

VIA/S3 und XGI scheiden eigentlich aus, da die bei WGF2.0 schon dabei gewesen sein dürften.

Eine weitere Möglichkeit wäre 'something new'...

Bitboys?

[Tortenheber]

An PowerVR glaube ich schon mal gar nicht. Von denen hört und sieht man nix. Nach den unerfüllten Hoffnungen letztes Jahr kommt da auch nichts mehr.

Matrox wäre vielleicht ein Kandidat aber da sie mit der Parhelia zumindest einen Quasi-DX9 Chip haben und (vorläufig?) nicht in den Spielerbereich zurückkehren wollen/werden, dürfte sie ein fehlendes WGF 2.0 Siegel eher wenig stören. Für den Einsatzbereich wo Matrox operiert, brauchen sie eigentlich nicht.

S3 und XGI sollten WGF2.0 hinkriegen, falls nicht, haben beide nicht genügend Marktmacht um MS zu einer Streichung zu "zwingen".

Bleibt eigentlich nur noch Intel. Inwiefern WGF2.0 mit integrierten Grafikchips alleine schon transistormäßig zu realisieren ist, weiß ich nicht. Falls es _ohne_ die Geometry Shader gerade so geht, kann ich mir schon vorstellen, dass es MS aufgrund Intels Marktmacht streicht.

Es könnte natürlich sein, dass es _im Moment_ für integrierte Grafik noch nicht geht und MS es erstmal aussen vor lässt, unter entsprechenden Vorraussetzungen (vielleicht Produktionsprozess für Chipsätze muss 90nm oder kleiner sein damit es reinpasst) es aber wieder "offiziell" aufnimmt.

[Ailuros]

Ein theoretischer "neuer" Spieler der bei der WGF2.0-Festlegung mitgespielt haette, waere uns wohl schon bekannt; im sehr geringen Gegenfall waere es eine Stimme gegen die Mehrzahl. Wieviel Einfluss haette diese Stimme denn ueberhaupt?

Es könnte natürlich sein, dass es _im Moment_ für integrierte Grafik noch nicht geht und MS es erstmal aussen vor lässt, unter entsprechenden Vorraussetzungen (vielleicht Produktionsprozess für Chipsätze muss 90nm oder kleiner sein damit es reinpasst) es aber wieder "offiziell" aufnimmt.

Extreme Graphics 2 duerfte schon verdammt nahe an WGF1.0 Komplianz liegen (und ich sage nur verdammt nahe, weil dem Ding ja die VS fehlen AFAIK).

Falls WGF2.0 tatsaechlich irgendwo im 2. Halbjahr 2006 auftaucht, wuerde ich vor 2008 oder spaeter keinen integrierten chip mit relevanter Technologie erwarten; ganz einfach weil die Vorraussetzungen fuer solche Komplianz viel zu hoch sind und das Ganze vorruebergehen schwer in einen integrierten chip reinpassen wird.

Wo sind die SM3.0 integrierten chips ueberhaupt? Die Relation sollte helfen.

[Demirug]

Extreme Graphics 2 duerfte schon verdammt nahe an WGF1.0 Komplianz liegen (und ich sage nur verdammt nahe, weil dem Ding ja die VS fehlen AFAIK).

Ja, dem Ding fehlt sogar das HT&L und Intel emuliert es auch nicht im Treiber. Soweit mir beakannt ist der Vertexbereich aber nicht so wichtig für WGF 1.0 Komplianz.

[Ailuros]

Ja, dem Ding fehlt sogar das HT&L und Intel emuliert es auch nicht im Treiber. Soweit mir beakannt ist der Vertexbereich aber nicht so wichtig für WGF 1.0 Komplianz.

Intel haelt anscheinend generell nichts von Geometrie:

http://www.beyond3d.com/forum/viewtopic.php?t=19847

[zompel]

Ich habe zwar keine Ahnung von den technischen Specs des Chips, aber könnte es nicht evtl. auch 3DLabs sein??
Da sie ja zu Creative Labs gehören, hätten sie zumindest finanziell auch die nötigen Ressourcen um zu den Global Playern aufzuschließen, denke ich zumindest. :confused:

[Coda]

Irgendwie halte ich das zu 90% für ein Gerücht, somit ist es meiner Meinung nach auch ziemlich sinnlos zu diskuttieren wer es denn sein könnte ;)

[seahawk]

Ich denke mal es ist wieder ne typische Falschmeldung, aber eigentlich kann ich mir nur eine Variante vorstellen.

Die XBOX2 wird das Feature nicht haben. MS könnte ein Interesse daran haben, dass Spiele zwischen PC und Konsole leicht protierbar bleiben und, dass die Konsole nicht zu schnell einen deutlich sichtbaren optischen Nachteil bekommt.

[ShadowXX]

Ich denke mal es ist wieder ne typische Falschmeldung, aber eigentlich kann ich mir nur eine Variante vorstellen.

Die XBOX2 wird das Feature nicht haben. MS könnte ein Interesse daran haben, dass Spiele zwischen PC und Konsole leicht protierbar bleiben und, dass die Konsole nicht zu schnell einen deutlich sichtbaren optischen Nachteil bekommt.

Auch eine Idee....allerdings würde sich MS damit teilweise selbst (bzw. WGF 2.0 als Schnittstelle) ins Bein schiessen.

ATI und nV werden den Geometrie-Shader wohl kaum mal so eben wieder aus den fertigen (bzw. fast fertigen) Designs rausnehmen....

OK, würde dann nicht mit WGF funktionieren, aber für OGL könnte die beiden
Extensions bringen, womit man das ganze dann doch nutzen kann....

Und da Programmierer verspielt sind, würde bestiimt der eine oder andere anfangen seine Engine auf OGL umzustricken/neu zu entwickeln. Und wenn dann die ersten Games damit rauskommen und dann auch noch wesentlich besser dank per ogl ansprechbaren geometrie-shader aussehen, könnte dies MS ein paar Developer kosten, die sonst immer nur DX/WGF benutzt haben....

Das wäre bestimmt nicht in MS's interesse, die ja am liebsten schon bei XP OGL rausgeschmissen hätten (bei Longhorn haben Sie den Versuch ja noch mal gestartet...)

MS ist sich sehr wohl bewusst, dass PCs mit WIndows sehr häufig als Game-Maschinen "eingesetzt" werden. Wenn nun viele anfangen in OGL zu Proggen, weil WGF nicht alle Features der Chips anbieten kann, könnte es auch passieren, das viele Anfangen gleich für Linux mit zu Entwickeln.
Das würde MS auf die dauer durchaus ein paar Kunden kosten und was viel schlimmer aus sicht von MS wäre...es wäre ein Kontrollverlust, jedem der Linux benutzt, kann nicht mehr so sehr auf die Finger geguckt werden...

[Coda]

MS kann OpenGL gar nicht "rausschmeißen". Der Treiber bringt die DLL mit und fertig, ist z.Z. auch nicht anders.

Das einzige was MS bei XP macht ist, dass sie keine OpenGL fähigen Treiber mitliefern.

[Demirug]

MS kann OpenGL gar nicht "rausschmeißen". Der Treiber bringt die DLL mit und fertig, ist z.Z. auch nicht anders.

Das einzige was MS bei XP macht ist, dass sie keine OpenGL fähigen Treiber mitliefern.

Die OpenGL32.DLL kommt immer noch von MS.

[1913]

Könnte doch sein das ATI M$ überzeugt hat, das es keinen Sinn macht Geometrieshader jetzt schon einzuführen, weil die Möglichkeit nicht in die XBOX2 eingebaut werden konnte, bei Retailkarten hängt ATI Technologisch hinter her, begründet das damit das man nicht genug Power für SM3 hat und deshalb wartet. M$ bremst also die Entwicklung und NV hat vieleicht daraufhin einen Chip auf Eis gelegt, und könnte nun vieleicht per "Cell" Technologie die Next Gen etwas aufbohren.

[Coda]

Die OpenGL32.DLL kommt immer noch von MS.Uhm stimmt sogar. Wie funktioniert dass dann? Gibt's da nen Treiberinterface von Microsoft?

Naja die Grafikkartenhersteller könnten trotzdem ihre eigene mitliefern.

[Demirug]

Uhm stimmt sogar. Wie funktioniert dass dann? Gibt's da nen Treiberinterface von Microsoft?

Naja die Grafikkartenhersteller könnten trotzdem ihre eigene mitliefern.

Ja, die OpenGL32.DLL lädt die passenden OpenGL DLL die zur entsprechnenden Karte gehört. Dann werden die Aufrufe dorthin umgebogen.

[Liszca]

Hallo auch :)

Grad mal wieder meine Gamestar (;)) bekommen und da ist mir ein kleiner "Artikel" aufgefallen:

Shader Model 4.0 - Kastriert?

Offenbar hat Microsoft das kommende Shader Model 4.0 stark kastriert. In der Ausgabe 02/2005 haben wir berichtet, ein dritter Shader-Typ namens Geometry Shader würde die bekannten Pixel und Vertex Shader ergänzen. Das war auch so geplant - aber nach unseren neusten Informationen strich Microsoft das clevere Feature zum Ärger von ATI und NVIDIA aus den Spezifikationen. Der Geometry Shader wäre die größte technische Neuerung der letzten 3D-Jahre geworden: Mit ihm hätten Spiele-Entwickler Welten dynamisch ändern und endlich Displacement Mapping effizient einsetzen können. Das letzte Wort scheint allerdings noch nicht gesprochen - wir halten Sie auf dem laufenden.

Ist das korrekt das Microsoft das ganze gestrichen hat (Hat also jemand etwas davon gehört)? Oder erzählt die Gamestar nur mal wieder Schmu?

ich nehme mal an das es hoffentlich einfach nur wichtigtuerrei seitens der gamestar ist, und hoffentlich nicht so bleibt, sprich das ati und nv dafür sorgen dass es anders kommt.

p.s. gamestar ist in solcher hinsicht genauso informative wie die bäckerin... ;D

[Narrenkönig]

Könnte doch sein das ATI M$ überzeugt hat, das es keinen Sinn macht Geometrieshader jetzt schon einzuführen, weil die Möglichkeit nicht in die XBOX2 eingebaut werden konnte, bei Retailkarten hängt ATI Technologisch hinter her, begründet das damit das man nicht genug Power für SM3 hat und deshalb wartet. M$ bremst also die Entwicklung und NV hat vieleicht daraufhin einen Chip auf Eis gelegt, und könnte nun vieleicht per "Cell" Technologie die Next Gen etwas aufbohren.
ATi hat ja auch schon Erfahrung als Technologiebremse.
[verschwörungsmode]DX9 hat MS ja auch kurzfristig auf bitten ATi´s verändert, damit die FXen schlecht darstehen. Seit nV den Preis für den nv2A nicht senken wollte mögen die sich nicht mehr.

[HellHorse]

und könnte nun vieleicht per "Cell" Technologie die Next Gen etwas aufbohren.
Sogar Sony ist mittlerweile aufgefallen, dass "Cell" als Grafikkarte nix taugt und das will was heissen. Immerhin wissen die mehr über "Cell" als wir alle zusammen, geben Fehlentscheide sehr ungern zu (wer nicht?) und bauen stark auf das "Hardware nur für's Gamen gemach, blah blub"-Marketing.

[Coda]

Sogar Sony ist mittlerweile aufgefallen, dass "Cell" als Grafikkarte nix taugtKommt drauf an für welchen Teil. Als Vertexshader würde sich das Ding sicher gar nicht so schlecht machen.

[Ailuros]

Kommt drauf an für welchen Teil. Als Vertexshader würde sich das Ding sicher gar nicht so schlecht machen.

Kein Einwand, nur hockt aber leider der VS auf der falschen Seite des Buses. Ich hab keine Ahnung was genau SONY mit dem Ding vorhat und wie NVIDIA's IP genau in die ganze Logik reinpassen soll.

Falls es sich dann ueberhaupt ueber eine Architektur handelt wo ein Geometrie Shader oder PPP eventuell sogar mitspielt, will ich hoffen dass man sich nicht ausschliesslich fuer VS auf die CPU verlassen will.

[Coda]

Naja wenn Cell wirklich solch eine brachiale Streamleistung entfesselt sollte das "nebenher" gehen :)

[Ailuros]

Naja wenn Cell wirklich solch eine brachiale Streamleistung entfesselt sollte das "nebenher" gehen :)

Ich will endlich on chip adaptive Tesselation sehen und nicht irgendwelchen "nebenher" Schnickschnack....darf ich jetzt bitte weitertraeumen? :D

[Tigerchen]

ATi hat ja auch schon Erfahrung als Technologiebremse.
[verschwörungsmode]DX9 hat MS ja auch kurzfristig auf bitten ATi´s verändert, damit die FXen schlecht darstehen. Seit nV den Preis für den nv2A nicht senken wollte mögen die sich nicht mehr.

Wo hast du denn den Unfug her?
nV wollte FP16 und ATI FP24 und jeder hat gekriegt was er wollte.
Daß die nV Serie nix taugt ist alleine nV's Schuld und hat mit Verschwörung nichts zu tun. Damit ist dein ganzer Einwand absolut im falschen Thread gelandet. Wenn du das weiter diskutieren willst dann mach ein neues Faß auf.

[Narrenkönig]

Wo hast du denn den Unfug her?
nV wollte FP16 und ATI FP24 und jeder hat gekriegt was er wollte.
Daß die nV Serie nix taugt ist alleine nV's Schuld und hat mit Verschwörung nichts zu tun. Damit ist dein ganzer Einwand absolut im falschen Thread gelandet. Wenn du das weiter diskutieren willst dann mach ein neues Faß auf.

Der erste Satz war meine zum Thema passende Antwort.
Der zweite Teil ist eine wilde Spekulation meinerseits, die nicht zu beweisen ist. Darüber zu diskutieren wäre sinnlos. Vielleicht hätte ich ein paar :D :D :D setzen sollen!?

[Coda]

Daß die nV Serie nix taugt ist alleine nV's Schuld und hat mit Verschwörung nichts zu tun.Naaaaja.
So ganz stimmt das ja nicht, weil DX9 keinen FX12 Datentyp in PS 2.0 hat, was ziemlich oft reichen würde :rolleyes:

Auf jeden Fall stand NV30 mit DX9 sicherlich schlechter da als er eigentlich war.

Ich will endlich on chip adaptive Tesselation sehen und nicht irgendwelchen "nebenher" Schnickschnack....darf ich jetzt bitte weitertraeumen?Öhm und wieso sollte sich dafür Cell nicht eignen?

[Ailuros]

Öhm und wieso sollte sich dafür Cell nicht eignen?

Mit on-chip meinte ich eher die GPU und nicht jeden anderen Bandbreiten-begrenzten Datenstrom zwischen GPU (<->) CPU. Ich dachte das war klar genug.

IMHO ist eine der Direktionen in die >WGF1.0 gehen will, die CPU noch mehr zu entlasten und nicht anders rum.

[godess]

wieso schreibt ein softwareherrsteller eigentlich vor, wie hardwarehersteller ihre grafikkarten featuremäßig ausgestattet sein müssen? ist das nich blanke ironie?

[StefanV]

wieso schreibt ein softwareherrsteller eigentlich vor, wie hardwarehersteller ihre grafikkarten featuremäßig ausgestattet sein müssen? ist das nich blanke ironie?
Kann man sehen, wie man will...

Wenn M$ das nicht machen würde, hätte man so ein Chaos wie unter Open GL, was man auch schon teilweise als mittlere Katastrophe bezeichnen kann, da jeder Hersteller seine eigenen Mist machen kann, was natürlich die Spielehersteller freut...

[Demirug]

wieso schreibt ein softwareherrsteller eigentlich vor, wie hardwarehersteller ihre grafikkarten featuremäßig ausgestattet sein müssen? ist das nich blanke ironie?

Vorschrieben ist ein zu hartes Wort dafür. Über die Features wird gemeinsam verhandelt und am Ende kommt eben ein Kompromiss dabei heraus.

[godess]

Vorschrieben ist ein zu hartes Wort dafür. Über die Features wird gemeinsam verhandelt und am Ende kommt eben ein Kompromiss dabei heraus.
das mit dem absprechen war doch aber nich immer so, oder?

[StefanV]

das mit dem absprechen war doch aber nich immer so, oder?
Naja, vor DX7 konnte man gut bei OGL 'borgen', davor war D3D auch OGL unterlegen, erst ab Version 8 sind diese 'Absprachen' nötig, da es davor nicht wirklich relevant war, da schon mehr oder minder vorhanden...

[Demirug]

Naja, vor DX7 konnte man gut bei OGL 'borgen', davor war D3D auch OGL unterlegen, erst ab Version 8 sind diese 'Absprachen' nötig, da es davor nicht wirklich relevant war, da schon mehr oder minder vorhanden...

Zudem ist das DX7 Featureset dermassen Variable durch die vielen Caps das man im Prinzip für fast jede Karte einen DX7 Treiber schreiben konnte.

[Ailuros]

Zudem ist das DX7 Featureset dermassen Variable durch die vielen Caps das man im Prinzip für fast jede Karte einen DX7 Treiber schreiben konnte.

Auch eine Anspielung auf SW T&L? Wenn ja wie wird es dann wohl fuer diesen Bereich in WGF2.0 aussehen? Koennte die GPU (rein theoretisch und abgesehen von Komplianz) auch auf VS Einheiten total verzichten und alles auf die CPU verladen? (womoeglich noch eine bloede Frage).

[del_4901]

Das kann ja sogar mein zukünftiges Handy :P
http://www.bitboys.fi/g40.php
hrhr
also wenn selbst Handys das schon haben können, dann ist es für Dektops ein Muss mit der nächsten Gen.

[Demirug]

Das kann ja sogar mein zukünftiges Handy :P
http://www.bitboys.fi/g40.php
hrhr
also wenn selbst Handys das schon haben können, dann ist es für Dektops ein Muss mit der nächsten Gen.

Wo steht da was von einem Geometrie Shader? Da steht nur " Programmable geometry engine" der Begriff wurde auch schon in der Vergangenheit benutzt um lediglich Vertexshader Unterstützung anzuzeigen.

Zudem spricht man auch immer nur von OpenGL ES 1.1.

[Demirug]

Auch eine Anspielung auf SW T&L? Wenn ja wie wird es dann wohl fuer diesen Bereich in WGF2.0 aussehen? Koennte die GPU (rein theoretisch und abgesehen von Komplianz) auch auf VS Einheiten total verzichten und alles auf die CPU verladen? (womoeglich noch eine bloede Frage).

Theoretisch möglicherweise. Aber MS würde ja gerne einheitliche Shadercores sehen und entsprechend auch Load Balencing. Auf jeden Fall muss aber alles in die Treiber programmiert werden (was unter WGF einfacher sein sollte) da es ja bei WGF 2.0 keine Caps mehr gibt. Bisher meldet ja zum Beispiel Intel überhaupt keine Vertexfähigkeiten und überlässt es der Anwendung die Softwareemulation dafür zu aktivieren.

Was mir in dem Zusammenhang aber gerade noch eingefallen ist. Auch (oder gerade) wenn man nur noch einheitliche Shadercores hat kann es interesant werden die CPU doch die Vertexarbeit übernehmen zu lassen. Kommt die GPU mal wieder nicht hinterher und veranlasst daher die CPU zu warten könnte diese schon mal anfangen für den nächsten Frame im Prerender Buffer die Vertexarbeiten auszuführen. Kommen dann diese Objekte bei der GPU an kann sie alle Shadercores für die Pixelarbeit rannehmen.

[del_4901]

Wo steht da was von einem Geometrie Shader? Da steht nur " Programmable geometry engine" der Begriff wurde auch schon in der Vergangenheit benutzt um lediglich Vertexshader Unterstützung anzuzeigen.

Zudem spricht man auch immer nur von OpenGL ES 1.1.

Mhm dann weiß ich aber nicht was ich von dem Bild halten soll:

http://www.bitboys.fi/images/demo/feature_geometry_engine_b.jpg

Trueform?

[Demirug]

Mhm dann weiß ich aber nicht was ich von dem Bild halten soll:

http://www.bitboys.fi/images/demo/feature_geometry_engine_b.jpg

Trueform?

Ja, könnte ein Patch verfahren sein.

Allerdings erinnere ich mich auch daran das man die Vorteile von HT&L und Vertexshader auch mal mit Bildern die eine feiner aufgelöste Geometrie zeigten unter Beweiss gestellt hat.

[Ailuros]

Wo steht da was von einem Geometrie Shader? Da steht nur " Programmable geometry engine" der Begriff wurde auch schon in der Vergangenheit benutzt um lediglich Vertexshader Unterstützung anzuzeigen.

Zudem spricht man auch immer nur von OpenGL ES 1.1.

Auf dem Link wird tatsaechlich OGL ES 2.0 erwaehnt aber dann ausschliesslich wohl fuer G40. Pixel Shader Extensionen gibt es in 1.1 AFAIK noch nicht.

AlphaTier,

G40 ist noch nicht mal im FPGA Format aufgetaucht. Von dem abgesehen ist G40 viel zu gross und Stromfressend fuer einen heutigen Handy und wurde eher fuer zukuenftige PDAs und/oder handheld gaming devices entwickelt.

Wie dem auch sei, falls NEC ein Handy veroeffentlicht das wahren 3D support behauptet, wird das IP wohl von Bitboys sein. Mit aller Wahrscheinlichkeit aber von den G2x oder G3x Familie und bei etwa 60-70MHz, wie bei allen anderen 3D cores fuer Handys auch.

Demirug,

Allerdings erinnere ich mich auch daran das man die Vorteile von HT&L und Vertexshader auch mal mit Bildern die eine feiner aufgelöste Geometrie zeigten unter Beweiss gestellt hat.

Kurven koennten sie aber auch eventuell durch den VS schleusen oder?

Auch (oder gerade) wenn man nur noch einheitliche Shadercores hat kann es interesant werden die CPU doch die Vertexarbeit übernehmen zu lassen. Kommt die GPU mal wieder nicht hinterher und veranlasst daher die CPU zu warten könnte diese schon mal anfangen für den nächsten Frame im Prerender Buffer die Vertexarbeiten auszuführen. Kommen dann diese Objekte bei der GPU an kann sie alle Shadercores für die Pixelarbeit rannehmen.

Passiert das nicht schon heutzutage in relativem Sinn auf Architekturen mit getrennten Einheiten oder besser formuliert: ist es moeglich dass sowas schon heute zum Einsatz kommen kann wenn der VS-Daten-Strom zu enorm ist? (rein theoretisch).

So in etwa N (GPU)- N+1 (CPU) - N+2 (GPU)....usw.

Heutige SIMD/MIMD Einheiten sind ja schon ueber multithreading faehig (wohl nicht so kompliziert wie bei vereinten Einheiten oder?); irgendwie hab ich das Gefuehl dass bei extremer Geometrie-Last auch heute schon nicht alles den VS Einheiten ueberlassen wird (ueberhaupt wenn der Entwickler bloed genug ist und draw calls nicht minimalisiert).

Mal anders gefragt: bei einer gut entwickelten Architektur mit vereinten Einheiten, GS und Tesselations-Einheit, waere es nicht idealer den ganzen (oder eben den groessten Anteil) der Geometrie auf der GPU zu behalten?

Gedankensprung: eine Applikation mit extremem VS-Gebrauch wird moeglicherweise "Tesselation-limitiert" sein und jegliche CPU ueberlasten oder?
Hat man jetzt eine starke Tesselations-Einheit kann man auch viel mehr VS-Befehle und auch effizienter ausfuehren, ohne dass die CPU ueberlastet wird.

Ausser ich schiesse mir hier wieder in den Fuss hab ich das Gefuehl dass im Fall wo eine programmierbare Tesselations-Einheit fehlt (da diese ja optional erscheint bis jetzt), die CPU-Last sowieso schwer zu vermeiden ist mit starker Geometrie-Last.

[Demirug]

Demirug,

Kurven koennten sie aber auch eventuell durch den VS schleusen oder?

Hängt davon ab wie der VS aufgebaut ist.

Passiert das nicht schon heutzutage in relativem Sinn auf Architekturen mit getrennten Einheiten oder besser formuliert: ist es moeglich dass sowas schon heute zum Einsatz kommen kann wenn der VS-Daten-Strom zu enorm ist? (rein theoretisch).

So in etwa N (GPU)- N+1 (CPU) - N+2 (GPU)....usw.

ATI hat angeblich sowas. Allerdings denke ich das man dabei nicht auf Vertexebene aufteilt sondern schon in etwas grösseren Blöcken. Schon wegen der Caches.

Heutige SIMD/MIMD Einheiten sind ja schon ueber multithreading faehig (wohl nicht so kompliziert wie bei vereinten Einheiten oder?); irgendwie hab ich das Gefuehl dass bei extremer Geometrie-Last auch heute schon nicht alles den VS Einheiten ueberlassen wird (ueberhaupt wenn der Entwickler bloed genug ist und draw calls nicht minimalisiert).

Mal anders gefragt: bei einer gut entwickelten Architektur mit vereinten Einheiten, GS und Tesselations-Einheit, waere es nicht idealer den ganzen (oder eben den groessten Anteil) der Geometrie auf der GPU zu behalten?

Gedankensprung: eine Applikation mit extremem VS-Gebrauch wird moeglicherweise "Tesselation-limitiert" sein und jegliche CPU ueberlasten oder?
Hat man jetzt eine starke Tesselations-Einheit kann man auch viel mehr VS-Befehle und auch effizienter ausfuehren, ohne dass die CPU ueberlastet wird.

Ausser ich schiesse mir hier wieder in den Fuss hab ich das Gefuehl dass im Fall wo eine programmierbare Tesselations-Einheit fehlt (da diese ja optional erscheint bis jetzt), die CPU-Last sowieso schwer zu vermeiden ist mit starker Geometrie-Last.

Das ausweichen auf die CPU sehe ich ja nur für den Fall das die GPU zu langsam ist und man CPU restzeit hat. Wenn die GPU sowieso schnell genug ist sollte man die CPU nicht noch zusätzlich belasten.

[Ailuros]

Das ausweichen auf die CPU sehe ich ja nur für den Fall das die GPU zu langsam ist und man CPU restzeit hat. Wenn die GPU sowieso schnell genug ist sollte man die CPU nicht noch zusätzlich belasten.

Dass die Tesselations-Einheit in WGF2.0 (hoechstwahrscheinlich) optional ist, ist NUR eine "Transistoren-Sparmassnahme" der IHVs oder sind sich die IHVs bewusst dass zukuenftige (auch multi-core) CPUs das Ganze wohl doch effizient genug loesen koennten?

[Demirug]

Dass die Tesselations-Einheit in WGF2.0 (hoechstwahrscheinlich) optional ist, ist NUR eine "Transistoren-Sparmassnahme" der IHVs oder sind sich die IHVs bewusst dass zukuenftige (auch multi-core) CPUs das Ganze wohl doch effizient genug loesen koennten?

IMHO will man Transitoren sparen.

[Ailuros]

Danke. So in etwa hab ich es mir vorgestellt *seufz*.

[reunion]

Was hat z.B. ATi denn entwickelt in letzter Zeit? :|

Mehr Pipelines hat ja wohl nix mit den Features zu tun.

R400 :naughty: