Nvidia vergibt Kepler- und GPU-IP-Lizenzen an Dritte

[beercarrier]

Wollen sie - klar.
Abwarten, ob sie es auch dürfen. Denn lass mich mal überlegen, was man derzeit so als Alternative zu einer GPU der ~gf630 Klasse lizensieren könnte...
...
...
...
...
Ach ja: Nichts. AMD lizensiert nicht, Intel auch nicht, PowerVR ist nicht annähernd in dieser Leistungsklasse. Nimm noch so attraktive Dinge wie CUDA-Kompatibilität (und damit eine extrem leichte Protierung diverser Titel der letzten Konsolengeneration auf z.B. kommende Tablets) hinzu und Nvidia macht SoC-Entwicklern ein Angebot, dass vielleicht keinen riesigen Markt anspricht, in diesem aber konkurrenzlos ist.
Und Nvidia muss mit einem derartigen Nebenverdienst auch keinen riesigen Markt ansprechen und sich z.B. mit PowerVR in einer Leistungsklasse anlegen, von der Nvidia 0 Ahnung hat und für die sie ein zweites Entwicklerteam unterhalten müssten.

ich frag mich eh wer überhaupt für lizenzen in frage kommt. man braucht einen funktionierenden cpu teil, am besten einen etwas stärkeren, also bei arm designs waren die ulv geforce jetzt nicht übermäßig stark, deshalb würde ich noch etwas mehr cpu-leistung ansetzen damit sich das lohnt und da fällt mir nur via ein. trotzdem lohnt sich das für einige 10k stück wohl eher weniger und ganz billig wird nvidia die lizenzen wohl auch nicht verscherbeln. naja vlt ibm mit power. hat jmd von euch ne ahnung wer überhaupt interesse daran haben könnte.

 

[Skysnake]

IBM, VIA und MIPS/China

Intel nicht wirklich, die haben ihre iGPU. Vor allem will Intel eine sehr sehr starke Integration. Da müsste nVidia die Hosen bis zu den Schuhsohlen runter lassen. Da gäbe es kaum noch einen Unterschied zum aufgekauft werden, außer halt das man noch selbst rechtlich als eigene Firma laufen würde.

Sparce/Fujitsu kann ich mir nur schwer vorstellen, da ist ihr Fokus einfach doch ein ganz anderer.

Als realistischtes würde ich IBM und China mit ihren MIPS Schmieden ansehen. IBM, da Sie was Neues nach Cell brüchten, um einen Konterpart zu XeonPhi zu haben. Bei den Chinesen ist es halt so ne Sache. Die würden sich wohl durchaus über die Technologie von nVidia freuen, da Sie ihre MIPS damit massiv aufwerten könnten. Wenn man sich aber daran erinnert, wie sich nVidia bei den Chinesen wie die Axt im Walde verhalten hat, und die ziemlich brüsk vor den Kopf gestoßen hat, dann könnte das zu ziemlichen Problemen für nVidia führen, da die Chinesen das sicherlich nicht so schnell vergessen werden...

 

[beercarrier]

das nur mal zum verhältnis intel - nvidia
Für 1,5 Milliarden Dollar: Intel kauft sich Nvidia-Technologie - N24.de
für mich mit ein hauptgrund warum intel in sachen igp so dermaßen aufgeholt hat.

p.s. ja n24 hab aber auf die schnelle keine andere quelle gefunden.

 

[ruyven_macaran]

Ich seh da noch immer kein "verdammt spät".


Also nicht mal ein Monat unterschied in der offiziellen frei verfügbaren Implementierung.

Es geht nicht um AMD vs. Nvidia, es geht um die Entscheidung gegen PhysX/CUDA und für OpenCL. Und wie bereits erwähnt geht es auch nicht um die erste Beta, sondern es geht um den Zeitpunkt, an dem man versucht hat, OpenCL flächendeckend verfügbar zu machen.
Soweit ich das nachvollziehen kann, war die erste normale Catalyst-Ausgabe mit OpenCL Unterstützung der 11.1 von Anfang 2011. gegen PhysX und "für" OpenCL hat man sich aber Anfang 2008 entschieden. Das sind milde drei Jahre, in der IT-Branche eher als "Aeonen" denn "verdammt spät" bekannt.

Ok, der Kontext hat sich mir jetzt erst nach dem lesen der beiden Ursprungsposts des Zitats erschlossen.
Ja, bei den Physik-Engines hat sich OpenCL noch nicht durchgesetzt, aber das gilt halt im gleichen Maße für "CUDA"/GPU-PhysX. Also GPU-Physik hat sich allgemein noch nicht durchgesetzt.

Daher versteh ich auch nicht, was OpenCL mit PhysX(CPU) zu tun hat. Das sind zwei paar Stiefel

Eben nicht, dass ist ja das geniale an PhysX. Im Gegensatz zu allen Konkurrenzangeboten kann es dem Entwickler vollkommen egal sein, ob das ganze später auf einem CPU- oder GPU-Client läuft. Hauptsache, die Gesamtleistung stimmt. Es ist also in einer Vielzahl von Titeln möglich, mit einer CUDA-tauglichen GPU einer schwächelnden CPU unter die Arme zu greifen. OpenCL dagegen verlangt vom Entwickler, explizit für GPU zu entwickeln, ggf. sogar noch getrennte Fallbacks bereitzuhalten, und bietet keinerlei Kompatibilität zu bestehenden Titeln. Wenn ich eine ARM-GPU in mein SoC integriere, dann bringt mir das: Grafikausgabe. Sonst nichts. Wenn ich eine PowerVR-GPU in mein SoC integriere, dann bringt mir das: Grafikausgabe. Sonst nichts. Wenn ich ein custom-SoC bei AMD kaufe, dann bringt mir das: (ne CPU & ) Grafikausgabe und sonst nichts. Wenn ich aber eine aktuelle Nvidia-GPU in mein SoC integriere, habe ich neben dem Rendering noch eine deutliche CPU Entlastung in einer Vielzahl bestehender, populärer PC, X360 und PS3 Titel. Also gerade auch Spielen, deren Leistungsanforderungen in dem Bereich liegen, in dem in 1-3 Jahren (="1 Entwicklungszyklus") Tablets zu erwarten sind. Und das ohne irgend eine Änderung an der Physik-Engine vornehmen zu müssen.

Und genau hier liegt der Denkfehler. Das funktioniert nicht. Du kannst keinen fertig gelayouteten IP-Block in ein Full-Custom design packen. Das funktioniert einfach nicht. Selbst bei nem Semi-Custom-Design wirds schwierig, weil du hier ja zwei komplett gleichberechtigte Chipteile hast in einem SOC, nämlich CPU und iGPU.

Bei nem externen Chip, wie ner dGPU, nem NIC funktioniert das. Auch bei SER/DES und sonstigen "kleinen" Chipkomponenten funktioniert das. Aber schon PCI-E Core oder nem RAM-Interface routest du eigentlich selbst, weil das eben durchaus Latenzkritische Sachen sind, die auch noch doch einiges an Platz brauchen, und dann auch noch eben vernünftig angeschlossen werden müssen. Klar, die I/O Pads usw nimmste wirklich als Fixen block, den du halt hinschieben musst, aber bei der ganzen Ansteuerlogik usw wirds schon wieder problematisch.

PCI-E und RAM sind externe Schnittstellen. Die unterzubringen erfordert natürlich etwas Planung, sonst kommst du an deine I/O Pads überhaupt nicht angemessen ran. Eine iGPU dagegen muss (fast) "nur" mit *was auch immer du in deiner CPU an Interconnect nutzt* (Crossbar, Ringbus, ggf. PCIe selbst, wenns ein einfaches Design wird?) verbunden werden. Sicherlich ist das nicht leicht, aber es ist ein Funktionselement, dass sich seinerseits an Bedürfnisse anpassen lässt - wesentlich freier als z.B. ein RAM-Controller, der nun einmal zwingend an einer Außenkante liegen sollte, weil er viele Anbindungen braucht.
Und bezüglich der Anordnung und "kleiner" und "großer" Chipkomponenten: Llano hat die GPU als Block in einer Hälfte. Trinitiy hat die GPU als Block in einer Hälfte. Sandy Bridge hat die GPU als Block in einer Hälfte. Ivy Bridge hat die ... . Haswell hat ... . Kal El hat ... . Wayne ... .
Ich gebe zu, dass ich mir Insiderwissen klar fehlt. Aber wenn jedes einzelne full custom Design (alias "für uns selbst") mit nenenswerter iGPU diese als einen großen, in sich geschlossenen Block positioniert, dann frage ich mich doch, warum das bei einem semi-custom auf einmal unmöglich sein sollte.

Nur weil man bei TSMC produziert heist das noch LANGE nicht, dass das dann am Ende auch alles genau das Gleiche ist. TSMC erschlägt dich mit Auswahlmöglichkeiten, was du wann wo wie machen kannst. Das musst du immer aufeinander anpassen. Dazu kommt noch, das Kunden wie AMD und nVidia eben nicht 0815 Bibs verwenden, sondern ihre Transistoren auf unterster Ebene teils selbst designen. Da steckt sehr viel Know-How drin. Das ist dann alles nicht mehr so einfach, und kann Seiteneffekte haben.

Sowohl Nvidia als auch AMD leisten es sich nicht einmal ein zweites Stepping des Transistorlayers. Entweder sind das also gnadenlos begabte Hellseher, die alles, wirklich alles im vorraus planen können (im Gegensatz zu z.B. den Loosern bei Intel, die manchmal 3-4 Versuche brauchen), oder da kann nicht alzuviel Entwicklung drin stecken, die nicht zu 99% von TSMC übernommen wurde...

Und ja: TSMC bietet einem ein paar Möglichkeiten. Was spricht dagegen, die zu nehmen, für die man ein fertig optimiertes Design kaufen kann?

Wenn Sie es richtig machen, also wirklich realistische Chancen haben wollen in Deals rein zu kommen, müssen Sie relativ weit die Hosen runter lassen. Tun Sie es nicht, können Sie die SAche eigentlich gleich bleiben lassen, weil mehr als aktuell bei Tegra, also ein Minusgeschäft, kommt dabei kaum rüber.

