Ist 3dNow eigentlich tot?

[Gast]

Im Grunde ja oder? Warum ist der "Kram" immernoch in den X2 drin? Wäre Transistoren sparen nicht angesagter?

[CokeMan]

Im Grunde ja oder? Warum ist der "Kram" immernoch in den X2 drin? Wäre Transistoren sparen nicht angesagter?

Wie wäre es wenn mann die zweite Dimension abschafft, und du dann all deine 2D Spiele von früher nicht mehr spielen kannst :rolleyes:

[Kurgan]

Wie wäre es wenn mann die zweite Dimension abschafft, und du dann all deine 2D Spiele von früher nicht mehr spielen kannst :rolleyes:
naja, der vergleich hinkt etwas ... und von den paar progs die 3dnow überhaupt unterstützt haben dürften auch nicht mehr gerade massen in anwendung sein.

[blutrausch]

genau das hab ich mich auch letztens gefragt...welche applikationen nutzen 3dnow denn eigentlich noch?!
und wäre es nicht sparsamer gewesen wenn beim K10 die transistoren die dafür fällig waren einzusparen?

amd würde jedes quäntchen an einsparung in verbrauch als auch kosten gerade sehr nutzen denke ich. allerdings muss ich zugeben dass ich mich noch nicht viel zu dem thema belesen habe.

[Ihm]

Ganz einfach: Abwärtskompatibilität.
Bei ca. 150 Mio. Transistoren eines X2 3800+ ist es echt egal, ob man die ca. 1 Mio. Transistoren für 3DNow! Prof. drin lässt oder nicht. Logischerweise lässt man es dann aus Kompatibilitätsgründen drin.

Kurz:
Die Transistorzahl von 3DNow! Prof. ist einfach zu gering, um sich bei der Entwicklung daran aufzuhängen.

[Gast]

Ists nicht so, dass der "Transistorenverbrauch" von 3dNow noch lächerlicher ist, da es im Grunde nur ein wenig Microcode ist, der eh durch die SSE-Einheit geht? Für eine Handvoll Transistoren Kompatibilität opfern wäre absoluter Unsinn...

[blutrausch]

dann nennt aber bitte mal programme die von 3dnow profitieren....
ich kenne nur sse(2/3) optimierte programme.ich weiß dass es ne 3dnow optimierte build version von firefox gibt aber wer sollte die nutzen wo doch sse3 in jedem aktuellen X2 ist?

[Gast]

Ists nicht so, dass der "Transistorenverbrauch" von 3dNow noch lächerlicher ist, da es im Grunde nur ein wenig Microcode ist, der eh durch die SSE-Einheit geht? Für eine Handvoll Transistoren Kompatibilität opfern wäre absoluter Unsinn...

Ebend, man beachte das Alter von 3dnow. Hat jemand lust auf'ne A20 Gate Diskussion? :D

[Marscel]

dann nennt aber bitte mal programme die von 3dnow profitieren....
ich kenne nur sse(2/3) optimierte programme.ich weiß dass es ne 3dnow optimierte build version von firefox gibt aber wer sollte die nutzen wo doch sse3 in jedem aktuellen X2 ist?

Der Lame MP3 Encoder wirft entsprechende Meldung aus. Wie weit da Nutzen ist, weiß ich nicht.

[lilgefo~]

PowerDVD nutzt afaik 3dnow..wobeis da im Prinzip auch egal waere weil eh alles über die GPU geht und wenn nich langt die Leistung immer noch. xD

[Ihm]

Ists nicht so, dass der "Transistorenverbrauch" von 3dNow noch lächerlicher ist, da es im Grunde nur ein wenig Microcode ist, der eh durch die SSE-Einheit geht? Für eine Handvoll Transistoren Kompatibilität opfern wäre absoluter Unsinn...

Stimmt. 3DNow! Professional ist eigentlich ne Mischung aus SSE und Enhanced 3DNow!. Letzteres ähnelt stark MMX. Von daher läuft das Ganze warscheinlich fast oder wirklich komplett über die SSE-Einheiten.
Das eine Abarbeitung der 3DNow! Prof. Befehle in SSE und eine massive Ähnlichkeit vorliegt sieht man auch sehr deutlich an der Transistorzahlzunahme vom Spitfire zum Morgan. Beim Morgan wurde bei der gleichen Fertigungstechnik SSE eingeführt. Die Transistorzahl stieg aber von 25 Mio. auf 25.18 Mio und damit nur um 180.000 Transistoren. Und das obwohl 3DNow! Prof. und SSE neu eingeführt wurde. Das erklärt eigentlich alles. ;)

Da wäre AMD ja schön blöd, wenn sie 3DNow! Prof. nicht einfach drin lassen würden. Und wenns auch nur darum gehen würde, einen technischen Begriff mehr im Portfolio zu haben.

Btw:
In die Geode GX und LX wurde 2002 ein zusätzlicher Befehl eingefügt, der in keinem anderen Prozessor von AMD zu finden ist: pfrsqrtv
PFRSQRT gehört zur Arithmetik. Das "v" am Ende könnte auf eine Funktion für Vektor-Arithmetik hinweisen.

