3Dnow! ungenutzt?

[LordDeath]

hier ist so ne frage an die, die es wissen ;)
warum wird diese erweiterung nicht mehr genutzt? nur weil es das aktuelle visual studio nicht hat? und wieso nicht? ich habe davon eigentlich seit der SSE einführung beim athlonxp nicht mehr etwas gehört. funktioniert 3Dnow! denn überhaupt bei gleichzeitiger nutztung von SSE? wenn ja, bringt es dann noch was?

[Coda]

Es lohnt sich einfach nicht für 3DNow! zu entwickeln, weil SSE der Standard geworden ist. Außerdem blockiert 3DNow! die FPU/MMX Register. SSE hat 8 neue Register spendiert bekommen.

Man kann theoretisch 3DNow! und SSE gleichzeitig nützen, nur bringt das nichts weil es eh von den gleichen Recheneinheiten verarbeitet wird.

Der einzige Vorteil von 3DNow! gegenüber SSE waren eigentlich die "horizontalen" Befehle. Da wurde bei SSE3 jetzt aber einiges nachgeholt.

[LordDeath]

also waren zuwenig zusatzleistung und zuwenig unterstützung seitens intel der untergang vom 3dnow...

was bringt es amd dann eigentlich noch, diese erweiterung weiter im programm zu haben? das verbraucht ja auch eigene transistoren für logiken. oder wäre das anschließende neudesignen von chipteilen durch die entfernen von 3dnow! die einsparung selbst nicht wert?

[Goldmund]

also waren zuwenig zusatzleistung und zuwenig unterstützung seitens intel der untergang vom 3dnow...

was bringt es amd dann eigentlich noch, diese erweiterung weiter im programm zu haben? das verbraucht ja auch eigene transistoren für logiken. oder wäre das anschließende neudesignen von chipteilen durch die entfernen von 3dnow! die einsparung selbst nicht wert?
Keine Unterstützung von Intel wäre wohl treffender :wink:
Die mangelte Zusatzleistung ist imho auch kein Problem. Nur kann AMD es nicht so promoten und Intel war sich seinerzeit noch "Zu fein" um es zu übernehmen.
Und da Amd mittlerweile auch SSE1-3 kann , besteht für die Entwickler keinen 3dnow! zu supporten. SSE ist meines ungefähr gleich "gut" wie 3dnow! .
Warum sollten sie es nicht mehr supporten ? die paar 100k? Transis sollten wohl kein Prob darstellen. Und außerdem gibt es ja noch ältere Progs mit 3dnow! Unterstützung wie Quake2
Weitere Fragen diebezüglich am besten im P3D Forum stellen

[Coda]

was bringt es amd dann eigentlich noch, diese erweiterung weiter im programm zu haben? das verbraucht ja auch eigene transistoren für logiken. oder wäre das anschließende neudesignen von chipteilen durch die entfernen von 3dnow! die einsparung selbst nicht wert?Die Recheneinheiten sind wie gesagt die selben wie für die FPU und 3DNow!.

Man will wohl nur Kompatibilität beibehalten. Ich kann mir durchaus vorstellen dass es Software gibt die nur auf "AuthenticAMD" und Model>=6 checken mittels CPUID und dann 3DNow! annehmen.

[micki]

naja, selbst wenn amd viel werbung dafür machen würde, aus entwicklersicht ist es viel zu unflexibel. bei SSE kann man sich ne lib machen für z.b. matrizen und ohne bedenken damit arbeiten.
bei 3dnow muss man entweder bei jedem funktionsaufruf der lib die fpu hin und her switchen (was ziemlich zeit kostet in relation zu vielleicht den 2 befehlen die man ausführen möchte) oder man setzt spezielle codeblöcke ein die 3dnow unterstützen und die so gekapselt sind dass nichts zwischendurch aufgerufen wird dass die fpu braucht.

mir persönlich gefällt 3dnow viel besser als sse, zum einen weil es die horizontalen befehle gibt (wie coder schon sagte) und zum anderen weil man pro takt eine instruction abarbeitet im gegensatz zu einer instruction alle zwei takte bei sse. im endeffekt braucht man doppeltsoviele 3dnow instructions um die gleichen operationen durchzuführen wie bei sse, man ist aber nicht gezwungen wirklich diese operationen durchzuführen, wenn man sich z.B. ne simple 2D engine schreiben würde, muss man nur mit 2d-vectoren arbeiten.