Das größte Problem von Tegra ist, dass er eine zu eingeschränkte CPU-Konfiguration hat (siehe den nachgeschobenen i), um einen größeren Marktbereich abzudecken, und dass die Entwicklungskosten für diese auch noch in keinem Verhältnis zum Ergebnis stehen, weil Nvidia eben keine Ahnung von CPUs hat. Beide Probleme lösen sich in Luft auf, wenn man die Konzeption von CPUs Leuten überlässt, die sich mit sowas auskennen.
Und zum Minusgeschäft: Wenn man (quasi) keine Investitionen hat, kann man auch keine Verluste machen. Die Entwicklung der Grafikeinheiten als solche ist für Nvidia quasi umsonst, denn die sollten ab der nächsten Generation sowieso runterskalierte Desktop-Architekturen sein. Man muss lediglich den Personalaufwand finanziert bekommen, der bei der technischen Unterstützung des Kunden anfällt (Implementation und ggf. Anpassung der Schnittstelle zur restlichen CPU). Sobald der Kunde 1 € mehr zahlt, als diese Techniker kosten, macht Nvidia Gewinn.
Und selbst wenn er nur ±0 diese Kosten zahlt, ist die Sache für Nvidia lohnend. Denn so erhält man mehr Aufmerksamkeit, ist für Entwickler attraktiver (bzw. "produziert" umgekehrt mehr Entwickler, die sich schon mit der Architektur auskennen) und vor allem: Verbreitet CUDA. Und im Gegesatz zu AMD und Intel mit ihren ultra mobilen Ambitionen riskiert Nvidia mit kleineren iGPUs keine Eigenkonkurrenz zu bestehenden Produkten. Es ist schlichtweg ein Markt, auf dem man -abseits des wohl gefloppten Tegra- nicht präsent ist und den man nun versucht, von Lizenznummern zum Nulltarif (bzw. Plustarif) erobern zu lassen.

ich frag mich eh wer überhaupt für lizenzen in frage kommt. man braucht einen funktionierenden cpu teil, am besten einen etwas stärkeren, also bei arm designs waren die ulv geforce jetzt nicht übermäßig stark, deshalb würde ich noch etwas mehr cpu-leistung ansetzen damit sich das lohnt und da fällt mir nur via ein.

Die Grafikentwicklung im mobilen Bereich explodiert derzeit geradezu. Durch den "Retina"-Wahn haben viele Tablets Auflösungen, die vor 3-4 Jahren auf PCs nicht schlecht gewesen wären und selbst Smartphones haben kein Jahrzehnt Rückstand mehr. Entsprechend hoch sind auf einmal die Anforderungen an Grafikeinheiten. Zugleich sind die in diesem Markt erfolgreichen Spielkonzept auf dem Stand der Jahrtausendwende und die Beschränkungen in der Bedienung legen nahe, dass das auch noch eine zeitlang so bleibt. GTA Vice City wurde z.B. vor nicht alzu langer Zeit umgesetzt. Eine moderne Grafikeinheit könnte somit für alle Hersteller mobiler SoCs von großem Interesse sein - insbesondere von Nvidia weil, wie erwähnt, die Physik- und Grafikengines vieler für Portierungen interessanter Titel bereits vollkompatibel sind, wobei der bislang auf CPUs laufende Physikteil 1:1 auf die GPU wandern kann. Das reduziert dann, neben der entfallenden PowerPC/x86->ARM Portierung, auch gleich noch das Problem der knappen CPU-Leistung.
(Und selbst bei reinen Casual-Games ist Nvidia interessant, weil jeder Indie-Entwickler die passende Entwicklungsplattform zu Hause stehen hat.)

 

[Deimos]

Kann man das so verstehen, dass sich NV weniger auf Hardwareentwicklung und verstärkt auf Softwaresupport konzentrieren könnte? Dass sie nur noch "Designs" entwerfen?

Kann das im Umkehrschluss auch heissen, dass der Markt bestenfalls wieder mehrere dedizierte GPU-Produzenten bekommen könnte, abhängig davon, wie frei NVs GPU-Lizenzen sind und wie weit sich durch Dritthersteller eine Diversifizierung erreichen liesse (auf der Basis derselben Architektur zwar, aber immerhin!)?


Ich verstehe leider viel zu wenig davon, als dass ich verstehen würde, wie sich das auswirken könnte.

 

[ruyven_macaran]

