Ich glaube dass du versuchst fdsonne zu verstehen zu geben, dass 1d nicht gleich 1D ist und die Software von nVidias 1D(auf die sie ja speziell zugeschnitten ist) erst auch auf AMDs 1D angepasst werden muss.
Das Problem ist, das eine ist Software, das andere ist Hardware. Der Schnittpunkt in der Mitte entscheidet über laufen oder nicht. Aber in keinem Fall die Hardware oder Software allein.
Der Punkt, an dem man eben nicht vermischen sollte ist die Tatsache, das CUDA, Stream, OpenCL sowie auch das DirectCompute Schnittstellen sind. (vereinfacht gesagt)
Welche Hardware drunter tuckert, ist vollkommen egal. NV bietet CUDA als ich glaube ClosedSource Software dediziert nur für NV ab G80 Karten, AMD bietet Stream auch nur für R600 und neuer. Wärend OpenCL Hardwareunabhängig agiert. CUDA sowie Stream könnten technisch absolut schmerzfrei auch auf den Konkurenzkarten laufen, wenn das gewollt wäre. Und das ist der Punkt. CUDA hat einfach nix mit der GPU Architektur bzw. dem Aufbau der ALUs zu tun.
NV handelt es halt in dem Fall sehr clever, denn man implementiert OpenCL via CUDA, was rein logisch schon Leistungsverlust für ein und das selbe Endergebnis beinhaltet. Für sehr komplexe Aufgaben kann das durchaus nicht nur Messbar weniger Leistung für OpenCL sein. Hat man also dediziert die Möglichkeit (Gerade im Wissenschaftlichen Bereich), macht es mehr Sinn auf CUDA zu setzen als auf OpenCL, es sei denn, man will Hardwareunabhängig programmieren.
Ein weiter Faktor ist die Tatsache, das der Programmierer sich nicht hinsetzt und Maschinencode dediziert für Skalar Einheiten (NV) oder VLIW4/5 Einheiten (AMD) schreibt. Sondern er nutzt eine Hochsprache. Für alle Ansätze gibt es C/C++ Aufsätze, was dem Programmierer das Umdenken erleichtert. Wie gut der Compiler hinten arbeitet ist einzig und allein das Bier der Hersteller (nicht des Programmierers!)
Übrigens, zum Thema PhysX... Dort ging es ja dediziert um PhysX selbst. Es haben sich findige Programmierer gefunden, welche die NV PhysX Implementation auf CUDA Basis "gehakt" hatten... Wie ich das lese schien NV anfangs durchaus nicht abgeneigt zu sein, aber hat dann die Sache dennoch beendet.
Mit CUDA Code selbst (um das gings ja ursprünglich hier) hat das aber wenig zu tun, weil nicht ganz klar ist, was die Jungs dort damals überhaupt angestellt hatte. Theoretisch wäre es Möglich mit gewissem Aufwand eine Art Emulator zu basteln, welcher PhysX auf Stream portiert. Effizienztechnisch entscheiden dann aber schon zwei Sachen über den Speed. Und für diese halbherzige Implementierung (dazu noch zu Anfängen von Stream) waren die Ergebnise doch schon ganz ordentlich... HD3850 ca. 2/3 Leistung von 8800GT...
Im Vergleich zum Speed von CPUs (i7 Hexacore + SMT) bei vollem Multicoresupport ist der Speed von NV GPUs dediziert mit ihrer Implementierung äußerst schlecht -> kann jeder selbst Testen mit beispielsweise Fluidmark.
NV macht es sich hier sehr einfach indem man einfach die Threadanzahl für CPU PhysX deutlich einschränkt bis hin zu nur einem einzigen -> Batman zum Beispiel um hier selbst nicht unterzugehen.
Das könnte aber auch daran liegen, das die eigentliche PhysX Entwicklung damals seitens Ageia für ihre dedizierte CPU war und NV hier nur nen CUDA Aufsatz gebastelt hat anstatt das ganze selbst dediziert umzubauen.
. 700Mhz orginal und max oc 930 
.
. Was mich nur sehr sehr sehr stört das der Januar wieder teuer für mich wird 