weshalb ich trotzdem SSE benutze liegt einfach daran dass es probleme gibt mit dem fpu/3dnow modus. die kapselung davon ist echt aufwendig und es passieren überall mal fehler weil man vergessen hat zu kapseln (wenn man 3dnow als fpu ersatz anwenden möchte). wenn man hingegen nur spezielle bereiche für 3dnow optimieren wollte, sonst aber generell SSE nutzt, dann ist es irgendwie witzlos.

SSE an sich ist für spiele bei weiten nicht so nützlich wie es sein könnte. Eigentlich ist SSE eher für streaming und wissenschaftliche dinge gedacht. dass SSE bei spiele etwas bringt ist nur ein kleiner nebeneffekt den dass intel marketing gut zu nutzen weis. Wenn es wirklich so für spiele tauglich gewesen wäre, hätte es von anfang an ein dotproduct als instruction oder mindestens gute horizontalbefehle (und nicht diese halbherzigen wie bei SSE3).

afaik war AMD aber gezwungen die fpu register zu nutzen, weil microsoft nicht extra SSE UND 3DNow -register unterstützen wolte.

MfG
micki

[Narrenkönig]

Wie unterstützt die Source Engine eigentlich 3Dnow?
Erkennen tut sie es ja, aber wird es auch genutzt?

[LordDeath]

danke für eure erläuterungen :D

[Goldmund]

afaik war AMD aber gezwungen die fpu register zu nutzen, weil microsoft nicht extra SSE UND 3DNow -register unterstützen wolte.

MfG
micki
Wie soll ich das verstehen ?
3dnow! war ~ 1 Jahr vor SSE. Wie soll MS dann AMD sagen dass sie nur einen Registersatz unterstützen werden ?

[micki]

Wie soll ich das verstehen ?
3dnow! war ~ 1 Jahr vor SSE. Wie soll MS dann AMD sagen dass sie nur einen Registersatz unterstützen werden ?
bei der entwicklung von hardware weiß man schon viel länger was kommen wird als nur ein jahr ;).
3dnow! war zudem kein alleiniges kind von AMD, sondern noch von cyrix und ..em.. *vergessen*. es war also schon lange vorher bekannt
wobei ich natürlich keine absoluten informationen habe, es sind nur gerüchte dass AMD wegen M$ keine neuen register eingeführt hat.

doch das ist das, was trotz der besseren eignung von 3dnow! , dem selbigen das genick bricht. wenigsten bei der 64bit version hätten sie ein extra registersatzt dafür machen können, wo sie es schon für alle register verdoppelt haben.


MfG
micki


btw. hab ne roadmap mal gefunden, http://www.geocities.com/soldaini/roadmap.html wenn die stimmt, dann kam SSE, genau wie 3dnow bei AMD und CYRIX anfang 1999....

[Coda]

doch das ist das, was trotz der besseren eignung von 3dnow! , dem selbigen das genick bricht. wenigsten bei der 64bit version hätten sie ein extra registersatzt dafür machen können, wo sie es schon für alle register verdoppelt haben.Wieso denn? SSE3 ist ein vollständiger Ersatz für 3DNow! und die FPU, die FPU Register können bei 64bit Programmen in Windows gar nicht mehr benützt werden.

[micki]

Wieso denn? SSE3 ist ein vollständiger Ersatz für 3DNow! und die FPU, die FPU Register können bei 64bit Programmen in Windows gar nicht mehr benützt werden.
vollständig?
wenn du dich mit 3dNow auskennst, weißt du dass es dort einige fixe befehle gibt, die SSE nicht hat.

MFG
micki

[Coda]

Wirklich? Was fehlt denn noch bei SSE3?

[micki]

Wirklich? Was fehlt denn noch bei SSE3?
z.B. approximierte wurzel, was ja für spiele durchaus von nutzen ist. zudem setzt windows bei 64bit nicht SSE3 sondern SSE(1) voraus, oder? und da gibt es noch einiges an defiziten zu 3DNow.