Kann man das so verstehen, dass sich NV weniger auf Hardwareentwicklung und verstärkt auf Softwaresupport konzentrieren könnte? Dass sie nur noch "Designs" entwerfen?(

Mit Software hat das nichts zu tun. Möglich wäre, dass sich Nvidia auf die Architektur-Entwicklung konzentriert und die Umsetzung anderen überlässt. Aber ist auch ziemlich sinnlos und unwahrscheinlich, da Nvidia mit -neben AMD- über mit Abstand das meiste Know-How über die Produktion größerer GPUs besitzt. Sinn machen die Lizensierungen also nur in Bereichen, in denen Nvidia bislang das Nachsehen hat, vor allen Dingen ultra mobile SoCs.

 

[Skysnake]

Es geht nicht um AMD vs. Nvidia, es geht um die Entscheidung gegen PhysX/CUDA und für OpenCL. Und wie bereits erwähnt geht es auch nicht um die erste Beta, sondern es geht um den Zeitpunkt, an dem man versucht hat, OpenCL flächendeckend verfügbar zu machen.
Soweit ich das nachvollziehen kann, war die erste normale Catalyst-Ausgabe mit OpenCL Unterstützung der 11.1 von Anfang 2011. gegen PhysX und "für" OpenCL hat man sich aber Anfang 2008 entschieden. Das sind milde drei Jahre, in der IT-Branche eher als "Aeonen" denn "verdammt spät" bekannt.

Die Aufnahme des OpenCL-Supports in den Grundtreiber hat aber nichts mit mangelndem Support an sich zu tun, sondern einfach nur mit Firmenpolitik. Über die kann man gerne streiten, und wie schon oben gesagt, hätte ich es auch gern früher gern im Grundgerüst drin gehabt, man kann deswegen aber nicht den prinzipiellen Support verleugnen.

Eben nicht, dass ist ja das geniale an PhysX. Im Gegensatz zu allen Konkurrenzangeboten kann es dem Entwickler vollkommen egal sein, ob das ganze später auf einem CPU- oder GPU-Client läuft. Hauptsache, die Gesamtleistung stimmt. Es ist also in einer Vielzahl von Titeln möglich, mit einer CUDA-tauglichen GPU einer schwächelnden CPU unter die Arme zu greifen.

GPU-PhysX unterscheidet sich schon von CPU-PhysX. Das kannst du nicht miteinander vergleichen...

Du kannst "normale" CPU-PhysX Sachen auch oft gar nicht auf nen GPU auslagern, also wenn es sich um eine dGPU handelt, da die Aufgaben VIEL!!! zu klein sind. Da wärst du schneller es einfach auf der CPU laufen zu lassen. Bei iGPUs sieht das natürlich wieder anders aus, wenn man einen gemeinsammen Adressraum hätte, aber nVidia ist davon noch weit entfernt, und das implementiert sich auch nicht mal eben so, und dann muss dort die Software sehr sehr sicher auch wieder expliziet angepasst werden durch die Entwickler, und wenn es sich nur um ein Neucompilieren handelt, was ziemlich sicher bei derart fundamentalen Änderungen nicht ausreichen wird.

OpenCL dagegen verlangt vom Entwickler, explizit für GPU zu entwickeln, ggf. sogar noch getrennte Fallbacks bereitzuhalten, und bietet keinerlei Kompatibilität zu bestehenden Titeln.

Öhm nö.

Du kannst ne CPU ohne Probleme als Fallback impelentieren. Das sind nur wenige Zeilen Code. Dass die Performance dann nicht sonderlich ist, ist ein anderes Thema, aber ein Fallback ist relativ schnell implementiert.

Wenn ich eine ARM-GPU in mein SoC integriere, dann bringt mir das: Grafikausgabe. Sonst nichts.

Sorry, aber das ist einfach falsch...
Mali-T622 - ARM

Die neueren Mali GPUs bieten OpenCL 1.1 Support. Ob auch OpenCL 1.2 aktuell unterstützt wird weiß ich nicht, wird aber sicherlich bald kommen.

Und damit nicht genug, es gibt auch Mali mit DX11 Support, und damit DirectCompute.....

Wenn ich eine PowerVR-GPU in mein SoC integriere, dann bringt mir das: Grafikausgabe. Sonst nichts.

Sorry, aber auch DAS ist einfach falsch...
PowerVR? Series6 IP Core

Alle SGX Series 6 GPUs von PowerVR unterstützen OpenCL 1.x
Dazu kommt noch DX10 Support, und damit soweit ich das weiß auch eben support von DirectCompute

Wenn ich ein custom-SoC bei AMD kaufe, dann bringt mir das: (ne CPU & ) Grafikausgabe und sonst nichts.

Falsch, du hast auch Support für DirectCompute und OpenCL. Zudem für HSA bei den neueren Semi-Custom-APUs, die du dir besorgen kannst.

Zudem wirst du den Zugriff auf die Freedom-Fabric erhalten, die wie es scheint doch ziemlich brauchbar ist.

Ganz zu schweigen von so Nebenkriegsschauplätzen wie:

• PCI-E 3.0 Controller mit Rootcomplex
• SATA 2/3 Controller
• USB 2/3 Controller
• NIC ist meines Wissens bei denen auch integriert, wird aber meist nicht genutzt. Zumindest ist es so bei den Chipsätzen für AM3(+)
• Eventuell auch Raidsupport, da bein ich mir aber nicht sicher, kann aber sicherlich als Option zugekauft werden

Sorry, aber der EINZIGE, der NICHTS aber auch wirklich GAR NICHTS! außer Grafik im SFF/Mobile Markt bietet außer Grafikausgabe ist nVidia.... Die haben den "Trend" völlig! verschlafen. Die hinken da unglaublich weit zurück. Sorry, aber was du da gerade geschrieben hast ist totaler Stuss. nVidia ist in dem Markt einfach nur schlecht was das Featureset anbelangt. Deswegen verkaufen sich wohl ihre Tegras auch so schlecht.

Wenn ich aber eine aktuelle Nvidia-GPU in mein SoC integriere, habe ich neben dem Rendering noch eine deutliche CPU Entlastung in einer Vielzahl bestehender, populärer PC, X360 und PS3 Titel.

Nein hast du nicht....

Soll ich dir auch sagen warum?

Du kannst weder die PC noch die X360 geschweige denn die PS3 Titel starten.... X360 und PS3 sollten klar sein, das sind propritäre Konsolen, ich frag mich, wie du da berhaupt darauf kommst

Und PC geht auch nicht, weil du eben in keinen SOC eine nVidia GPU integrieren kannst, die x86 Code ausführen kann, außer VIA nimmt sich dessen an, aber wie war das mit der "zu geringen CPU Leistung von AMD"?

VIA ist in einem KOMPLETT! anderen Markt unterwegs als Intel und AMD. Das kannste total knicken...

Sorry, aber das sind gerade echt nur Nebelkerzen. Ohne MINDESTENS! Neucompilieren, kannste da gar nichts reisen. Am Ende wirst du aber sogar große Anpassungen durchführen müssen, da du eben die Software auf ARM/MIPS/PowerPC/SPARCE portieren müsstest....

Und das wird KEINER! machen, und selbst WENN, dann hättest du noch immer ein riesen Problem... Die Software, die du dir vorstellst/nennst, läuft unter Windows... Viel Spaß mit ARM/MIPS/PowerPC/SPARCE und Windows......

Also gerade auch Spielen, deren Leistungsanforderungen in dem Bereich liegen, in dem in 1-3 Jahren (="1 Entwicklungszyklus") Tablets zu erwarten sind. Und das ohne irgend eine Änderung an der Physik-Engine vornehmen zu müssen.

Nein... Da Software inkompatibel...

PCI-E und RAM sind externe Schnittstellen. Die unterzubringen erfordert natürlich etwas Planung, sonst kommst du an deine I/O Pads überhaupt nicht angemessen ran. Eine iGPU dagegen muss (fast) "nur" mit *was auch immer du in deiner CPU an Interconnect nutzt* (Crossbar, Ringbus, ggf. PCIe selbst, wenns ein einfaches Design wird?) verbunden werden.

Ja, du musst das an die internen Strukturen anpassen, dazu musst du aber die Interfaces an der richtigen Stelle haben, und überhaupt erstmal kompatible Schnittstellen haben, die dir nicht Leistung und Latenzen OHNE! Ende fressen....

Sicherlich ist das nicht leicht, aber es ist ein Funktionselement, dass sich seinerseits an Bedürfnisse anpassen lässt - wesentlich freier als z.B. ein RAM-Controller, der nun einmal zwingend an einer Außenkante liegen sollte, weil er viele Anbindungen braucht.

Nein, es ist nicht einfacher, weil du ja einen gemeinsammen Adressraum haben willst, ansonsten ist das Ding nicht Konkurrenzfähig gegen die AMD/HSA Lösungen der Konkurrenz, die in absehbarer Zeit kommen werden.

Und bezüglich der Anordnung und "kleiner" und "großer" Chipkomponenten: Llano hat die GPU als Block in einer Hälfte. Trinitiy hat die GPU als Block in einer Hälfte. Sandy Bridge hat die GPU als Block in einer Hälfte. Ivy Bridge hat die ... . Haswell hat ... . Kal El hat ... . Wayne ... .

Dir ist schon klar, dass das jeweils eine Vielzahl wiederum kleine IP-Block ist, die z.B. SRAM, ALUs, Branchprediktion usw ist. Das erkennst du dann auch mit dem Auge. Sprich, alles was klare Strukturen hat ist im Normalfall von Hand entworfen, gelayoutet und geroutet. Das ist aber nur ein Teil eines Chips. Die gesamte Verbindung dieser kleineren IP-Block erfolgt aber normal mittels tools heutzutage. Und da sprechen wir von CPUs un I/O Blocks....

Wir müssen aber über GPUs! sprechen, wo die Sache FUNDAMENTAL! anders aussieht. Hier wird fast alles syntethisiert... Deswegen erkennt man auf GPUs auch fast keine klaren Strukturen, weil eben fast alles durch Tools gejagt wird....

Und selbst bei den Sachen, die so tool klar strukturiert aussehen, hast du dazwischen immer mehr oder weniger große Areale, die auch wieder syntethisiert sind. Und da steckt eben auch oft noch sehr sehr viel Logik drin. Gerade bei GPUs ist es so, weil man Durchsatzoptimierte Designs hat. Das würdest du von Hand gebaut gar nicht so hinbekommen... Da gehen die einzelnen Funktionsblöcke auch fließend ineinander über. Schau dir mal ein Blockschaltbild/Floorplan eines Jaguar-Cores an.... Da siehst du mal ansatzweise, wie stark die einzelnen Bereiche ineinander übergehen...

Ich gebe zu, dass ich mir Insiderwissen klar fehlt. Aber wenn jedes einzelne full custom Design (alias "für uns selbst") mit nenenswerter iGPU diese als einen großen, in sich geschlossenen Block positioniert, dann frage ich mich doch, warum das bei einem semi-custom auf einmal unmöglich sein sollte.

Genau das ist eben das Problem...

Das sieht für den Laien so aus, weil er eben nur mit den Augen das sieht. Wenn du aber dich damit beschäftigst, dann wird dir mit der Zeit klar, dass das eben weit weg von der Realität ist, was man so als Laie denkt. Die ganzen Sachen sind VIEL komplizierter als man denkt, und der Wahnsinn/Teufel steckt im Detail... Man sieht die meisten komplexen Sachen einfach gar nicht, weil Sie eben nur als Graue-Masse erscheinen, da synthetisiert...

Es gibt Firmen, die fertige IP-Blocks anbieten, und das doch so manche die eben geschlossene IP-Blocks verkaufen, also den Quellcode NICHT bekommst. Da bist du aber auf EXTREM! viel und guten Service/Support angewiesen. Wenn der fehlt, rennste dir als Firma schnell den Kopf ein, weil du IMMER! auf Probleme stößt, die es zu klären gibt. Daher ist das IP-Geschäft auch kein einfaches. Es bedarf da eines großen Vertrauens. Du musst ja bedenken, dass da Multimillionen $ Investitionen getätigt werden, die schnell in den Sand gesetzt werden können.

Wir hatten es heute erst im Meeting. Da hat unser Chef gesagt, dass im IP-Bereich leider viel zu viele Verbrecher/Betrüger rum rennen, und man aufpassen muss wie noch was, das man auch wirklich das bekommt, was man erwartet...

So manche Firma versucht dir nämlich Produkte an zu drehen, die noch gar nicht fertig sind.... Und dann passiert es auf einmal, das du x Monate delay hast, weil dein Zulieferer nicht mit seinem IP-Block fertig wird. Oder die Spezifikationen der Schnittstellen ändern sich, oder oder oder oder....

Du brauchst da einfach VERDAMMT verlässliche Partner, und sorry, nVidia steht NICHT gerade dafür ein verlässlicher Partner zu sein... Die letzten Jahre glänzt nVidia eigentlich nur mit einem: Verschiebungen, und revidieren von Roadmaps usw....

Sorry, aber als Chef einer Firma würde ich wohl als letztes an nVidia denken, wenn es um IP-Blöcke geht. Wenn dann nur mit abartig krassen Konventionalstrafen. Aber selbst dann hätte ich noch Angst, das nVidia Probleme macht. Vor allem, als IP-Nehmer muss ich ja nicht nur mit normalen Delays klar kommen, nein, wenn der IP-Anbieter meint, er müsse schnittstellen oder LAyouts oder oder oder ändern, dann biste der gearschte, weil du je nachdem nochmal komplett von vorne anfangen kannst, dein Package, dein LAyout und Routing zu machen... NA GZ sag ich dir da... Da willste alles, nur nicht mit ner Firma zusammenarbeiten, die schon ihre eigenen Roadmaps immer und immer wieder grandios in den Sand setzt...

Sowohl Nvidia als auch AMD leisten es sich nicht einmal ein zweites Stepping des Transistorlayers. Entweder sind das also gnadenlos begabte Hellseher, die alles, wirklich alles im vorraus planen können (im Gegensatz zu z.B. den Loosern bei Intel, die manchmal 3-4 Versuche brauchen), oder da kann nicht alzuviel Entwicklung drin stecken, die nicht zu 99% von TSMC übernommen wurde...

Dir ist schon klar, das AMD und nVidia über viele viele Jahre ihre Bibliotheken haben reifen lassen, genau wie ihre Tools. Allein von einem Tool auf ein anderes um zu steigen kann dich Wochen/Monate an Entwicklungszeit kosten....

nVidia und AMD sind teilweise weit weg von dem, was du als "0815" TSMC Kunde bekommst. Die überziehen die Designrules von TSMC, einfach weil Sie ihre eigenen Entwicklungen mit einbringen, und genau deswegen stehen Sie auch da wo Sie heute sind. An der Spitze.

Und ja: TSMC bietet einem ein paar Möglichkeiten. Was spricht dagegen, die zu nehmen, für die man ein fertig optimiertes Design kaufen kann?

Ein paar?

Du meinst wohl eher hunderte....

Das größte Problem von Tegra ist, dass er eine zu eingeschränkte CPU-Konfiguration hat (siehe den nachgeschobenen i), um einen größeren Marktbereich abzudecken, und dass die Entwicklungskosten für diese auch noch in keinem Verhältnis zum Ergebnis stehen, weil Nvidia eben keine Ahnung von CPUs hat. Beide Probleme lösen sich in Luft auf, wenn man die Konzeption von CPUs Leuten überlässt, die sich mit sowas auskennen.
Und zum Minusgeschäft: Wenn man (quasi) keine Investitionen hat, kann man auch keine Verluste machen. Die Entwicklung der Grafikeinheiten als solche ist für Nvidia quasi umsonst, denn die sollten ab der nächsten Generation sowieso runterskalierte Desktop-Architekturen sein. Man muss lediglich den Personalaufwand finanziert bekommen, der bei der technischen Unterstützung des Kunden anfällt (Implementation und ggf. Anpassung der Schnittstelle zur restlichen CPU). Sobald der Kunde 1 € mehr zahlt, als diese Techniker kosten, macht Nvidia Gewinn.
Und selbst wenn er nur ±0 diese Kosten zahlt, ist die Sache für Nvidia lohnend. Denn so erhält man mehr Aufmerksamkeit, ist für Entwickler attraktiver (bzw. "produziert" umgekehrt mehr Entwickler, die sich schon mit der Architektur auskennen) und vor allem: Verbreitet CUDA. Und im Gegesatz zu AMD und Intel mit ihren ultra mobilen Ambitionen riskiert Nvidia mit kleineren iGPUs keine Eigenkonkurrenz zu bestehenden Produkten. Es ist schlichtweg ein Markt, auf dem man -abseits des wohl gefloppten Tegra- nicht präsent ist und den man nun versucht, von Lizenznummern zum Nulltarif (bzw. Plustarif) erobern zu lassen.

Du hast nicht mal den Ansatz einer Vorstellung davon, welcher Aufwand es für nVidia mit derartigen spezialisierten Designs den IP-Markt zu betreten. Den Support den die Leisten müssen ist extrem, und die Leute wachsen nicht auf Bäumen... Selbst mit allem Geld der Welt bekommst du nur schwer Leute mit dem entsprechenden Know-How .....

Support von IP-Nehmern bedeutet also zwangsläufig weniger Leute in der Entwicklung eigener Produkte.... Und du kannst gift darauf nehmen, dass das wie der Hüten eines Sackes voller Läuse ist....

 

[ruyven_macaran]

Die Aufnahme des OpenCL-Supports in den Grundtreiber hat aber nichts mit mangelndem Support an sich zu tun, sondern einfach nur mit Firmenpolitik. Über die kann man gerne streiten...

Schön, dass du das Thema dieser Diskussion entdeckt hast.

Du kannst "normale" CPU-PhysX Sachen auch oft gar nicht auf nen GPU auslagern, also wenn es sich um eine dGPU handelt, da die Aufgaben VIEL!!! zu klein sind. Da wärst du schneller es einfach auf der CPU laufen zu lassen.

Du wärst vielleicht schneller (wenn du denn die nötige Leistung hättest.), aber das hat nichts mit "können" zu tun. Du kannst die Berechnungen (afaik) nämlich sehr wohl auf eine GPU oder auch PPU oder halt auch x86 bzw. PowerPC CPU packen, wie du lustig bist. Und das tolle: "Du" als Anwender kannst das. Nicht ein "Du" als Entwickler muss es vorher machen.

Du kannst ne CPU ohne Probleme als Fallback impelentieren. Das sind nur wenige Zeilen Code. Dass die Performance dann nicht sonderlich ist, ist ein anderes Thema, aber ein Fallback ist relativ schnell implementiert.

Nach dem, was ich gehört habe, soll die Performance von CPU-OpenCL Clients weit, weit hinter konventionellen Physik-Engines und auch hinter aktuellen CPU-PhysX zurückliegen. Vor allem aber bleibt das Problem bestehen, dass niemand in der Vergangenheit OpenCL genutzt hat - PhysX dagegen schon.

Du brauchst da einfach VERDAMMT verlässliche Partner, und sorry, nVidia steht NICHT gerade dafür ein verlässlicher Partner zu sein... Die letzten Jahre glänzt nVidia eigentlich nur mit einem: Verschiebungen, und revidieren von Roadmaps usw....

Kann ich nicht beurteilen - ich habe keinen Zugriff auf Roadmaps und interne Zeitpläne. Wenn du mehr weist (und zwar aus der Hardwareentwicklung), verate es uns. Andeutungen und Themenwechsel bringen die Diskussion nicht wirklich vorran.

nein, wenn der IP-Anbieter meint, er müsse schnittstellen oder LAyouts oder oder oder ändern,

Was für physische Schnittstellen willst du denn an einer GPU ändern? Die haben klassischerweise genau eine zum Restsystem...

nVidia und AMD sind teilweise weit weg von dem, was du als "0815" TSMC Kunde bekommst. Die überziehen die Designrules von TSMC, einfach weil Sie ihre eigenen Entwicklungen mit einbringen, und genau deswegen stehen Sie auch da wo Sie heute sind. An der Spitze.

Und trotzdem bist du der Meinung, die einzig richtige Variante wäre es, ein Nvidia-Konzept komplett selbst zu implementieren, anstatt ein fertiges Layout zu verwenden...

Du hast nicht mal den Ansatz einer Vorstellung davon, welcher Aufwand es für nVidia mit derartigen spezialisierten Designs den IP-Markt zu betreten.

Aber zum Glück weiß Herr Skynake ganz genau, welchen Aufwand die komplett unbekannten Buisnesspläne und kommenden Vertragsdetails von Nvidia für unbekannte Kunden in unbekannten Anwendungsbereichen verursachen

 

[Skysnake]

Ich weiss wieviel Aufwand wir mit unseren IP Blocks haben....

Das reicht mir. Ich lass mich gerne von nVidia positiv ueberraschen, aber ich wuerde mich nicht auf nVidias Aussagen verlassen, wenn es um mein Geld geht. Dafuer sind in der juengsten Vergangenheit einfach zu viele Delays von offiziellen Roadmaps/Launch Aussagen passiert, zusammen mit nicht einhalten der Versprechungen im Vorfeld.

Bzgl Schnittstellen.

Klar, du kannst as alles 0815 machen, am Besten noch mit PCI-E als Schnittstelle dazwischen, aber die Effizient kannste dann in der Pfeife rauchen, und genau das ist halt das Problem. nVidia ziehlt ja auf den Mobile/SFF Markt damit ab, bei dGPUs machts ja kaum Sinn, und da kannst du dir halt einfach nicht erlauben mal hier und mal dort x% Effizienz zu vergeuden. Wenn du mit der Einstellung ran gehst, brauchst du gar nicht erst anfangen ein custom-Design zu machen, weil du nicht das entsprechende Ergebnis raus bekommst, und gleich auf nen Chip von der Stange zurueckgreifen kannst.

Die Probleme/Einschraenkungen kommen von ganz allein, da brauchst du nicht noch mehr. Und genau deswegen ist das IP-Geschaeft eben nicht nur das Anbieten eines komplett fertigen IP-blocks, an dem man nichts mehr schrauben muss fuer jedweden Kunden. Da haengt einfach mehr dahinter, und das wissen die IP-Kunden auch. Ohne support kauft dir keiner nen IP/Block ab. Ohne Support ist es naemlich schon praktisch im Voraus klar, dass du scheitern wirst. Irgendwas macht IMMER! Probleme.

Was glaubst du, warum bei uns die Leute schon fast Paranoid in der Entwicklung sind? Richtig, weil staendig hinter irgend einer Ecke irgend nen Mist lauert, der dann am Ende doch Probleme macht... und wenns nur son mist ist, wie Entwicklungssoftware, die die Simulation nach >10h abbricht, weil zu viele/zu wenige Parameter angegeben sind, und das Tool sich dann verschluckt...

Full Custom Designs sind ja ehm... der Weg in den Wahnsinn ums mal so zu sagen, und nvidia hat Full Custom Designs, und nicht gerade welche die total konservativ sind, und ueberall die grossen Sicherheiten/Tolleranzen einplanen....

 

[ruyven_macaran]

Sicherlich wäre PCIe im UM-Bereich nicht das naheliegenste (wobei sich das ändern könnte, wenn einer der Vorstöße von AMD oder Intel erfolgreich ist. Denn die haben bislang alle eh PCIe Controller und ein einheitlicher Standard -ggf. für hochintegrierte UM auf LV adaptiert- ist eben schon was feines).
Aber mir geht es vor allen Dingen um Schnittstellen. Es gibt nicht mehrere. Wenn du was anderes als PCIe nimmst, hast du halt "das was anderes ist als PCIe". Und es wird genau die gleiche Funktion an genau der gleichen Position übernehmen. Warum sollte da irgendjemand etwas daran ändern wollen und Inkompatibilitäten verursachen? Und vor allen: Warum sollten sich diese Änderungen auf die weiter hinten liegenden Ausführungseinheiten auswirken? Die Schnittstelle selbst nimmt einen so winzigen Raum ein, dass eine ineffizientere Raumnutzung kaum einen Unterschied macht und allein die gespaarte Entwicklungsverzögerung wert wäre.

 

[Skysnake]

Ganz einfach, weil es sich dabei um Laufzeitkritische Datenpfade handelt.

Die Anordnung des restlichen Chips beeinflusst die Art und Weise wie du die Interfaces ausgestalten musst.

Klar, du kannst da einfach Flip/Flops dazwischen packen, aber das erhöht die Latenz, und kostet auch unnötig Energie, und genau das ist halt der Knackpunkt, den ich oben versucht habe zu umreisen. Klar, du kannst das immer über "standardisierte" Interfaces lösen, so dass du nie Probleme hast, und den IP-Block an sich gar nicht anfassen musst. Von Performance, Perf/W und Perf/mm² kannst du dich dann aber gleich mal verabschieden. Die Lösung ist dann nur eins: "billig in der Implementierung", wobei das aber auch NUR! gilt, wenn der IP-Verkäufer richtig richtig richtig gute Arbeite geleistet hat, und alles bis zum Erbrechen nach außen gekapselt hat. Du unterschätzt einfach die Auswirkungen, die bereits kleinste Änderungen auf ein Chipdesign nehmen können. Selbst mit 100% identischen Sourcen kann aus den Tools verdammt unterschiedliche Layouts rauskommen, wo selbst größere Funktionsblöcke ihre Position ändern... Die Tools machen einfach nur Näherungen, weil das Problem zu komplex ist für eine vollständige Lösung.

Ich kann mir aber nicht vorstellen, das jemand an so etwas Interesse hat. Dafür sind die NAchteile zu groß. Vor allem, WENN! nVidia ein Design raus bringen würde, was mit diesen Einschränkungen immer noch gut wäre, dann würden ihre angepassten eigenen Designs die Konkurrenz schlicht platt machen....

Also warum sollte ich mir dann nur ein IP für die iGPU holen, und nicht den kompletten SOC?

Sorry, das ist das nicht besser/leichter verständlich erklären kann, aber die Thematik ist wirklich nicht so einfach, da der Teufel im Detail steckt. Nur mal so, obwohl ich ziemlich konservativ und Zurückhaltend bin, werde ich von den Leuts die bei uns den Chip designen immer eingebremst. Das ist halt ALLES viel viel viel komplizierter als man sich das Vorstellen kann, und ich zieh echt meinen Hut davor, dass AMD, nVidia und Intel überhaupt ihre Chips derart ans laufen bekommen.

PS:
Sorry, den kann ich mir gerade nicht verkneifen "Herr Ruyven"
Wie wars das mit der iGPU und man kann Sie nur für die Ausgabe nutzen?

PPS:
Ruyven, du darst mich auch nicht falsch verstehen, ich fände es durchaus cool, wenn nVidia wirklich ihre aktuellen Designs als IPs verkauft. Da hätte ich schon so manche Idee, wie man daraus ziemlich coole Sachen machen könnte, nur sagt mir meine Intuition, die mich selten täuscht, das nVidia für so etwas nicht der richtige Partner ist, und da bin ich nicht der Einzige, der dieses "Gefühl" hat.

 

[ruyven_macaran]

Du redest schon wieder von Änderungen im IP Block selbst. Darum gehts nicht. Wir haben eine fertig gelayoutete GPU-Fläche (die auch von keinen Tools mehr bearbeitet werden muss), an einer Kante sind eine Schnittstelle. Alle latenzkritischen Pfade innerhalb der GPU sind fertig optimiert, auch alle, die zur Schnittstelle führen. Das einzige, was ggf. anzupassen ist, ist die Schnittstelle selbst, die die Informationen am Anfang der Pipeline in Empfang nimmt, noch bevor auch nur eine Trennung zwischen Daten und Befehlen erfolgt ist.

Und bezüglich des Vergleichs mit eigenen Designs:
Wie bereits erwähnt hat Nvidia nur eingeschränkt Ahnung von CPUs. Und so gut wie gar keine Kompetenzen mehr für externe Schnittstellen. Die brauchst du aber auch für ein SoC und Tegra beweist, dass Nvidia einiges an Arbeit reinstecken muss, um halbwegs konkurrenzfähig zu sein. "Halbwegs" lohnt sich aber nicht, erst recht nicht, wenn ein einziges Produkt bei raus kommt für einen Markt, der eine große Bandbreite an Anforderungen stellt. Nvidia hat jetzt drei Optionen:
a) massiv investieren und eine UM-SoC Entwicklung von den Dimensionen aufbauen, wie sie Samsung, Qualcomm oder Apple haben. Hierzu muss man dann nebenbei vermutlich gleich noch deren Gehälter deutlich überbieten, wie du selbst schon festgestellt hast
b) sich ganz von DEM Boomarkt schlecht hin verabschieden und andere die Gewinne machen lassen
c) nur noch den GPU-Teil verkaufen und den Rest jemandem überlassen, der sich mit sowas auskennt. Und es gibt viele am Markt, die sich mitterweile sehr gut mit der Implementierung von ARM-Cores auskennen, die aber keine eigene GPU-Kompetenz haben und, wie beschrieben, auch sehr wenig Lizensierungsalternativen, wenn sie Leistung und Features wollen.


