Es gab eine optional installierbare Entwickler-/Betaversion. Das ist ein bißchen was anderes, als konsequent auf eine neue Schnittstelle zu setzten und zu versuchen, diese zum
Standard aufzubauen, den Softwareentwickler zuverlässig und stabil auf jedem DAU-Rechner vorfinden. Gerade Mr.-SB-E-kann-kein-PCIe3 sollte den feinen Unterschied zwischen "konnte man nutzen" und "war Bestandteil des offiziellen Featuresets" kennen
Ich seh da noch immer kein "verdammt spät".
- On 28 September 2009, Nvidia released its own OpenCL drivers and SDK implementation.
- On 13 October 2009, AMD released the fourth beta of the ATI Stream SDK 2.0, which provides a complete OpenCL implementation on both R700/R800 GPUs and SSE3 capable CPUs. The SDK is available for both Linux and Windows.
Also nicht mal ein Monat unterschied in der offiziellen frei verfügbaren Implementierung.
Wie gesagt, bei den GPUs war AMD leicht hinter nVidia, bei den CPUs aber Äonen vor Intel. Also knapp nen Jahr.
On 13 September 2010,
Intel released details of their first OpenCL implementation for the Sandy Bridge chip architecture. Sandy Bridge will integrate Intel's newest graphics chip technology directly onto the central processing unit
Wenn man bedenkt, das man eben 2 komplett unterschiedliche Produkte fit für OpenCL machen musste geht das doch durchaus in Ordnung.
Dass die Art der Verteilung über ein optionalen Treiberbestandteil, und am Anfang sogar nur über das SDK erfolgte ist da ein ganz anderes Thema. Da gebe ich dir Recht, da haben die am Anfang EXTREM geschlafen, aber darum gings ja gerade nicht oder?
Wir reden wir von Spielen und von einem Vergleich mit einer (wenn nicht) der weit verbreitesten Physik-Engines. (An der Stelle seien noch mal alle auf den Unterschied zwischen PhysX-Verwendung und dem wesentlich selteneren Einbau spezieller Effekte für Systeme mit leistungsfähiger GPU-PhysX-Beschleunigung hingewiesen)
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
Lies bitte noch einmal durch, was ich geschrieben habe. Stand da irgend ein Satz zum Implementierungsaufwand?
Nein. (wobei ich persönlich den als gering erachte, solange Nvidia fertig gelayoutete Kerne verkauft bekommt.
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.
Und gerade! bei SOCs im SFF Markt, kannst du dir nicht mal die kleinsten Schusseligkeiten erlauben. Du bist da einfach darauf angewiesen effizient zu sein, und wenn du da direkt mal so was großes wie ne iGPU als komplett fixen block hast, dann kannste die Effizienz direkt mal in der Pfeife rauchen...
Schließlich lassen 90% der potentiellen Kunden eh bei TSMC im gleichen Prozess fertigen)
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.
Ich ging auf deine Befürchtung ein, dass niemand mehr eine Nvidia-Grafikkarte kauft, wenn er woanders das Gleiche in besser bekommt. Dieser Fall kann überhaupt nicht eintreten, solange Nvidia keine Lizenzen für komplexe Chips der Leistung einer High-End-GPU vergibt - und das die Pläne soweit gehen, ist bislang nicht bekannt. (ganz abgesehen davon, dass es ziemlich schwer werden wird, in dieser Rubrik an Nvidia vorbeizuziehen. Das wäre in etwas das gleiche Verhältnis, wie es zwischen Intel und AMD Anfang der 90er bestand)
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.
So wie die anderen ...äh...hmm... NULL Entwicklungspartner, die in den letzten fünfeinhalb Jahrzehnten mit Intel Chips entwickelt haben?
Tut mir ja leid, aber abseits von ARM und PowerVR gibt es keine andere Firma, die Grafikeinheiten lizensiert und die spielen beide in einer anderen Klasse. Die einzige Alternative zur Lizensierung einer Nvidia-Grafikeinheit ist eine Custom-APU von AMD. Und nicht jeder will AMD-CPU-Kerne nutzen müssen oder AMD die Entwicklung des gesamten Chips bezahlen, obwohl er für sämtliche nicht-GPU-Teile davon eigenes Know-How im Hause hat. (Ganz abgesehen davon, dass AMD nicht unbedingt die personellen Reserven hat, um eine nenneswerte Zahl von Anfragen zu bedienen)
[/quote]
Das ist aber eben der springende Punkt. Wenn sich nVidia auf da versteift was du hier skizierst, dann werden Sie mit Glück einen Kunden bekommen, der dann am Ende das Handtuch wirft, weil kein konkurrenzfähiger funktionierender Chip bei raus kommt...
Wie gesagt, den Weg den nVidia hier bestreiten will mit der Lizensierung von IP-Blöcken, und nicht der Öffnung der Chips für Anpassungen wie AMD, ist weit mehr, als ein Design fertig zu machen, und das dann an den Kunden weiter zu geben, der das dann schon irgendwie verwurschtelt. Der Betreuungsaufwand ist immens, und genau da liegt für nVidia eben der Hacken. 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.
Zurück zum Artikel: Nvidia vergibt Kepler- und GPU-IP-Lizenzen an Dritte
! Aber imho ist so eine Lizenzierung der richtige Weg für Nvidia, CUDA ernsthaft durchzusetzen.