für Spiele wäre 3DNow! um einiges geeigneter.

MfG
micki

[zeckensack]

z.B. approximierte wurzel, was ja für spiele durchaus von nutzen ist. zudem setzt windows bei 64bit nicht SSE3 sondern SSE(1) voraus, oder?SSE2.
und da gibt es noch einiges an defiziten zu 3DNow.Ack.

[Coda]

z.B. approximierte wurzel, was ja für spiele durchaus von nutzen ist.Kann man sicher in ähnlichen vielen Takten "zu Fuß" machen.

[zeckensack]

Kann man sicher in ähnlichen vielen Takten "zu Fuß" machen.>=15 signifikante Bits mit einer Instruktion, mit drei Takten Latenz?

[Coda]

Hä? Ich hab mich ja grad schon gewundert dass es keine Squareroot Instruction in SSE geben soll.

Es gibt sie: SQRTPS und RSQRTPS

Was imho bei 3DNow! und SSE fehlt ist eine gescheite (dynamische) Swizzle Instruction. Das dürfte doch nicht so schwer zu implementieren sein.

[Stebs]

Kennt jemand die kleine Demo Metaballs von Humus: http://www.humus.ca/index.php?page=3D&ID=57
Dort kann man unter F1 zwichen FPU, SSE und 3DNow umschalten.
Auf meinem AthlonXP 3200+ ist die Framerate FPU < SSE < 3DNow, wobei mit SSE die "Metaballs" nicht angezeigt werden (obwohl der Athlon XP doch SSE kennt). Wie siehts bei euch aus? Hat dies einen praktischen Wert?

[maximAL]

bei mir läuft die demo mit FPU mit 19-20FPS, mit 3Dnow mit ~23.
SSE kann mein tbird eh nicht :wink:

[Darkman.X]

Bei mir mit A64

FPU < SSE = 3DNow

[z3ck3]

XP-M 2500+ @1,6Ghz (FSB@200), NV 5900XT

FPU 51, 100%
SSE 64, FPU + 25,5%,
3dNOW 69, FPU + 35,2%, SSE + 7,8%

3DNOW scheint also beim XP fast 8% mehr Listung zubringen als SSE.

[Bokill]

Ist der Geode eigentlich schon betrachtet worden?

Immerhin ist in der neusten Variante dem Geode LX immer noch 3DNOW! drin, aber ausdrücklich kein SSE. Für Embedded und System on Chip (SoC) könnte dann 3DNOW! länger leben wie von manch einem erwartet. Auf der Ebene von 32 Bit sind solche Designs noch gut genug.

MFG Bobo(2005)

[Coda]

In embedded Systemen wird doch kaum FPU Leistung gebraucht

[Stebs]

Um auch mal konkrete Zahlen zu liefern (mit Athlon XP 2500+ @ 3200+, 6600GT):
FPU: 62 fps
SSE: 67 fps
3DNow: 79 fps

bei SSE ist wie gesagt die "Blase" nicht zu sehen.

[z3ck3]

komisch das bei manchen die Blase bei SSE net zu sehen ist. Bei mir ist sie da. (XP-M siehe oben)

[Stebs]

Das kam mir langsam auch komisch vor, hab das Demo jetzt mal einfach neu runtergeladen und siehe da, nun gehts auch korrekt mit SSE :)
Neues Ergebnis:
FPU: 61
SSE: 73
3Dnow: 78

Ergebnisse sehen jetzt auch definitiv vertrauenderweckender aus.
3Dnow hat also Prinzipiell doch Vorteile gegenüber SSE (auf einem Athlon XP zumindest).
Inwieweit sich das auch in realen Spielen (mit 3Dnow) bestätigen lässt, ist natürlich eine andere Frage...

[Bokill]

In embedded Systemen wird doch kaum FPU Leistung gebraucht ... jupp ... darum hat der Geode (http://www.orthy.de/modules.php?name=Encyclopedia&op=content&tid=242) GX/LX ja auch eine deutlich eingesparte FPU, aber mit 3DNOW! ... und kein SSE/SSE2.

MFG Bobo(2005)