Bezüglich der Ausgabe: Du hast mal wieder ne imposante Latte Besserwisserei runtergerattert, aber irgendwie war kein einziger Fall dabei, in dem eine lizensierbare non-Nvidia-GPU in bestehender Software mehr als eben Grafikberechnung hätte übernehmen können.


Bezüglich Nvidia als Firma: Dazu erlaube ich mir kein Urteil, da ich wie gesagt keinerlei Einblicke in die hier relevanten Bereiche habe. Softwareseitig, wo man mehr mitbekommt, sind sie sicherlich niemand, auf den man sich verlassen will. Aber hier gehts halt um die Hardwareabteilungen und die haben, mit Ausnahme der erfolgreichen Kooperationen im Konsolenbereich, die eben zumindest auch Fremdfertigung und afaik sogar Fremdimplementierung von Shrinks auf Basis von Nvidia-IP beinhalteten, bislang noch nie etwas derartiges gemacht.

 

[Skysnake]

Du redest schon wieder von Änderungen im IP Block selbst. Darum gehts nicht. Wir haben eine fertig gelayoutete GPU-Fläche (die auch von keinen Tools mehr bearbeitet werden muss), an einer Kante sind eine Schnittstelle. Alle latenzkritischen Pfade innerhalb der GPU sind fertig optimiert, auch alle, die zur Schnittstelle führen. Das einzige, was ggf. anzupassen ist, ist die Schnittstelle selbst, die die Informationen am Anfang der Pipeline in Empfang nimmt, noch bevor auch nur eine Trennung zwischen Daten und Befehlen erfolgt ist.

