Schau dir doch mal die Geschichte der Hard/-Softwareentwicklung an. Es kam noch nie vor, dass ein Feature von der Software genutzt wurde, bevor es spezifiziert oder die Hardware da war. Ein sehr gutes Beispiel ist wohl die FPU bzw. damals der Mathematische Co-Prozessor. Also warum soll es bei den APUs denn jetzt auf einmal anders ablaufen?
Wie lange gibts GPGPU nun schon?
Ich denke, das dürfte gegen Mitte 2007 mit CUDA seitens NV losgegangen sein... AMD folgte etwas später mit Stream.
Und was ist jetzt mit der Software? Ich sehe neben ein paar wenigen dedizierten Spezialfällen nix. Keine Alltagssoftware nutzt die GPU. Bzw. wenn, dann macht es die Sache nicht dadurch zum "Renner" und es geht genau so auch ohne... (Browser mit GPU Beschleunigung)
Das ist der Punkt... Das es erst eine Hardware geben muss, um überhaupt die Software darauf zu entwickeln sollte logisch sein, wurde auch von mir nirgends angezweifelt. Nur es gibt eben die Hardware seit Generationen schon... Nur wird sie überwiegend nicht ausgenutzt (bis auf den CPU Teil)...
Der Unterschied zwischen unseren Meinungen scheint einzig daran zu hängen, das ich eben aufgrund der bisherigen Software auf Hardware Anpassungen und dem Ansprechverhalten stark bezweifle, das die ganze Sache für AMD aufgeht. Mit dem Bulldozer ist man auf die Nase gefallen und das Ding ist viel zu langsam im Schnitt gegen die Konkurenz -> so das man das Ding mit hohen Taktraten, hohen Spannungen und vor allem viel zu niedrigem Preis anbieten muss.
Das APU Konzept selbst ist nicht verkehrt. Nur als Zugpferd (da will doch AMD aktuell hin mit APUs only für Sockel FMx in Zukunft) sehe ich die notwendig zu meisternden Hürden von externen Firmen als viel zu hoch an, dass da am Ende für AMD das rauskommt, was sie eigentlich bräuchten -> nämlich endlich mal wieder ein Produkt, was am Markt richtig gut platziert ist und wo man auch mit den Preisen mal nicht im Keller agieren muss.
Es ist jedem Bewusst, das es entsprechende Software braucht, du reitest nur andauern darauf herum. Im Prinzip verlangst du etwas von den APUs, dass es vorher noch nie gegeben hat, die Nutzung neuer Technik mit altem, schon compiliertem Code.
Genau hier zum Beispiel machst du mich dafür verantwortlich... Ich reite nicht auf der Software rum, ich spreche den Umstand an, weil der immer wieder verdrängt wird.
Ein Ansprechen des Umstandes wäre absolut nicht notwendig, wenn es allseits bekannt wäre... Ist es aber scheinbar nicht. Man schaue sich die Kommentare hier und in anderen APU Threads an, speziell eben zum Thema Fusion und Co. -> da denken sich scheinbar einige, das die Hardware auf einmal rasend schnell wird ohne irgendwelches zutun.
Beispiel gefällig:
http://www.hardwareluxx.de/communit...g-sample-aufgetaucht-987618.html#post21380793
Aus dem Zitat ist zu entnehmen, das die APU nun Berechnungen auf dem GPU Part ausführen kann... Wird dediziert erwähnt und hervorgehoben? Warum? Ja scheinbar legt man da Wert drauf... Und ich sage daraufhin -> ja schön und gut, aber du brauchst du die Software, die es sogut wie gar nicht gibt. Und wie die Vergangenheit zeigt, die sich bestenfalls mäßig schleppend an soetwas anpasst. Siehe Llano Vergleich. CPU Seitig noch langsamer als die aktuellen APUs, und die GPU bekommt auch nach 2,5 Jahren fast keine Aufgaben zu tun.
Ich denke schon, dass es wichtig ist, was du erwartest, sonst würdest du nicht immer auf der fehlenden Software rum reiten
Nochmal, ich reite nicht drauf rum...
Ein Ansprechen des Umstandes, der von anderen vergessen, verdrängt oder einfach durch unwissenheit nicht beachtet wurde ist kein "rum reiten".
Du vergleichst Äpfel mit Birnen. Eine Sprungvorhersage muss nur nach ein paar speziellen Befehlen filtern. Ob ein Codeabschnitt aber auf der GPU beschleunigt werden kann oder nicht, hängt nicht von einzelnen Befehlen, sondern von seinem Aufbau ab.
Es gibt immer Mittel und Wege sein Ziel zu erreichen...
Auch ist es nicht meine Aufgabe, die APUs zu entwerfen oder den Jungs bei AMD irgendwelche Tips zu geben... Zumal ich mir das wohl nichtmal selbst anmaßen würde, zu tun.
Die wissen schon was sie machen.
Heist also, wie sie diesen Umstand entgegenwirken (oder ob überhaupt) kann bestenfalls spekuliert werden.
Und wenn es eben in Hardware nicht geht, muss es halt in Software gelöst werden. Wie Mick sagte... Oder man fährt bei der Entwicklung gleich mehrgleisig und entwickelt gewisse Funktionen usw. speziell angepasst für die Hardware X oder Y
Oder lässt gar dem User am Ende die Wahl usw. usf.
Ich würde sagen die GPUs sind zZ. noch zu langsam für einzelne FPU Berechnungen (geringer Takt) und zu simpel. Da müsste sich erst was tun bis sie die FPU ersetzten könnten. Ein Aufbohren würde aber so viel Fläche kosten, dass die schiere Masse verloren gehen würde. FPU und GPU rechnen zwar beide mit Gleitkomma zahlen, doch haben sie beide ihre Stärken und Schwächen. Wir werden also noch eine ganze Weile mit CPU, FPU und GPU leben müssen.
deswegen schrieb ich von Zukunftsmusik...
Wo mach ich dich denn dafür verantwortlich?
Nur mal so, in heutigen Prozessoren ist die FPU immer noch eine eigenständige Einheit, die neben den Integerkernen verbaut wird
Man hat sie zwar immer weiter Integriert, mit einem gemeinsamen Decoder und eigenen Befehlssätzen, es ist aber immer noch eine eigenständige Einheit.
zum ersten, siehe oben beispielsweise... Jedesmal wenn ich mich hier kritisch über eine Sache äußere, kommen scheinbar immer die selben Leute und meinen da irgendwas dran aussetzen zu müssen.
Es macht den Eindruck, als wäre ich dran schuld, weil ich den Umstand anspreche...
Sollte es so nicht gemeint gewesen sein, ist auch OK
Zum anderen, ja, aber was spielt das zur Sache?
Ich spreche mit meiner Software üblicherweise Programmiert in irgend ner Hochsprache nicht direkt die FPU an.
Das muss ich aber stand heute mit der GPU machen. -> und das ändert sich mit Kaveri genau Null, auch nicht durch HSA und hUMA. Oder habe ich hier nen Denkfehler?