[Spasstiger]

Ich denke auch, dass man 3DNow inzwischen komplett über die SSE-Einheiten lösen kann und somit keine zusätzlichen Ausführungseinheiten braucht. Lediglich der Microcode wird dann etwas größer, aber das sind wirklich Peanuts.

[BlackBirdSR]

Ich denke auch, dass man 3DNow inzwischen komplett über die SSE-Einheiten lösen kann und somit keine zusätzlichen Ausführungseinheiten braucht. Lediglich der Microcode wird dann etwas größer, aber das sind wirklich Peanuts.

Low-Level wird sowieso alles über die FPUs ausgeführt. Es gibt also keinen extra SSE und 3dnow-Einheiten. Daher muss nur noch ein kleiner Teil der CPU in der Lage sein die Befehle zu interpretieren.

Trotzdem ist 3dnow! Geschichte. Ab x64 gibt es keinen direkten Zugriff mehr auf 3DNow! wenn es nach Microsoft/AMD geht.

[SavageX]

Wenn ich mich recht entsinne, so nutzten z.B. die MPEG4 Decoder von ffmpeg (libavcodec) 3DNow! *und* SSE geschickt verschachtelt. Zumindest beim ersten Athlon konnte man damit mehr Einheiten auslasten und bekam etwas mehr Power serviert. Ob beim K8/K9 oder K10 überhaupt noch separate 3DNow! Einheiten vorhanden sind... keine Ahnung.

[SavageX]

Low-Level wird sowieso alles über die FPUs ausgeführt. Es gibt also keinen extra SSE und 3dnow-Einheiten. Daher muss nur noch ein kleiner Teil der CPU in der Lage sein die Befehle zu interpretieren.


Err... jein. MMX (und bei 3Dnow! darauf aufgesetzt) bekam zumindest in der Vergangenheit wohl doch eine eigene Einheit. Vermutlich ist die FPU bei Integer-Berechnungen doch nicht so toll ( ;-) ), auch wenn MMX und die FPU sich die Register geteilt haben (ob das aber nun wirklich die selben physikalischen Register waren, keine Ahnung. Vielleicht beim Pentium MMX, der ja auch lustige Strafrunden beim Wechsel der Modi drehte).

K6-2:
http://en.wikipedia.org/wiki/Image:Amdk62_arch.png


Pentium MMX:
http://www.fh-wedel.de/cis/archiv/seminare/ws97/mp-ws97/imageKGL.JPG

Fragt sich, wie weit man diesen Blockdiagrammen trauen kann.

Edit: Zum eigentlichen Thema: Bis auf Nischenanwendungen halte ich 3DNow! für tot. Da gibt es nichts, was man nicht auch mit SSE2 etc. anstellen könnte.

Eine Nische wäre z.B. der OLPC Laptop ("100$ Laptop"). Der eingebaute Geode LX kann nur MMX (mit den MMX-Erweiterungen, die Teilmenge von SSE1 waren) und das Athlon-3DNow!. Ich erinnere mich da eine Diskussion, ob es Sinn machen würde, z.B. dem Speex-Codec eine 3DNow!-Variante zu verpassen, um auf dieser Kiste noch ein bisschen schneller zu sein.

[Bokill]

AMD hat MMX etwas anders in die Microarchitektur des K6 eingbunden als Intel in seinem Pentium1.

Bei AMD war 3DOW! ein Aufsatz zur MMX-Einheit beim K6.

Im Grundsatz hat AMD dieses 3DNOW! im K7 dann in die Gleitkommaeinheiten integriert. Die erste SSE-Implementierung von AMD setzte auf die vorhandenen 3DNOW!-Schaltungen auf, wobei man vermuten darf, dass per Microcode dann SSE-Befehle auf der 3DNOW!-Einheit umgebogen wurden.

Weil AMD 3DNOW! und SSE(1) so eng miteinander verwoben hat, war es gut, dass AMD 3DNOW! weiter bis heute "mitgeschleppt" hat.

Einige Modemtreiber erwarten MMX-Prozessoren als Minimal-Anforderung und das spätere SSE1 ist doch recht breit verbreitet, so dass ein nachträgliches entfernen von 3DNOW! im Zweifelsfalle eher schädlich ist, als dass damit entscheidend Transistoren eingespart werden.

All dies bedeutet aber dennoch, dass 3DNOW! in der allgemeinen Praxis tot ist.

Wie jemand aber auch richtig bemerkte, im Detail können sich Legacy-Einheiten sich sehr tief irgendwo eingegraben haben. Das Gate A20 ist davon nur ein sehr altes und populäres Beispiel davon. Wenn eines den x86-Instruktionssatz "auszeichnet", dann die "ewige" Kompatibelität.