Das versuch ich dir ja klar zu machen, dass sich das zwar in der Theorie zwar toll anhört, aber bei so performancekritischen Sachen einfach nicht so einfach funktioniert, ohne an den verschiedensten Stellen einfach Verluste zu haben, und da der Markt hier so sensitiv ist, kannst du dir diese Verluste einfach nicht leisten.

Und bezüglich des Vergleichs mit eigenen Designs:
Wie bereits erwähnt hat Nvidia nur eingeschränkt Ahnung von CPUs. Und so gut wie gar keine Kompetenzen mehr für externe Schnittstellen. Die brauchst du aber auch für ein SoC und Tegra beweist, dass Nvidia einiges an Arbeit reinstecken muss, um halbwegs konkurrenzfähig zu sein. "Halbwegs" lohnt sich aber nicht, erst recht nicht, wenn ein einziges Produkt bei raus kommt für einen Markt, der eine große Bandbreite an Anforderungen stellt. Nvidia hat jetzt drei Optionen:
a) massiv investieren und eine UM-SoC Entwicklung von den Dimensionen aufbauen, wie sie Samsung, Qualcomm oder Apple haben. Hierzu muss man dann nebenbei vermutlich gleich noch deren Gehälter deutlich überbieten, wie du selbst schon festgestellt hast
b) sich ganz von DEM Boomarkt schlecht hin verabschieden und andere die Gewinne machen lassen
c) nur noch den GPU-Teil verkaufen und den Rest jemandem überlassen, der sich mit sowas auskennt. Und es gibt viele am Markt, die sich mitterweile sehr gut mit der Implementierung von ARM-Cores auskennen, die aber keine eigene GPU-Kompetenz haben und, wie beschrieben, auch sehr wenig Lizensierungsalternativen, wenn sie Leistung und Features wollen.

nVidia sollte einfach mal Tegra richtig angehen, und nicht zich Jahre alte Technik verwenden... Wenn ich zich Jahre hinter der Konkurrenz bzgl Featureset usw bin, dann ist es einfach kein Wunder, das keine Sau sich für die eigenen Produkte interessiert.

Ich versteh allerdings nicht, wie du darauf kommst, das nVidia keine Kompetenz für "externe Schnittstellen" hat

PCI-E, GDDR, DDR3, LTE/G3(?), DVI, DP, HDMI, SATA2 und USB haben Sie alles im Haus, da schon mal entwickelt. Also das Sie keine "Kompetenz für externe Schnittstellen" im Haus hätten finde ich etwas "merkwürdig"
Wie kommst du darauf?

Sie haben ja lang genug Chipsätze entwickelt, und das Know-How ist noch da, selbst wenn einzelne Leute abgewandert sind. Vor allem im SFF/Mobile Markt, kann man sich bzgl Schnittstellen relativ entspannt zurücklehnen, das ist ziemlich überschaubar, und kann zur Not auch durchaus realtiv einfach über IPs eingekauft werden. Da gibt es genug Angebote. Und gerade! LTE sieht ja gut aus. nVidia hat ja nicht ohne Grund die eine Firma für die Modems übernommen. Also da sollte mehr als genug Know-How vorhanden sein in diesem Bereich. Ich versteh daher wirklich nicht, wie du zu dieser Meinung kommst

Bezüglich der Ausgabe: Du hast mal wieder ne imposante Latte Besserwisserei runtergerattert, aber irgendwie war kein einziger Fall dabei, in dem eine lizensierbare non-Nvidia-GPU in bestehender Software mehr als eben Grafikberechnung hätte übernehmen können.

openclnews.com/blog/image_processing_effects_in_camera_application_on_android_tablet_opencl

Und nein, ich such jetzt nicht noch mehr raus, weil:

1. Mich Android NULL interessiert, da ich kein Smartphone besitze, und dafür auch nicht vor habe zu entwickeln...
2. Es schwer ist etwas zu finden, da nicht immer klar ist, ob jetzt OpenCL genutzt wird oder nicht, und ich, wegen 1., eben auch keine Android-Software kenne
3. Es wohl auch nicht sooo viele Beispiele bisher gibt, da die Softwarebranche hier schon noch Zeit braucht, bis die Produkte auf dem Markt ankommen.

Bezüglich Nvidia als Firma: Dazu erlaube ich mir kein Urteil, da ich wie gesagt keinerlei Einblicke in die hier relevanten Bereiche habe. Softwareseitig, wo man mehr mitbekommt, sind sie sicherlich niemand, auf den man sich verlassen will.

Tolle Vorraussetzung nicht?

Aber hier gehts halt um die Hardwareabteilungen und die haben, mit Ausnahme der erfolgreichen Kooperationen im Konsolenbereich, die eben zumindest auch Fremdfertigung und afaik sogar Fremdimplementierung von Shrinks auf Basis von Nvidia-IP beinhalteten, bislang noch nie etwas derartiges gemacht.

Ja supi gell. Der Firma schmeis ich mich doch direkt an den Hals...

Wobei ich den Entwicklern an sich das schon zu traue, das zu wuppen, wenn das Management da aber nicht mit spielt, und nicht auch die entsprechendne Ressourcen frei macht, dann können die Ingis noch so gut sein wie Sie wollen. Zaubern können Sie halt auch nicht...

Und genau das ist das Problem, welches ich mit nVidia habe. Die Firmenphilosophie der letzten X Jahre/Jahrzehnt passt einfach nicht zu dem, wie ne IP-Firma mit Kunden umgehen muss.

 

[ruyven_macaran]

Das versuch ich dir ja klar zu machen, dass sich das zwar in der Theorie zwar toll anhört, aber bei so performancekritischen Sachen einfach nicht so einfach funktioniert, ohne an den verschiedensten Stellen einfach Verluste zu haben, und da der Markt hier so sensitiv ist, kannst du dir diese Verluste einfach nicht leisten.

Wie wäre es, wenn du einfach mal n paar Beispiele nennst, welche Verluste wieso an so einer Stelle auftreten können?

nVidia sollte einfach mal Tegra richtig angehen,

"einfach" ist das eben nicht.

Ich versteh allerdings nicht, wie du darauf kommst, das nVidia keine Kompetenz für "externe Schnittstellen" hat

PCI-E, GDDR, DDR3, LTE/G3(?), DVI, DP, HDMI, SATA2 und USB haben Sie alles im Haus, da schon mal entwickelt.

Das Nvidia herrausragender Hersteller von LTE-Controllern ist, wusste ich nicht. PCIe, GDDR, DVI und SATA werden ihnen im mobile-Markt nichts nutzen, USB kann jeder, mini-DP ist ne ziemliche Niesche. Wichtig und mit Optimierungspotential versehen sind BT, eine breite Palette an Flash-Interfaces, schmalbandiges lpDDR, Sound-Ausgabe und hochwertige Filterroutinen für den Mic-In. Dazu *was auch immer an diversen Schnittstellen für die Anbindung des Krimskrams von Cam bis SIM benötigt wird*, wobei es da natürlich wenig zu optimieren gibt.
Ich wüsste nicht, dass sich Nvidia in irgend einem dieser Bereiche einen Namen gemacht hat. (Sieht man mal von der 10 Jahren alten, nicht übertragbaren aber guten Idee ab, sich ne Dolby-Encoding Lizenz für eine Soundlösung zu leisten )

Es wohl auch nicht sooo viele Beispiele bisher gibt, da die Softwarebranche hier schon noch Zeit braucht, bis die Produkte auf dem Markt ankommen.

Ach sie an.
Aber trotzdem widersprichst du standhaft der Feststellung, dass OpenCL derzeit denkbar wenig bringt...

Wobei ich den Entwicklern an sich das schon zu traue, das zu wuppen, wenn das Management da aber nicht mit spielt, und nicht auch die entsprechendne Ressourcen frei macht, dann können die Ingis noch so gut sein wie Sie wollen. Zaubern können Sie halt auch nicht...

Und genau das ist das Problem, welches ich mit nVidia habe. Die Firmenphilosophie der letzten X Jahre/Jahrzehnt passt einfach nicht zu dem, wie ne IP-Firma mit Kunden umgehen muss.

Und da muss man halt abwarten. Denn die letzten x Jahre wollte man das eben auch gar nicht sein und offensichtlich hat sich etwas geändert. Wieviel kann man noch lange nicht sagen.

 

[Skysnake]

Wie wäre es, wenn du einfach mal n paar Beispiele nennst, welche Verluste wieso an so einer Stelle auftreten können?

Ähm....

Das ergibt sich aus dem Chipdesign heraus...

Was willst du da hören? Was man allgemein sagen kann habe ich ja bereits gesagt. Mehr gibt es dazu nicht zu sagen. Das sind ziemlich provane Dinge, die dir aber extremen Ärger bringen können. Das hängt aber immer GENAU von der jeweiligen Implementierung ab, und selbst bei der gleichen Implementierung kann ein anderes Layout und Routing wieder an ganz anderer Stelle Probleme machen...

