News NVIDIA: DirectX 11 ist nicht so wichtig
- Ersteller pipin
- Erstellt am
Devastators
Grand Admiral Special
so ziemlich alle Firmen, die nicht Fieberhaft auf neue Grafikkarten warten und ihren Mitarbeitern sofort neue Grafikkarten kaufen
Genausowenig wird dort auch immer die neuste CPU eingesetzt, im "Profibereich".
Das CUDA eine Randnotitz wird, spielt doch keine Rolle
Man hat damit ein(ige) Jahre Werben und Erfahrungen sammeln können und passt die Schnittstelle "nur noch" an DX11 an.
Ich sehe da absolut keinen Nachteil
Dr@
Grand Admiral Special
Naja aber nVidia hats mit PhysX schon integriert und nicht nur gezeigt. Das muss man denen ja lassen. Nur machen die eben den Fehler es nVidia-Exklusiv zu vertreiben.
Mir ists Schnuppe ob so ein Mirrors Edge mit wehenden Fahnen dahingurkt oder eben ohne. Sowas kann man auch ohne PhysX einigermaßen gut kaschieren und implementieren, statt es gänzlich rauszulassen. Nur Hascherei is das.
Genau wie die Sonnenstrahlen damals bei Crysis... DX10 only! pfff
bye Hübie
Ich denke die propritären Standards für Physikberechnungen werden es in der Zukunft schwer haben, denn jeder Hersteller kann dank Compute Shader sich seine eigene Physik-Engine programmieren. Diese wäre dann auf jeder DX11 Hardware lauffähig.
MfG @
Zuletzt bearbeitet:
Devastators
Grand Admiral Special
Genau der TRend ist doch nicht zu erkennen, oder warum nutzen fast alle Spiele nur noch PhysX oder Havok?
Den Zeit und Geldaufwand will man sich doch sparen, eigene PhysikEngines zu programmieren
Dr@
Grand Admiral Special
was hat CUDA mit DX11 zu tun?
kurz bis auf PTX (Low-Level-Interface, Parallel Thread Execution) nichts
kurz bis auf PTX (Low-Level-Interface, Parallel Thread Execution) nichts
Devastators
Grand Admiral Special
Ich frage mich ob das überhaupt geht: CUDA DX11-fähig zu machen.
Bräuchte man dann nicht sowas wie einen wrapper
bye Hübie
jein, ich denke man programmiert einfach die Schnittstelle neu, ist jedenfalls performanter als die DX11 Befehler dann in die entsprechenden CUDA Befehle zu "wrappen".
Da man mit CUDA bereits viele Erfahrungen sammeln konnte, sollte die neue Schnittstelle nicht so fürchterlich langwierig werden.
Dr@
Grand Admiral Special
Die Compute Shader von DX11 greifen über das PTX (Low-Level-Interface, Parallel Thread Execution) Interface auf die GPU zu.
Das ist vergleichbar mit AMDs CAL.
MfG @
Edit: siehe hier
Das ist vergleichbar mit AMDs CAL.
MfG @
Edit: siehe hier
Zuletzt bearbeitet:
PuckPoltergeist
Grand Admiral Special
wazzup
Vice Admiral Special
- Mitglied seit
- 25.11.2004
- Beiträge
- 538
- Renomée
- 5
Die übliche nvidia taktik. Können wir (noch) nicht = schlecht, niemand braucht/will das, kauft unsere alten Karten. Wenns dann darum geht das sie einen (und sei es noch so kleinen) vorsprung haben wie DX9.0c damals sind sie die schnellsten, besten und tollsten überhaupt und die konkurrenz unfähig. Ich habe selten einen hersteller erlebt der sich so elegant selbst lächerlich machen kann.
LordAndrax
Gesperrt
- Mitglied seit
- 11.06.2005
- Beiträge
- 4.618
- Renomée
- 41
Und als bei den Ati an den neuesten Shadern fehlte, wurde genau das gleiche gesagt.
Und in beiden Fällen ist es das gleiche.
Ein must have ist es jedenfalls nicht.
Zumal kann sich jeder selbst überlegen obs ihm wichtig ist oder nicht.
Außerdem sagt das jeder Hersteller über Funktionen die er nicht anbieten kann.
Ich würde gerne mal wissen, ob Amd es nicht auch gerne hätte die Cpu Kerne Virtuell verdoppeln zu können.
Und in beiden Fällen ist es das gleiche.
Ein must have ist es jedenfalls nicht.
Zumal kann sich jeder selbst überlegen obs ihm wichtig ist oder nicht.
Außerdem sagt das jeder Hersteller über Funktionen die er nicht anbieten kann.
Ich würde gerne mal wissen, ob Amd es nicht auch gerne hätte die Cpu Kerne Virtuell verdoppeln zu können.
Undergroundking
Gesperrt
- Mitglied seit
- 23.05.2007
- Beiträge
- 2.366
- Renomée
- 72
zum ersten seh ich da kein video und zum zweiten. ja ist doch süss, soll nvidia ihr cuda gedöns inne tonne der geschichte kloppen, dort wo es auch hingehört und sich auf open cl und dx11 (wenn die mal die hardware hinbekommen) konzentrieren.
Kann ich dir sagen: der Overhead für bestimmte Aktionen, die der Treiber ausführen muss sind einfach extrem groß. Viele Spiele limitieren dort durch warten auf das fertigstellen eines DrawCalls, was man durch eine vollständige Parallelisierung auf CPU Seite umgehen kann. Der Verwaltungsaufwand ist schon extrem groß. NVidia hat in OpenGL eine Extension namens Bindless Grafics eingebracht, die den Overhead im Treiber verringert, damit konnten in einer Singlethreadumgebung Leistungssteigerungen um den Faktor 10 erzielt werden. Wenn man jetzt die GrafikAPI in mehrere Threads aufteilt, werden diese Leistungssteigerungen nutzbar, ohne das man den Treiber verbessern muss, da ein Call einfach warten kann, während API seitig schon der nächste Call in einem anderen Thread vorbereitet wird.
PuckPoltergeist
Grand Admiral Special
gruffi
Grand Admiral Special
Das ist richtig, du hast sie absolut nicht verstanden. Es geht um Produktpolitik. Übrigens, es gibt seit einiger Zeit ein vollständiges OpenCL SDK von AMD. Nur so zur Info.
Das konnte man auch mit ATI Stream. Und sogar schon länger als CUDA mit CTM und Brooks. Aber wie schon erwähnt, du hast die Aussage gar nicht verstanden. Es geht um zukünftige Plattformen. AMD hat sich für die plattformunabhängigen OpenCL und DirectCompute Schnittstellen sehr früh festgelegt. Das hat nVidia nicht. Dort weiss man immer noch nicht, was sie genau vorhaben. Möglichst solange wie es geht Softwarelösungen auf die eigene Hardware beschränken, um diesen ein Alleinstellungsmerkmal zu geben.
![:]](https://www.planet3dnow.de/vbulletin/images/smilies/rolleyes.gif "Augen rollen (sarkastisch) :]")
Und das ist alles andere als kundenfreundlich.Wenn diese Monster Chips nur dafür entwickelt werden würden, schön. Das werden sie aber nun mal nicht. Ergo -> fail. Auch AMD bedient mit ihren deutlich wirtschaftlicheren Chips den Profi Markt. Falls dir das entgangen sein sollte.
Wo hast du denn deine 90% her? Ich halte diese Zahl ehrlich gesagt für Quatsch bzw frei erfunden. AMD ist mit ihrer proprietären Schnittstelle ebenfalls in vielen Projekten vertreten. Vermutlich kaum weniger.
nVidia hat bereits ein vollständiges OpenCL SDK veröffentlicht? Muss mir entgangen sein. Sie haben bereits DirectX 11/DirectCompute fähige Karten gezeigt? Muss mir ebenfalls entgangen sein. Für PhysX existiert bereits ein plattformunabhängiger Layer so wie das AMD/Intel bereits mit Havok und OpenCL gezeigt haben? Wäre mir neu. Ich glaube, du verkennst hier leicht die Realität.
Ich sage es gerne nochmal, man kann AMD nur dankbar sein, dass sie so energisch eine so offene Produktpolitik betreiben. Dadurch wird letztendlich auch nVidia enorm unter Druck gesetzt. Dürfte nVidia frei entscheiden, würden sie bei ihrem proprietären Quark bleiben und der Kunde schaut am Ende in die Röhre.
Weil es bisher keine plattformunabhängigen Mittel gab, die es jetzt gibt?
Dann schau dir mal an, wie viele 3D Engines es gibt. Es ist immer eine Frage der Lizenzierungskosten und der notwendigen Entwicklungszeit.
Bobo_Oberon
Grand Admiral Special
- Mitglied seit
- 18.01.2007
- Beiträge
- 5.045
- Renomée
- 190
Ja so "vollständig", dass entweder nur die Multicore-Prozessoren genutzt werden ... oder nur die eigenen GPUs. Das hatten wir andernorts auch schon angesprochen.
Für Nvidia lohnt sich das derzeit um so mehr, weil sie einen hohen Anteil im Profimarkt erobert haben.
Dort werden Quadro Karten in der Höhe von über 4000 US-Dollar verkauft und das in Stückzahlen und Margen, wovon ATI/AMD nur träumen können.
Ich berufe mich auf den Anteil der professionellen Produktivsysteme mit Nvidia-Karten (Quadro + Tesla) und ATIs Fire-Karten.
Das steht nicht im Widerspruch von ATI-Kunden, die Fire-Karten einsetzen.
Zumindest haben sie Grafikkartentreiber veröffentlicht, die OpenCL nutzen können. Wie weit CUDA ist, kann ich nicht sagen. Geplant ist auf jeden Fall die Integration der OpenCL API. In Apples OS Snow Leopard läufts schon mit den Karten der Kalifornier.
Direct Compute kommt zwar mit der DirectX-11 API, aber das können auch DX-10 Karten sein, die so etwas nutzen können. Das ist auch eine Frage der Treiber.
-> Bildklick <- Quelle.
Oder mit anderen Worten. Deine Annahme, man könne Microsofts "Direct Compute" nur mit einer nativen DirectX-11 GPU nutzen, ist grundfalsch.
Dir ist klar, dass die PS3, Xbox 360 und Wii die Physikengine von Ageia lizensiert haben? -> Es gibt durchaus Plattformen, die Physikbeschleunigung mit PhysX-Technik nutzen, ohne dabei Nvidia-Chips zu nehmen.... Für PhysX existiert bereits ein plattformunabhängiger Layer so wie das AMD/Intel bereits mit Havok und OpenCL gezeigt haben? Wäre mir neu. Ich glaube, du verkennst hier leicht die Realität.
So viel zu deinem Bezug zur Realität.
Meine Hoffnung ist, dass OpenCL (neben dem proprietären DirectX-11) breit genutzt wird. Damit wird langfristig eine firmeneigene API überflüssig.
MFG Bobo(2009)
Zuletzt bearbeitet:
gruffi
Grand Admiral Special
Ja, ich hätte es mir denken können. Du als Nicht-Programmierer verstehst das natürlich nicht. Das hatten wir an anderer Stelle auch schon besprochen. Die Hardware spielt erstmal überhaupt keine Rolle. Vollständig heisst hier, dass der Entwickler den kompletten Umfang der OpenCL Spezifikation erhält.
Nun ja, die Zahlen sind relativ nichtssagend, da man nicht nachvollziehen kann, wie sie sich zusammensetzen. Mobil? Integriert? Dediziert? Usw. Insgesamt leidet der professionelle Markt schon seit geraumer Zeit. Und das tut auch nVidia, trotz mehr Marktanteil in diesem Bereich und höheren ASPs. Und Monsterchips wie GT200 helfen dann auch nicht mehr. Quartalszahlen lügen nun mal nicht.
Das sind AMD Folien. Über nVidia sagt das erstmal nichts aus.
Nein, diese Aussage ist grundfalsch. Etwas derartiges habe ich weder angenommen, geschweige denn geschrieben. Die Aussage sollte doch deutlich geworden sein. Du hast in den Raum gestellt, dass nVidia generell viel weiter in Sachen GPGPU ist. Das ist eben nicht der Fall.
Dir ist schon klar, dass wir über GPU Beschleunigung sprechen? Das können diese Plattformen aufgrund ihrer veralteten Hardware nicht. Dort gibt es lediglich Software Havok und PhysX. Übrigens, netter Versuch, aber der ging leider völlig daneben. Diese Plattformen hatten Havok schon weit vor PhysX lizenziert.
Und genau darauf darf man auch hoffen. Vor allem dank Apple (muss ich leider mal zugeben), der Khronos Group und AMD. Würde es nach nVidia gehen, wäre diese Hoffnung wohl schon begraben.
Dr@
Grand Admiral Special
Oben hast du noch von einem SDK (Software Development Kit) gesprochen. Ich gehöre zu den Nicht-Programmierern und verstehe diesen Zusammenhang nicht ganz. Gehört nicht zu einem vollständigen SDK etwas mehr als nur ne Spezifikation?
Das ist richtig, du hast sie absolut nicht verstanden. Es geht um Produktpolitik. Übrigens, es gibt seit einiger Zeit ein vollständiges OpenCL SDK von AMD. Nur so zur Info.
MfG @
Zuletzt bearbeitet:
PuckPoltergeist
Grand Admiral Special
Schon wieder dieses Böses-nVidia-Gebashe? Die arbeiten genauso an den Standards mit wie Apple und AMD. Oder gehört nVidia für dich neuerdings nicht mehr mit zu Khronos?
.
EDIT :
.
Es braucht in diesem Fall zumindest Treiber, die die Spec unterstützen sowie passende Schnittstellen, um es auch nutzen zu können. Bestes Negativbeispiel ist XvBA von ATI. Wird seit was weiß ich schon wie vielen Version des Treibers mit ausgeliefert, aber Header sind nach wie vor nicht zu haben.
PuckPoltergeist
Grand Admiral Special
Jetzt sprechen wir aneinander vorbei. Ich habe oben generell vom SDK gesprochen, nicht speziell Stream.
Und bzgl. der GPU-Unterstützung steht ja da, dass der Treiber-Support benötigt wird.
Bobo_Oberon
Grand Admiral Special
- Mitglied seit
- 18.01.2007
- Beiträge
- 5.045
- Renomée
- 190
Mir ist ein Rätsel was du mit dem Begriff "Vollständig" meinst.
Zum aktuellen Zeitpunkt gibt es bei AMDs Stream SDK ein entweder - oder.
1. Der Programmierer hat die Wahl zwischen dem Einsatz für OpenCL bei Prozessoren (neue Stream-SDK),
2. oder OpenCL für GPUs (ältere Stream SDKs).
Zeige mir bessere Zahlen. Üblicherweise sind das nur wenige Marktforscher, die da Zahlen (und das nur in Auszügen) gratis publieren. Das sind in der Regel JPR, IDC und Gartner.
Die von mir verlinkten Zahlen belegen aber zumindest die große Nvidia Dominanz zur Zeit (und den letzten Jahren). Andere Zahlen kenne ich nicht, sonst hätte ich sie berücksichtigt.
Dort ist die Rede von der DirectX-11 und DirectX-10 API von Microsoft. An diese Standards hält sich auch Nvidia, nicht nur AMD.
Wenn AMD aussagt, dass die Compute Shader auch mit DX10-Hardware läuft, dann sehe ich keinen Grund, weswegen auf Nvidias DX10-Karten dies nicht läuft.
Über das "viel" weiter könnte man sich streiten.
Beobachtet man neben der Marktanteile im Profisektor auch die Meldungen zur Zusammenarbeit mit verschiedenen Software-Schmieden, dann fällt mir auf, dass die Nvidia-Lösungen in der Regel einige Monate vorher vorgestellt werden.
Geht es um die rohe GPU-Rechenleistung, dann sind die ATI-GPUs sogar verstärkt in Vorhand. Das habe ich schon vor Jahren bemerkt und beschrieben (1, 2). Das Änderte aber offenbar nichts an der Präsenz und Zugkraft des CUDA-Marketings.
Deine Antwort ist eine doppelte Frechheit.
1. Es ging in deiner Frage um einen plattformunabhängigen Layer für Physikbeschleunigung. - Meine Antwort lautet: Ja es gibt so etwas.
2. Deine Replik gibt vor, dass Physikbeschleunigung ganz natürlich aus dem GPGPU-Bereich käme. - Meine Antwort darauf: Der PhysX war aber kein Grafikchip, sondern ein Spezial-Chips nur zum Zwecke der Physikbeschleunigung.
Die Antwort von mir vorher auf deine Replik lautete folgendermassen:
Ageia hat mit dem PhysX zwar einen speziellen Physikbeschleunigungschip entworfen. Aber sie haben zusätzlich eine Middleware geschrieben, die Physik-Berechnungen auch auf anderen Plattformen und Hardware ermöglicht.
Setzt man Manpower daran, dann könnten also nicht nur Nvidia-Karten die Physikbeschleunigung von Ageia nutzen, sondern auch andere Plattformen. Sei es Cell, Xenon, oder potenziell auch ATI-GPUs.
Zu diesem Zwecke bewarb Ageia noch das Framework APEX, damit auch andere Hardware MIT und OHNE PhysX-Chip genutzt werden konnte.
MFG Bobo(2009)
Zuletzt bearbeitet:
gruffi
Grand Admiral Special
Oh mann, wie soll ich dir das erklären? Hast du überhaupt schon mal etwas programmiert? Löse dich doch endlich mal komplett von dem Gedanken der Hardwareunterstützung. Auf welcher Hardware die Software läuft, ist für dich eine Blackbox und spielt erstmal überhaupt keine Rolle. Programmiersprachen, und OpenCL ist im Wesentlichen "nur" eine Spracherweiterung, bestehen aus Syntax, Semantik und dem für die jeweilige Plattform bereitgestellten Compiler sowie der Runtime. Letzteres bereitgestellt als SDK. Und genau dieses SDK stellt sicher, dass in dem Fall die in der OpenCL Spezifikation definierten Funktionalitäten, dem Entwickler zur Verfügung stehen. Er kann also damit beginnen, Anwendungen entsprechend OpenCL Standard zu schreiben, diese übersetzen und ausführen. Weder CPU, noch GPU, noch das Stream SDK haben hierbei irgendeine Relevanz. Es geht um die OpenCL Spezifikation und um nichts anderes.
Ist ja schön, das ändert trotzdem nichts an meiner Aussage. Es sind nun mal verschiedene Architekturen und nicht identisch, was das Feature Set betrifft. Solange keine konkreten Informationen bekannt sind, kann man jedenfalls erstmal nicht ausschliessen, dass es bei nVidia eventuell anders ausschaut.
Nun ja, das ist wohl etwas offtopic. Ich dachte, es sollte klar sein, dass es hier immer noch um Physik Beschleunigung per GPU geht. Mir wäre auch neu, dass Ageia ihre Zusatzkarten in irgendeiner Konsole verbaut hätte. Wie ich schon sagte, dort gibt es also trotzdem nur Software Havok und PhysX bzw Havok und PhysX per CPU.
Bobo_Oberon
Grand Admiral Special
- Mitglied seit
- 18.01.2007
- Beiträge
- 5.045
- Renomée
- 190
Wie wärs mit einer Erklärung, anstatt mich wieder mal in eine Schublade zu stecken?
OK, wusste ich schon vorher.
OpenCL ist eine Laufzeitumgebung für bestimmte Anwendungen mit einem fest umrissenen allgemeinen Instruktionssatz und bietet darüber hinaus auch firmeneigene Extensions einzubinden (wie bei OpenGL auch).
Und genau da hört die "Allgemeingültigkeit" der jeweiligen SDKs auf.
Zwar spucken die Tools von AMD/ATI, Nvidia, Intel OpenCL-Anweisungen heraus. Aber das Entwicklerkit kennt die Tiefen der eigenen Hardware besser, als das Konkurrenztool.
Es ist ein offenes Geheimnis, dass zwar mit Nvidias Entwicklertools auch eine ATI-Karte laufen kann, aber in der Regel läuft das dann suboptimal. Umgekhrt geht das Spiel natürlich auch.
Tja, wenn es nur um die sprachliche Reinheit einer Syntax ginge ... wie kommt es dann zu unterschiedlich gut optimierenden Kompilern in der x86-Welt? Die Hardware spielt eben doch eine Rolle.
Da gibt es einen Ganzen Sack voll von Kompilern in der x86-Welt und alle ordnen die Versatzstücke der x86-ISA immer etwas anders an ...
Ich wüsste nicht, warum es bei OpenCL anders sein sollte. Im Grunde genommen müssten da noch weit grösserer Spielraum sein, weil die Anweisungen schon ein Stück weg sind, um als maschienennah bezeichnet zu werden.
Was du und ich denken lässt sich in den allerwenigsten Fällen in Deckung bringen.
Die Lösung von Nvdia lässt sich durchaus vergleichen mit den Middleware-Lösungen der Spielekonsolen.
Die einzige native Hardwarelösung für Physikbeschleunigung in Spielen ist der PhysX-Chip.
Alles andere läuft über Softwarelösungen (-> APEX). Die aktuellen Nvdia-GPUs wurden noch ohne Ageias Spielephysik entwickelt.
Bei Havok hat man sich gleich ganz auf die Middleware für Prozessoren und GPUs konzentriert und darauf verzichtet einen wie auch immer gearteten eigenen Chip zu entwickeln.
MFG Bobo(2009)
Zuletzt bearbeitet:
gruffi
Grand Admiral Special
Nein, nein und nochmals nein. Hört doch endlich mal zu, wenn man dir etwas sagt. So langsam machst du mich echt wuschig. OpenCL ist eine Spezifikation. Die Spracherweiterungen, die Runtime, usw sind lediglich darin definierte Teile.
So langsam habe ich echt das Gefühl, du weisst nicht im geringsten etwas über Softwareentwicklung, bist aber der Meinung, darüber diskutieren zu können oder zu wollen.
Tools von ... spucken gar nichts aus. Wir haben erstmal über die Programmierung gesprochen. Da kannst du jeden billigen Texteditor hernehmen und loslegen. Die C und OpenCL Standards sagen dir, was du machen darfst und was nicht. Und genau darauf bezog sich meine ursprüngliche Aussage. Du kannst mit dem AMD OpenCL SDK uneingeschränkt loslegen und diesen Quellcode übersetzen. Was die Runtime dann bei der Ausführung macht, spielt hier überhaupt keine Rolle.So langsam bestätigt sich mein Verdacht. Du weisst wirklich nicht, wovon du sprichst. Lass es bitte bleiben. Was haben Syntax und Compiler Optimierungen miteinander zu tun?
Ähnliche Themen