Bei Microsofts Windows Vista 32/64 Bit wird aber zumindest an sehr vielen Baustellen der alte Legacy-Zopf abgeschnitten. Der klassische x87-Instruktionssatz (Gleitkomma-Instruktionssatz) MMX/3DNOW! und SSE1 gehören zu den ungenutzten/nicht mehr genutzten ergänzenden Instruktionssätzen dazu.

MFG Bobo(2007)

[Benedikt]

Bei Microsofts Windows Vista 32/64 Bit wird aber zumindest an sehr vielen Baustellen der alte Legacy-Zopf abgeschnitten. Der klassische x87-Instruktionssatz (Gleitkomma-Instruktionssatz) MMX/3DNOW! und SSE1 gehören zu den ungenutzten/nicht mehr genutzten ergänzenden Instruktionssätzen dazu.
MFG Bobo(2007)
Was passiert dann eigentlich, wenn eine Anwendung explizit eines dieser x86-Teilfeatures anfordert? Crash? Oder meldet das OS schlicht einen "nicht 3Dnow!-kompatiblen" Prozessor?
Welche Vorteile bringt es, die x87-FPU zu Grabe zu tragen, wenn diese doch offensichtlich bisher immer noch ihre Berechtigung hatte?

[Bokill]

Frage nicht mich, sondern Microsoft.

Ich gebe nur das wieder, was Microsoft verlautbart hatte.

Sehr wahrscheinlich, dass das der WOW64-Layer in 64 Bit Microsoft-Betriebssystemen abfängt, damit alte Spiele noch unter 64-Bit Windows laufen, denn das geht meistens.

MFG Bobo(2007)

[Legolas]

Die entsprechenden Instruktionen sind doch nicht irgendwie deaktiviert. Es werden nur die x87 Register beim Context Switch nicht mehr gesichert. Dies ist jedoch nur bei den 64 Bit versionen von Windows XP/Vista so. Für die 32 Bit Programme, die im WOW Layer ausgeführt werden, müssen die Register aber gesichert werden, sonst würden keine Applikationen laufen, die x87, 3dnow oder MMX Befehle verwenden, da diese 3 Instruktionserweiterungen alle die x87 FPU Register benutzen.

Falls eine Anwendung eine Instruktion benutzt, die der CPU unbekannt ist, dann wirft diese eine Exception, um das der Anwendung zu signalisieren. Normal wird dann durch Windows die Anwendung beendet. Hatte einen derartigen Fehler erst, als ich ein Programm, welches SSE benutzt, auf einem Athlon Thunderbird ohne SSE ausgeführt habe.

[Tigerchen]

dann nennt aber bitte mal programme die von 3dnow profitieren....
ich kenne nur sse(2/3) optimierte programme.ich weiß dass es ne 3dnow optimierte build version von firefox gibt aber wer sollte die nutzen wo doch sse3 in jedem aktuellen X2 ist?

Quake 2 und Half-life 2/ Counterstrike:Source haben 3DNow!-Unterstützung

[Blinx123]

Ganz einfach: Abwärtskompatibilität.
Bei ca. 150 Mio. Transistoren eines X2 3800+ ist es echt egal, ob man die ca. 1 Mio. Transistoren für 3DNow! Prof. drin lässt oder nicht. Logischerweise lässt man es dann aus Kompatibilitätsgründen drin.

Kurz:
Die Transistorzahl von 3DNow! Prof. ist einfach zu gering, um sich bei der Entwicklung daran aufzuhängen.

Ich sag nur eins. Dito.

Ich denke,dass das genau der Punkt ist. Man würde doch nur Kunden abschrecken,wenn dann plötzlich eine Anwendung nicht mehr läuft oder viel langsamer ist. Da ist es nebensächlich,wie alt diese Anwendung ist und wie wenig 3DNow genutzt wird.

[Bokill]

... AMD Family 10h processors are 64-bit processors that are fully backwards compatible with 32-bit code.

In general, 64-bit operating systems support the x87 instructions in 32-bit threads;
however, 64-bit operating systems may not support x87 instructions in 64-bit threads

To facilitate future migration from 32-bit to 64-bit code, it may be necessary to avoid x87 instructions altogether and use only SSE, SSE2, SSE3, and SSE4a instructions when writing new 32-bit code.

Note that x87 and scalar SSE instructions cannot schedule floating-point operations in the new second set of FPU registers. Thus, the x87 instructions cannot take full advantage of the new 128-bit floating-point resources; better performance is achieved using packed SSE instructions. ... AMD macht sich nicht besonders Mühe hier von 3DNOW! zu sprechen.

Auch die SSE1 Unterstützung fällt hier beim K10 recht mau aus. MMX und 3DNOW werden in diesem Zusammenhang erst gar nicht mehr erwähnt.

Im Grundsatz war diese AMD-Politik aber schon ab dem ersten K8 so.

MFG Bobo(2007)

[Legolas]

Der kleinste gemeinsame Nenner bei 64bit-fähigen x86 Prozessoren ist sowieso SSE2. Insofern ist alles, was vorher kam mittel- bist langfristig nur noch Legacy.