Das Problem ist ja, Chips erstmal überhaupt ans laufen zu bekommen, und je starrer da etwas ist, desto schwieriger wird es. Zumindest die Interfaces sollten/müssen daher offen sein, damit man eine gewisse Flexibilität erreicht. Das macht das Lösen der zwangsläufig immer auftauchenden Probleme einfach einfacher, und damit deutlich kostengünstiger.

Das was du hier von mir hören willst, kann dir NIEMAND apriori sagen. Es sind wirklich immer ganz spezifische Probleme, wo einem die Laufzeiten eben um die Ohren fliegen, oder die Signalpegel, oder man muss hier nochmal nen Flip-Flop einbauen, um zwischen Taktdomänen hin und her zu kommen, was die Latenzen verschlechtert usw usw. Je starrer etwas ist, desto schlechter werden immer deine Latenzen und dein Energieverbrauch werden, einfach weil die Tools weniger Möglichkeiten zur Optimierung haben, und man selbst auch weniger "geschickte" Ideen für SEINE! ganz spezifische Implementierung einbringen kann.

"einfach" ist das eben nicht.

Naja, kommt drauf an. Wenn man sich mal dafür entscheiden würde, was man denn nun will, und genug Ressourcen/ManPower zur Verfügung stellen würde, würde das ja schonmal ausreichen. Und das ist wirklich "einfach"

Das Nvidia herrausragender Hersteller von LTE-Controllern ist, wusste ich nicht.

Doch sind Sie. Die haben doch erste neulich ne Firma aufgekauft, die Modems auf FPGA Basis bauen, was sehr platzsparend und auch Effizient sein soll.

PCIe, GDDR, DVI und SATA werden ihnen im mobile-Markt nichts nutzen, USB kann jeder, mini-DP ist ne ziemliche Niesche. Wichtig und mit Optimierungspotential versehen sind BT, eine breite Palette an Flash-Interfaces, schmalbandiges lpDDR, Sound-Ausgabe und hochwertige Filterroutinen für den Mic-In.

Ähm... welche Konkurrenz bietet denn das groß an?

Und wie sieht es im Umkehrschluss bei den Konkurrenz mit LTE aus? Ah ja richtig, die nehmen eigentlich alle soweit ich das überblicken kann von Qualcomm einen Chip/IP...

Man muss nicht immer das Rad neu erfinden. Gerade bei so standardisierten Sachen macht es durchaus Sinn, so etwas extern ein zu kaufen. Die Entwicklungsarbeit kann man sich sparen. Nen USB-Controller zu bauen sollte für nVidia kein PRoblem sein, genau wie die anderen Sachen.

Dazu *was auch immer an diversen Schnittstellen für die Anbindung des Krimskrams von Cam bis SIM benötigt wird*, wobei es da natürlich wenig zu optimieren gibt.
Ich wüsste nicht, dass sich Nvidia in irgend einem dieser Bereiche einen Namen gemacht hat. (Sieht man mal von der 10 Jahren alten, nicht übertragbaren aber guten Idee ab, sich ne Dolby-Encoding Lizenz für eine Soundlösung zu leisten )

Das läuft doch fast alles über USB usw. Die Sachen die du hier ansprichst sind absolut kein Problem. Wobei die Sache mit dem Sound von der Konkurrenz auch überhaupt nicht fokusiert wird, also keinDruck besteht, da glänzen zu müssen.

Ich seh das Problem, das du nVidia hier andichtest leider überhaupt nicht.

Ach sie an.
Aber trotzdem widersprichst du standhaft der Feststellung, dass OpenCL derzeit denkbar wenig bringt...

Konjungtiv gesehen?

Zudem unterschlägst du hier, dass das eben ein "System" Problem ist. Du brauchst erst mal Probleme, die sich überhaupt lohnen auf die iGPU zu packen. Du unterstellst ja, das es mit CUDA anders wäre, aber wieviel Software gibt es nochmal für CUDA im KONSUMER! Bereich? Und dann nochmals überlegt, wieviel dieser Software man jetzt auf einem Smartphone/Tablet laufen lassen würde....

Da wirst du nicht auf viel kommen.

Die Bereiche die sich anbieten sind Bildbearbeitung von Schnappschüssen, und packen/entpacken von Containern, und beides gibt es soweit ich das einordnen kann.

Du hättest also durch eine "CUDA"-GPU absolut keinen Vorteil gegenüber der Variante mit OpenCL. Genau das versuchst du hier aber zu suggerieren.

Du wirst auch in 10 Jahren auf Smartphones/Tablets wohl keine Unmengen an GPU-Beschlunigter Software sehen abseits von Spielen, was ja "nur" Grafikausgabe ist, und für dich ja anscheinend irrelavant in diesem Diskussionspunkt.

Und in den Konkurrenzprodukten habe ich das eben HEUTE schon drin, und nicht erst in nem Jahr(en). nVidia hat hier halt total geschlafen.


Und da muss man halt abwarten. Denn die letzten x Jahre wollte man das eben auch gar nicht sein und offensichtlich hat sich etwas geändert. Wieviel kann man noch lange nicht sagen.[/QUOTE]

 

[ruyven_macaran]

Was willst du da hören?

Ein (oder bei der Häufigkeit: 2-3) konkrete Beispiele aus der Praxis, wo ein Problem mit der Schnittstelle Änderungen in Bereichen erforderte, die in den Ausführungseinheiten hinter der Schnittstelle erforderte.

[qupte]Man muss nicht immer das Rad neu erfinden. Gerade bei so standardisierten Sachen macht es durchaus Sinn, so etwas extern ein zu kaufen.[/quote]

Das waren explizit alles Schnittstellen, die entweder wichtig für die Leistung oder, im Wechselspiel mit Sende- und Empfangsqualität, für den Stromverbrauch. Wenn man irgendwo abseits der eigentlichen CPU und GPU (die man halt bei ARM einkauft respektive bei Nvidia einkaufen soll, wenns nach Nvidia geht) einen Vor- oder Nachteil gegenüber Konkurrenten haben kann, dann da.

Die Entwicklungsarbeit kann man sich sparen. Nen USB-Controller zu bauen sollte für nVidia kein PRoblem sein, genau wie die anderen Sachen.

Wobei die Sache mit dem Sound von der Konkurrenz auch überhaupt nicht fokusiert wird, also keinDruck besteht, da glänzen zu müssen.

Weiß nicht, was die Entwicklungsabteilungen machen - aber in Tests ist Sprachqualität weiterhin ein wichtiges Kriterium für Geräte, die irgendwie irgendwo doch noch eine Telefonfunktion versteckt haben.

Du unterstellst ja, das es mit CUDA anders wäre, aber wieviel Software gibt es nochmal für CUDA im KONSUMER! Bereich?

Auf die Gefahr hin, mich zu wiederholen:
Jedes einzelne Spiel der letzten 8 Jahre, dass PhysX als Physikengine nutzt.

Und dann nochmals überlegt, wieviel dieser Software man jetzt auf einem Smartphone/Tablet laufen lassen würde....

Es werden zunehmend mehr portiert oder (wenn das eben zu aufwendig oder aus Leistungsgründen nicht möglich ist...) als Ableger/Klon umgesetzt.

 

[Skysnake]

Ein (oder bei der Häufigkeit: 2-3) konkrete Beispiele aus der Praxis, wo ein Problem mit der Schnittstelle Änderungen in Bereichen erforderte, die in den Ausführungseinheiten hinter der Schnittstelle erforderte.

Man muss nicht immer das Rad neu erfinden. Gerade bei so standardisierten Sachen macht es durchaus Sinn, so etwas extern ein zu kaufen.

Zwischen I/O und der dazugehörigen Controllerlogik und wirklichen Logik-Schaltungen gibts nen fundamentalen Unterschied, genau wie zu SRAM-logik.

SRAM, und auch I/O sind 1. durchoptimiert bis zum geht nicht mehr, weil es eben komplett starre Sachen sind, und 2. eben extrem fixiert durch diese Optimierung sind, bzw 3. einfach schon an sich limitert sind, z.B. nur am Rand sitzen dürfen. Du kommst also immer praktisch auf die gleichen Lösungen, wenn du gewisse Ziele erreichen willst.

Bei den Controllern zu I/O ist das schon wieder ein bischen anders, wobei die Logik da im Normalfall sehr begrenzt ist. Das Know-How liegt da eher in der physikalischen Implementierung des I/O denn in der Controllerlogik (zumindest zumeist).
Was einem hier auch noch zu Gute kommt ist die Tatsache, dass diese externen Interfaces für Kernverhältnisse eigentlich schnarchen langsam sind. Ok klar, intern in den Cores muss man schon schauen, das man die Sachen verarbeitet bekommt, um die Latenzen niedrig zu halten, insgesamt sind die Dinger aber eigentlich schon langsam.

Bei Logik sieht das komplett anders aus. Ne iGPU willst du mit maximalen TAkt laufen lassen, und alles was die Taktbarkeit reduziert ist scheise. Deswegen willst du auch nicht Interfaces, die ALLE möglichen Eventualität tot schlagen, was man natürlich bauen kann, sondern EIN SPEZIELLES! Interface, was halt GENAU auf deinen Chip passt. Wobei du da aber auch schnell wieder das PRoblem bekommst, das ein komplett starre IP nicht gut ist, weil sich durch unterschiedliche KErnanzahl, und sonstige Interfaces, sowie Specialfeatures die "optimale" Form des restlichen DIEs verändert.

Und totschlagen tut man Probleme bei Interfaces halt mit großen Flip-Flop/Registern, aber das verbaucht nur unnötig Strom und Platz, und haut dann auch noch auf die Latenzen....

Kleines Beispiel.

Gehen wir mal davon aus, dass es 1000 Takte braucht, um Daten von der CPU auf die iGPU zu schieben, nur "totschlagen" aller eventualitäten brauchst du aber 10 Takte mehr. Das hört sich nicht viel an, aber sind einfach mal so 1% Performance weg geworfen. Vom höheren Strombedarf ganz zu schweigen.

Das Problem ist halt auch nicht, dass das jetzt DAS Problem wäre. Das Problem ist, dass du mal hier und mal dort einen Takt verlierst. Das ist ganz normal. Manchmal geht etwas einfach nicht anders. Das zieht aber GANZ schnell einen RIESEN Rattenschwanz an PRoblemen hinter sich her. Weil du eben doch zweimal einen Takt Latenz mehr hast, musst du deine Buffer größer machen, weil der Buffer aber größer ist, muss deine Kontrollogik größer werden, weil die Größer ist, verlierst du wieder nen Takt, weil du nen Takt verlierst.....

In Chips gibt es immer Cornerpoints, die dir echt Kopfschmerzen bereiten. Packst du die ist alles gut. Packst du die nicht, musst du ziemlich viele Änderungen machen. Du musst ja ALLE! Eventualitäten abfangen, also halt ne finate State Maschine implementieren, die nie nie nie in einen nicht definierten/illegalen Zustand kommen darf. Was glaubste, warum man teilweise um Nanosekunden bei den Laufzeiten kämpft, oder um einzelne Takte. Je nachdem, wo so was ist, kann das verdammt harte Performancehints geben, wenn du die eigentlich Zielvorgabe nicht schaffst.

