Eine HD 6550D hat die Hälfte der ALUs einer HD 5770 und deutlich weniger Chiptakt (somit gerade mal ein Drittel der GFLOPS), nur gut ein Drittel der Speicherbandbreite und keinen dedizierten Speicher. Aber hey, "AMD fehlt doch nicht mehr viel zu HD 5700 Niveau" ... selbst die HD 5750 ist meilenweit entfernt.
Von einer HD 5770 hat auch keiner gesprochen. Es war die Rede, dass man zwischen HD 5600 und 5700 landen könnte. Für genauere Prognosen müsste man aber natürlich die Specs kennen. Wenn wir analog zu HD 5870 vs 6970 von 20% mehr Stream Cores ausgehen, bei knapp 10% mehr Takt für die HD 5670, wäre das jedenfalls mehr Potenzial als Redwood. Wobei natürlich noch weitere Faktoren berücksichtigt werden müssen, wie Speicheranbindung, höhere Geometrieleistung bei NI, Treibersupport, etc. Wie gesagt, die HD 5670 halte ich für machbar. Und die HD 5700 ist dann mMn auch nicht mehr so weit entfernt. Und nur um das nochmal klarzustellen, die HD 5700 Serie beginnt mit der HD 5750 und nicht mit der HD 5770.
Aber danke für einen weiteren Beweis, wie du dir immer wieder Aussagen zurechtbiegst, nur um spammen und provozieren zu können.
Du beschwerst dich darüber, dass ich jede Gelegenheit nutzen würde, dir eins reinzuwürgen. Tatsache ist aber vielmehr, dass DU genau das machst. Wie wäre es endlich mal mit Sachlichkeit und sorgfältigerem Lesen von Beiträgen?
Ich warte nach wie vor auf ein paar fundierte Anwendungsbeispiele, die den Otto Normalo im Moment Intel/AMD IGP Käufer einen Vorteil bringen würden, durch die stärkere GPU.
Ich habe dir bereits ein Beispiel genannt. Gibt zB auch im B3D Forum einen
Thread für GPGPU Anwendungen (OpenCL, AMD Stream/APP, Nvidia CUDA). Such dir was aus.
Dazu sprach ich mich als Beispiel an. Du sagtest oben ja, Intel ist in Sachen Leistung, Qualität und Support hinter AMD und NV hinterher hinkt. Ich sehe nur davon nichts, wenn es nicht um Games geht. Und der Otto Normalo wohl auch nicht.
Tja, nur weil du nichts davon siehst, heisst das ja nicht, dass es nicht so ist. Wie gesagt, wenn für die Ansprüche von Otto Normalos eine Intel IGP reicht, dann reicht eine AMD CPU dafür genauso locker. Warum vergleicht man dann überhaupt noch AMD CPUs mit Intel CPUs?
Und zum Thema AMD CPU, wenn ich mir anschaue, wie die CPU Last im Schnitt über den Takt auf der CPU meines Arbeitsnotebooks anliegt, will ich bestimmt nicht auf ne VIA oder ARM CPU gehen...
Deshalb sagte ich auch "eventuell".
Hängt halt immer vom System ab. Es gibt auch schlanke Betriebssysteme, zB diverse Linux Derivate, die nicht viele Ressourcen benötigen. Es muss ja nicht immer Windows sein.
So recht kann ich deiner Argumentationen aber nicht ganz nachvollziehen, du versuchst mir was von Vorteilen bei schnellen GPUs einzureden, bringst im Gegenzug aber Argumente, für langsamere CPUs...
Nein. Ich sage, wenn dir die Performance der iGPU egal ist, dann solltest du dich auch nicht über die Performance von CPUs beschweren. Zumindest nicht was AMD oder Intel betrifft. Leider machst du genau das schon mal ganz gerne, siehe Trinity Thread.
Es gibt auch Intel CPUs unterhalb der Quadcore Riege, sollte dir das entfallen sein?
Natürlich nicht. Aber um die geht es ja auch nicht. Warum verpflanzt man aber eine so schwache IGP auf ein 4C/8T CPU Die? Technologisch sehe ich da keinen Sinn. Man macht das nur aus Eigennutz (mehr Marktanteile, weniger IGPs der Konkurrenz). Am Markt und am Verbraucher geht das irgendwie vorbei. Bei Fusion ist das anders, da es eben als ausgewogenes Design konzipiert ist. Sowohl CPU als auch GPU sind für Mainstream Ansprüche dimensioniert.
Ich denke in dem Punkt daran, das die CPU selbstständig die ihr gegebenen Aufgaben auf die ALUs verteilt, anstatt diese auf ihren eigentlichen Cores zu berechnen. Dabei spielt es dann keine Rolle, wie das ganze Programmiert ist, und es würden quasi alle Anwendungen daraus nutzen ziehen.
Heute musst du noch dediziert der Anwendung mitteilen, nutze für Part xy eben die GPU. Das würde bei native in die CPU integrierten Einheiten wegfallen. Spart somit dem Programmierer Arbeit und bringt dem unwissenden trotzdem die Vorteile. Im Moment hast du so oder so die Schnittstelle zur GPU, und diese muss gefüttert werden, sonst passiert nix. Würde die CPU selbst die Arbeit übernehmen, Berechnungen über die ALUs eines GPU Parts laufen zu lassen, umgeht man dieses gekonnt.
Nein, das spart dem Programmierer keine Arbeit. Es ist doch lediglich eine Frage des verwendeten Werkzeugs. Diesen Aufwand hat man so oder so. Alles weitere, und damit auch die Zuweisung des Codes an bestimmte Hardwareeinheiten, übernehmen Compiler, Runtime, etc.
Später sollen die Shader der GPU aber tatsächlich direkt in die CPU Pipleline wandern. So sehen zumindest die Pläne aus. Ob sich das vernünftig realisieren lässt, wird man sehen. Nur bringt das eben keine direkten Vorteile für den Programmierer, sondern macht die Hardware einfach effizienter (mehr Lokalität, kürzere Wege, geringere Latenzen, etc). Der Programmierer selbst wird auch dann dazu gezwungen sein, auf neue Lösungen zurückzugreifen, um diese Hardware nutzen zu können. Nur könnten das nicht mehr separate Lösungen wie OpenCL & Co sein, sondern direkt in die ISA integrierte Erweiterungen. Genau das hatte zB Intel mit LRBni vor. Ich denke, das ist grundsätzlich der richtige Weg. Das Problem ist nur, dass keiner wirklich mehr Assembler programmieren will, gerade auch im Hinblick auf Portabilität. Es muss also eine entsprechende Unterstützung für Hochsprachen geschaffen werden. Was uns wieder zurück zu OpenCL & Co bringt. Die Frage ist nur, inwiefern sich das in Zukunft alles automatisch vom Compiler parallelisieren lässt, ohne dass man auf nicht eingebaute Sprachfeatures bzw komplizierte Erweiterungen zurückgreifen muss.
PS: weil es auch angesprochen wurde, APU gut und schön, wie will man das in Zukunft mit der Speicherbandbreite machen?
CPUs selbst profitieren eher wenig von Speicherbandbreite, die APU hingegen in Games zum Beispiel doch recht stark (vergleichsweise), siehe Llano zwischen DDR3-1333 vs. DDR3-1866 oder mehr.
Noch deutlich schnellere GPUs würden das noch weiter vorrantreiben. Ich sehe da im Moment bald Ende im Gelände. Weil schnellere Speicher gibts auf absehbare Zeit doch nicht.
Mehr Speicherkanäle ist sicherlich eine Option. Letztendlich ist das eine Kostenfrage. Erst kürzlich wurden aber Infos zu einer anderen Option bekannt,
Memory Stacking. Damit könnte man den VRAM direkt auf den Prozessor verfrachten, was natürlich auch eine wesentlich schnellere Anbindung ermöglicht, also mehr Bandbreite. Und so wie es ausschaut, ist man da wohl schon reicht weit bei der Entwicklung. Gut möglich, dass das schon in ein bis zwei Jahren marktreif ist.
mr.dude sprach die mangelnde Geschwindigkeit, den mangelnden Support und die mangelnde Qualität aktueller Intel GPU Lösung an
Ich sprach nicht von "mangelnd", sondern davon, dass man der Konkurrenz hinterherhinkt, in praktisch allen Bereichen. Das ist ein objektiver Fakt und wurde hinlänglich beleuchtet. Mangelhaft ist hingegen eine subjektive Bewertung, die von den Ansprüchen jedes einzelnen abhängt. Was für den einen mangelhaft ist, ist für den anderen völlig ausreichend.
Gibts doch schon, Problem ist, Qualitätstechnisch gehts gut bergab...
Das ist dann aber der Implementierung geschuldet. Da die Shader aktueller GPUs mittlerweile ausnahmslos IEEE konform sind, gibt's eigentlich keinen technischen Grund mehr für Qualitätsverluste. Mir ist zumindest keiner bekannt. Was anderes ist das natürlich, wenn man auf dedizierte Hardware für's De-/Enkodieren zurückgreift, wie zB UVD. Dort muss IEEE Konformität nicht garantiert sein.