So Designs entwickeln sich ja auch evolutionär. Nur weil du ne Idee hast, wie man etwas machen könnte, heißt das noch lange nicht, dass sich das auch real implementieren lässt. Je nachdem packste halt nicht die Laufzeiten ein zu halten und musst dann doch wieder Buffer verweden, die deiner Idee dann das Genick brechen können. Bei FullCustom Designs muss man halt echt aufpassen, was man da macht, ansonsten kann man schnell in ner Sackgasse landen, wo 0815 Lösungen von der Stange günstiger und! performanter/effizienter wären...

Die Firmen die Ware von der "Stange" anbieten sind halt auch keine Vollboons... Sie müssen nur ein breiteres Kundenfeld ansprechen, was sich dann eben in weniger kranker Optimierung niederschlägt.

Das waren explizit alles Schnittstellen, die entweder wichtig für die Leistung oder, im Wechselspiel mit Sende- und Empfangsqualität, für den Stromverbrauch. Wenn man irgendwo abseits der eigentlichen CPU und GPU (die man halt bei ARM einkauft respektive bei Nvidia einkaufen soll, wenns nach Nvidia geht) einen Vor- oder Nachteil gegenüber Konkurrenten haben kann, dann da.

Das sind aber alles standardisierte Sachen, wo Patente drauf liegen. Eigenentwicklungen sind da immer zwiespältig, zumal der MArkt mit den IP-Angeboten, die es gibt ganz zufrieden zu schein seint. Die Firmen die sowas anbieten machen das ja auch oft schon ziemlich lange. Die haben also auch Erfahrung damit, was ihre Kunden wollen, und wo typische Probleme auftreten. nVidia ist da völlig unbefleckt.

Weiß nicht, was die Entwicklungsabteilungen machen - aber in Tests ist Sprachqualität weiterhin ein wichtiges Kriterium für Geräte, die irgendwie irgendwo doch noch eine Telefonfunktion versteckt haben.

Das hängt dann aber auch immer noch mit den Mikros/Lautsprechern UND der Software zusammen. Insbesondere Software ist hier sehr wichtig, soweit ich den Bereich der Audioqualität kenne. Das Problem hier ist wohl auch weniger die technische MAchbarkeit, sondern die reine "Pfenningfuchsere" halt doch noch 0,1Cent pro Gerät zu sparen...

Auf die Gefahr hin, mich zu wiederholen:
Jedes einzelne Spiel der letzten 8 Jahre, dass PhysX als Physikengine nutzt.

Wo kann ich denn bitte bei einem NICHT GPU-PhysX Game die GPU überhaupt nutzen, dass das Game beschleunigt wird? Ist das überhaupt möglich? Habe ich nichts von gehört. Und selbst dann bleibt die Frage bestehen, wann man darauf überhaupt einen Nutzen zieht, da man die DAten ja hin und her kopieren muss. Seit nVidia CPU-PhysX nicht mehr so krass künstlich beschneidet wie am Anfang wuppt das auch ganz gut.

Ansonsten gehst du hier wieder nicht auf ein Problem ein:
nVidia GPU-IP = nix x86.....

Und für was ist die ganze Software entwickelt und compiliert? Also wohl "jedes einzelne Spiel der letzten 8 Jahre, das PhysX als Physikengine nutzt"??? Gibt es überhaupt PhysX für PowerPC, ARM und MIPS? Also abseits von den eventuellen Konsolenversionen, die aber wieder zu speziell sind, als das man die für Custom-Chips abseits der Consolen verwenden kann.

Woher soll denn die Software kommen? Die passt sich ja nicht von allein an....

Und selbst wenn, würde man wieder nur für einen Underdog (nVidia im SFF/Mobile Markt) etwas Anpassen. Das werden wohl die wenigsten Entwickler machen. Wenn wird man eher schauen, das man OpenCL/Havok what ever nutzt, was auf ALLEN Geräten läuft, also auch auf denen von nVidia, wenn Sie denn mal in die puschen kommen...

Es werden zunehmend mehr portiert oder (wenn das eben zu aufwendig oder aus Leistungsgründen nicht möglich ist...) als Ableger/Klon umgesetzt.

Hast du Beispiele dafür?

 

[ruyven_macaran]

Wo kann ich denn bitte bei einem NICHT GPU-PhysX Game die GPU überhaupt nutzen, dass das Game beschleunigt wird? Ist das überhaupt möglich? Habe ich nichts von gehört.

PhysX Befehle werden vom PhysX Client verarbeitet - fertig. Auf PCs kannst du im Treiber einstellen, ob der CPU oder GPU nutzt oder sich das passende aussucht. Die ganze API wurde halt mal konzipiert, um ausschließlich auf einer separarten Beschleunigerkarte zu laufen und afaik wurde das nie eingeschränkt. Ein "GPU-PhysX" gibt es EBEN NICHT. Es gibt nur ein paar Spiele, die die Aktivierung besonders aufwendiger Effekte verhindern, wenn keine GPU-Beschleunigung gemeldet wird. Mit Tricks kann man die Sperren aber i.d.R. trotzdem überwinden und es läuft ohne Probleme auf der CPU und ohne dass sich je ein Entwickler je darüber Gedanken machen musste (siehe z.B. der PCGH Test des x87-Mods. Da musste man einfach nur die Client-Einstellungen nach laden des Spiels ändern). Umgekehrt geht das genauso.

Und selbst dann bleibt die Frage bestehen, wann man darauf überhaupt einen Nutzen zieht, da man die DAten ja hin und her kopieren muss. Seit nVidia CPU-PhysX nicht mehr so krass künstlich beschneidet wie am Anfang wuppt das auch ganz gut.

Aber nicht auf nem kleinen Tablet-ARM

Ansonsten gehst du hier wieder nicht auf ein Problem ein:
nVidia GPU-IP = nix x86.....

Und für was ist die ganze Software entwickelt und compiliert? Also wohl "jedes einzelne Spiel der letzten 8 Jahre, das PhysX als Physikengine nutzt"??? Gibt es überhaupt PhysX für PowerPC, ARM und MIPS? Also abseits von den eventuellen Konsolenversionen, die aber wieder zu speziell sind, als das man die für Custom-Chips abseits der Consolen verwenden kann.

Für ARM gibt es noch keinen Client (gibt ja eben bislang auch noch keine ARM-CPUs, denen man solche Belastungen zumuten möchte), bei PowerPC sehe ich keine größeren Probleme. Die "speziellen" Konsolenversionen laufen schließlich auf CPUs mit stink normalem PowerPC-Befehlssatz (und im Falle der x360 und Wii auch normaler Architektur). Da ist die Anpassung an andere Betriebssysteme sicherlich ein wesentlich größerer Aufwand, als für die darunter liegende Hardware. Größer, aber nicht groß, denn Linux und Unix in Form von MacOS werden bereits unterstützt.
MIPS könnte ein Problem werden (IA64 und Sparc auch), aber wer nutzt die (oder auch PowerPC) in Endusergeräten?

Hast du Beispiele dafür?

Explizit auf Basis von PhysX-Spielen wäre ein aufwendige Suche, da die Physikengines oftmals schlicht nicht erwähnt werden (z.B. nutzen sehr viele UE3 Spiele PhysX, weils zum Entwicklerkit gehört, aber dranstehen tut es selten. Bei Crossplatformtiteln ist es ebenfalls sehr beliebt, weil man eben 0 Portierungsaufwand mit dem Physikteil hat)
Ableger und Coverversionen findest du bei diversen AAA Releases der letzten Jahre, z.B. mehreren Need for Speeds, Siedler, iirc auch Assassins Creed, iirc mehrere Prince of Persia, Civilization V... . Das Interesse an einer Portierung von PC-Titeln ist definitiv da.
Die jüngste namenhafte Direktportierung, die sich von der PC Version nur in Plattform und Steuerung unterscheidet, dürfte GTA Vice City sein. Das zeigt auch den ungefähren Stand der Dinge: Es liegen nur noch wenige Jahre zwischen der Fähigkeit von Tablets und den Anforderungen der ersten PhysX-Titel. Eine GPU-PhysX-Unterstützung würde sicherlich bequem ein weiteres Jahr wegknabbern.

 

[Skysnake]

PhysX Befehle werden vom PhysX Client verarbeitet - fertig. Auf PCs kannst du im Treiber einstellen, ob der CPU oder GPU nutzt oder sich das passende aussucht. Die ganze API wurde halt mal konzipiert, um ausschließlich auf einer separarten Beschleunigerkarte zu laufen und afaik wurde das nie eingeschränkt. Ein "GPU-PhysX" gibt es EBEN NICHT. Es gibt nur ein paar Spiele, die die Aktivierung besonders aufwendiger Effekte verhindern, wenn keine GPU-Beschleunigung gemeldet wird. Mit Tricks kann man die Sperren aber i.d.R. trotzdem überwinden und es läuft ohne Probleme auf der CPU und ohne dass sich je ein Entwickler je darüber Gedanken machen musste (siehe z.B. der PCGH Test des x87-Mods. Da musste man einfach nur die Client-Einstellungen nach laden des Spiels ändern). Umgekehrt geht das genauso.

Bist du dir sicher, dass das nicht nur bei den frühen PhysX Versionen ging? Meines wissens nach kann man die Ageia Karten ja nicht mehr nutzen. http://extreme.pcgameshardware.de/grafikkarten/271575-asus-physx-p1-ageia-physx.html

Ich hab jetzt auf die Schnelle nichts besseres gefunden, aber MEIN Stand war/ist eben, dass das, was du sagst durchaus mal so war, aber eben schon länger nicht mehr, nachdem nVidia Ageia aufgekauft hat. Vor allem seit dem man Multi-Core CPUs unterstützt-

Aber nicht auf nem kleinen Tablet-ARM

Ähm... doch

Es sei denn du verpasst CPU und GPU keinen gemeinsamen Adressraum....

Und das hat nVidia noch nicht implementiert, und das kannst du faktisch auch nicht, wenn du geschlossene iGPU-IP-Blocks verkaufen willst. Entweder muss der IP-Block relativ offen sein, oder aber du musst nen kompletten SOC designen durch nVidia...

Deswegen kritisier ich nVidia ja auch.... Den gemeinsamen Adressraum müssen Sie bringen. Am EINFACHSTEN! wäre es gewesen, wenn Sie einfach sich HSA angeschlossen hätten, aber NEIN, Sie müssen wieder ne Extrawurst machen...

Für ARM gibt es noch keinen Client (gibt ja eben bislang auch noch keine ARM-CPUs, denen man solche Belastungen zumuten möchte), bei PowerPC sehe ich keine größeren Probleme. Die "speziellen" Konsolenversionen laufen schließlich auf CPUs mit stink normalem PowerPC-Befehlssatz (und im Falle der x360 und Wii auch normaler Architektur). Da ist die Anpassung an andere Betriebssysteme sicherlich ein wesentlich größerer Aufwand, als für die darunter liegende Hardware. Größer, aber nicht groß, denn Linux und Unix in Form von MacOS werden bereits unterstützt.
MIPS könnte ein Problem werden (IA64 und Sparc auch), aber wer nutzt die (oder auch PowerPC) in Endusergeräten?

Kommt darauf an, wie PhysX implementiert ist. Wenn du x86 spezifische Befehle verwendest, dann kann das ziemlich anspruchsvoll unf aufwändig sein.

Bzgl PowerPC usw:
Mit was willst du denn einen nVidia GPU-Block kombinieren? Mit ARM haste das Problem, dass du einen gemeinsamen Adressraum implementieren musst, da HSA VArianten absehbar sind, und du willst ja auch genug PErformance haben, sonst macht deine CUDA-Fokusierung als "Vorteil" keinen Sinn.

Explizit auf Basis von PhysX-Spielen wäre ein aufwendige Suche, da die Physikengines oftmals schlicht nicht erwähnt werden (z.B. nutzen sehr viele UE3 Spiele PhysX, weils zum Entwicklerkit gehört, aber dranstehen tut es selten. Bei Crossplatformtiteln ist es ebenfalls sehr beliebt, weil man eben 0 Portierungsaufwand mit dem Physikteil hat)
Ableger und Coverversionen findest du bei diversen AAA Releases der letzten Jahre, z.B. mehreren Need for Speeds, Siedler, iirc auch Assassins Creed, iirc mehrere Prince of Persia, Civilization V... . Das Interesse an einer Portierung von PC-Titeln ist definitiv da.
Die jüngste namenhafte Direktportierung, die sich von der PC Version nur in Plattform und Steuerung unterscheidet, dürfte GTA Vice City sein. Das zeigt auch den ungefähren Stand der Dinge: Es liegen nur noch wenige Jahre zwischen der Fähigkeit von Tablets und den Anforderungen der ersten PhysX-Titel. Eine GPU-PhysX-Unterstützung würde sicherlich bequem ein weiteres Jahr wegknabbern.

Das sind aber eben alles Spiele für Consolen oder PC. Das bekommst du nicht "mal eben so" portiert.

Selbst WENN! nVidia ne 100% kompatible PhysX Implementierung für die Chips herausbringen würde, müsstest du eben noch den gesamten NICHT PhysX Part portieren, und das wird einfach keine Sau machen, zumindest nicht so, dass du ne CUDA fähige iGPU zwingend brauchst. Dafür ist die MArktdurchdringung von nVidia in dem Bereich einfach viel viel viel zu gering.

Selbst wenn Sie jetzt mehrere Abnehmer bekommen. Wenn Samsung oder Apple nicht mitziehen, kannste das eigentlich schon vergessen...

Dazu kommt eben noch, das MEINES wissens nach eben ne CUDA GPU bei "normalem" PhysX Implementierungen ohne die GPU-PhysX Nutzung eben gar nicht mehr helfen kann, bzw es performancetechnisch absolut keinen Sinn macht.

 

[ruyven_macaran]

Bist du dir sicher, dass das nicht nur bei den frühen PhysX Versionen ging? Meines wissens nach kann man die Ageia Karten ja nicht mehr nutzen. http://extreme.pcgameshardware.de/grafikkarten/271575-asus-physx-p1-ageia-physx.html

Ich hab jetzt auf die Schnelle nichts besseres gefunden, aber MEIN Stand war/ist eben, dass das, was du sagst durchaus mal so war, aber eben schon länger nicht mehr, nachdem nVidia Ageia aufgekauft hat. Vor allem seit dem man Multi-Core CPUs unterstützt-

101% sicher bin ich mir nicht, aber mein letzter Stand der Dinge ist, dass es den PPUs "nur" an Treiber/Softwareunterstützung fehlt. Das heißt du kriegst die Karte als solche nicht zum laufen (bzw. vor ein paar Jahren war es mit Tricks noch möglich - keine Ahnung, was draus geworden ist), aber wenn du einen aktuellen Client für die Karte hättest, könnte sie alle PhysX-Berechnungen übernehmen. (würde zwar mangels Leistung dauern, aber Performance von 8 Jahre alter Hardware ist eben n bissl retro )

Ähm... doch

? Ich gebe ja zu, dass ich bekennender Dumbphone-Nutzer bin, aber mir wäre noch kein Android-Titel mit aufwendigen Partikeleffekten auf PC-Niveau oder auch nur einer Gameplay-Physik auf dem Level eines durchschnittlichen Havok-Titels begegnet. Bist du dir sicher, dass die Rechenpower dafür bequem ausreicht

Kommt darauf an, wie PhysX implementiert ist. Wenn du x86 spezifische Befehle verwendest, dann kann das ziemlich anspruchsvoll unf aufwändig sein.

Wie gesagt: Es gibt keine "x86 spezifischen Befehle" in PhysX. Das ne vollständige HAL, genausogut könntest du nach x86 Befehlen in DirectX suchen.
Einzig in den Clients für x86-CPUs wirst du entsprechenden Code finden - aber da es auch Clients für komplett x86-freie Plattformen gibt, ist bereits bekannt, wie man den loswird. Ein iGPU-Client würde ohnehin zum Großteil aus einem 1:1 übernehmbaren CUDA/GPU-Teil bestehen. Nur die Interaktion mit dem Betriebssystem muss neu entwickelt werden. Aber das ist vermutlich nicht viel, es ist nicht leistungskritisch (die Schnittstelle Spiel-Client ist PhysX und bleibt eben gleich, die Schnittstelle Client-Recheneinheiten ist z.B. CUDA und bleibt auch gleich, an der eigentlichen Berechnungspipeline ändert sich also nichts) und Nvidia hat eben nachweislich ein Team, dass schon Clients für min. 6 Konsolen- und 3 PC-Betriebssysteme geschrieben hat. Ich denke nicht, dass die bei #10 auf einmal verzweifeln würden. (zumal iOS von OS X und Android von Linux abgeleitet ist, man kennt also schon die Grundzüge des Systems)
Etwas länger dauern würde nur ein reiner ARM-CPU-Client, der aus Kompatibilitätsgründen wünschenswert wäre. Aber aus Leistungsgründen ist der eben sowieso eher was für 2-3 Generationen in der Zukunft, muss also nicht auf Anhieb klappen.

Mit was willst du denn einen nVidia GPU-Block kombinieren? Mit ARM haste das Problem, dass du einen gemeinsamen Adressraum implementieren musst, da HSA VArianten absehbar sind,

PhysX braucht keinen gemeinsamen Addressraum, weil es keine gemischten Berechnungen macht und HSA dauert, insbesondere in diesem Bereich, noch und bis Enduser Software dafür in großer Zahl erscheint, dauert es noch länger. Bis dahin immer noch getrennt zu arbeiten wäre dann sicherlich ein Nachteil. Aber wenn man in den nächsten 1-2 Jahren mit was brauchbarem auf den Markt kommt, hat man die Softwarestandards ggf. definiert, bevor HSA überhaupt Punkten kann. Und nur mit der Vereinheitlichung wird es zumindest im mobilen Markt schwer bis unmöglich, das Steuer noch einmal herumzureißen - Smartphones bieten schlichtweg nicht die Bedienmöglichkeiten und Interfaces, die von einer guten Hochleistungsplattform erwartet werden. Da wird noch auf lange Sicht niemand forderndere Software drauf laufen lassen, als Spiele. Und die lassen sich sehr gut separieren.

Selbst WENN! nVidia ne 100% kompatible PhysX Implementierung für die Chips herausbringen würde, müsstest du eben noch den gesamten NICHT PhysX Part portieren, und das wird einfach keine Sau machen

Den ganzen? Grafik basiert durchgängig auf OpenGL-Ablegern, die man problemlos auf der GPU unterstützen kann. Was bleibt ist im wesentlichen KI und die Steuerung. Aber das sind bei Titeln der zweiten Hälfte des letzten Jahrzehnts (leider, leider, leider) Nebenkriegsschauplätze mit geringeren Performanceanforderungen. Eine volle Kompatibilität in den anderen Bereichen würde den Portierungsaufwand dramatisch verkleinern und es würde eben auch wesentlich früher die benötigte Leistung bereitstellen. ARM kommt halt nicht so wirklich vorran bei der Leistungsexplosion, zumal die CPU ja auch ihre Low-Power-Fähigkeiten behalten muss. (ne aufwendige GPU wird einfach abgeschaltet, wenn sie nicht gebraucht wird - die Technik hat Nvidia im Haus)

zumindest nicht so, dass du ne CUDA fähige iGPU zwingend brauchst. Dafür ist die MArktdurchdringung von nVidia in dem Bereich einfach viel viel viel zu gering.

Und genau das versucht Nvidia gerade zu ändern, in dem sie die Nutzung von Nvidia-GPUs von der eigenen, vom Markt nicht angenommen CPU-Entwicklung entkoppeln.
Obs klappt? Wir werden sehen. Auf alle Fälle hat Nvidia Argumente in der Hand, denen andere nichts weiter als "Gleichstand in anderen Belangen" und ggf. den besseren Lizenznehmer-Support entgegensetzen.

Selbst wenn Sie jetzt mehrere Abnehmer bekommen. Wenn Samsung oder Apple nicht mitziehen, kannste das eigentlich schon vergessen...

Darf ich daran erinnern, dass Apple die gesamte Zeit über, in der man Intel-CPUs mit FSB verbaut hat (was man in einigen Produkten verdammt lange gemacht hat) Nvidia-Chips verwendete? Und nach der Ageia-Übernahme auch sehr früh einen PhysX-CPU-Client als Standardbestandteil im System hatte?
Geendet hat diese Kooperation afaik primär, weil Nvidia keine Chipsätze mehr anbieten konnte - nicht weil man sich gestritten hat. (auch wenn Bumpgate natürlich n heftiger Schlag war.) Volta wurde auch schon mehrfach in Zusammenhang mit Apple gebracht...

Dazu kommt eben noch, das MEINES wissens nach eben ne CUDA GPU bei "normalem" PhysX Implementierungen ohne die GPU-PhysX Nutzung eben gar nicht mehr helfen kann, bzw es performancetechnisch absolut keinen Sinn macht.

Auf herkömmlichen PC-Systemen stimmt das in der Regel. Da liegen in Spielen nunmal jede Menge CPU-Ressourcen frei, während die GPU am Limit arbeitet. Würde man einfachere Effekte auf die GPU auslagern, hätte man einen Leistungsverlust.
Hat man dagegen in Relation zu den Effektanforderungen eine schwache CPU (entweder weil die Effekte extrem sind - ""GPU""-PhysX - oder weil die CPU eben schwach ist), sieht die Sache anders aus.