amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Amiga, AmigaOS 4 > Lame 3.93.1 und 68060 vs. PPC [ - Suche - Neue Beiträge - Registrieren - Login - ]

1 2 -3- [ - Beitrag schreiben - ]

13.04.2008, 22:07 Uhr

Rindenmolch
Posts: 176
Nutzer 		@MaikG
Ich sitze hier gerade am AMIGA und habe alle libs nochmal neu geladen und kopiert. Ich habe genau die Libs, die du benutzt. Auch die Lameversion ist haargenau die selbe und es brauchst plötzlich 1Minute 50 Sekunden für die 256kbit testcase.wav mit den genau den Befehlszeilen die du hier in den Thread geschrieben hast und 1:56 für die 128er Variante. Ich werd echt bekloppt. Miami ist zwar im Hintergrund gelaufen aber das kann die Performance nicht soweit runterziehen. Den Cyberpatcher habe ich auch schon mehrfach angeklickt. Ich hab echt keine Ahnung.

[ - Antworten - Zitieren - Direktlink - ]
13.04.2008, 23:35 Uhr

MaikG
Posts: 5172
Nutzer 		>Ich sitze hier gerade am AMIGA und habe alle libs nochmal neu
>geladen und kopiert. Ich habe genau die Libs, die du benutzt.
>Auch die Lameversion ist haargenau die selbe und es brauchst
>plötzlich 1Minute 50 Sekunden für die 256kbit testcase.wav mit
>den genau den Befehlszeilen die du hier in den Thread geschrieben
>hast und 1:56 für die 128er Variante.


Hast du die:

sndfile.library 163368 ----rwed 18-Okt-00 20:27:34


bei den neueren Versionen läd Lame mit dieser library.


>Den Cyberpatcher habe ich auch schon mehrfach angeklickt.

Bei mir ist der aus. Beim 2.x Doppelklick deaktiviert der sich.
Der ist hauptsächlich für sachen die die FPU(<=040) benutzen,
Imagine kann der gut beschleunigen.
Akuelle Programme, speziell die für 68060 optimiert sind
benutzen logischer weise keine Befehle die ein 060 nicht unterstützt.

Da du AGA hast, mach das Testfile nochmal und zwar mit einer
2 Farb Workbench. Guck obs schneller wird.
Kein Miami im hintergrund. Wenns geht die ausgaben von Lame >NIL:
und Zeit per Stoppuhr nehmen.

[ - Antworten - Zitieren - Direktlink - ]
13.04.2008, 23:55 Uhr

DaxB
Posts: 1421
Nutzer 		Guck doch mal mit Scout nach unter Tasklist, ob da evtl. irgendwas die CPU besonders beansprucht.

[ - Antworten - Zitieren - Direktlink - ]
14.04.2008, 22:27 Uhr

Rindenmolch
Posts: 176
Nutzer 		@MaikG
Tatsächlich die knapp zwei Minuten reduzieren sich auf 37 und 35 Sekunden in Pal bei zwei Farben. DBLPAL ist es etwas mehr - um die 40 Sekunden. Ich habe normalerweise Euro72Hz laufen in 640x400 und 256 Farben. Woran kann das liegen? Die sndfile.library habe ich genau die selbe.


@DaxB Hab Scout gezogen und nix verdächtiges gefunden.

[ - Antworten - Zitieren - Direktlink - ]
15.04.2008, 09:02 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Rindenmolch:
@MaikG
Tatsächlich die knapp zwei Minuten reduzieren sich auf 37 und 35 Sekunden in Pal bei zwei Farben. DBLPAL ist es etwas mehr - um die 40 Sekunden. Ich habe normalerweise Euro72Hz laufen in 640x400 und 256 Farben. Woran kann das liegen?

Offensichtlich müsstest Du Deinem Rechner mal ein wenig mehr echtes FastRAM spendieren. Oder aber irgenein Stück Software ist buggy, weil es für seinen Code (oder für Daten die das nicht brauchen) ChipRAM anfordert.
Wenn der Prozessor erst mal auf das ChipRAM zugreifen muss, wird er natürlich ausgebremst. Im Fall von Euro72Hz in 640x400x256 auf die maximal mögliche Weise. Da ist der Bus fast komplett dicht. Evtl. kannst Du sogar noch mehr rausholen, wenn Du auf LoRes umschaltest (musst Du halt scrollen).

Besser ist natürlich echtes FastRAM verwenden und den Prozessor komplett ungebremst laufen lassen.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]
15.04.2008, 09:47 Uhr

MaikG
Posts: 5172
Nutzer 		>Tatsächlich die knapp zwei Minuten reduzieren sich auf 37 und 35
>Sekunden in Pal bei zwei Farben. DBLPAL ist es etwas mehr - um die
>40 Sekunden. Ich habe normalerweise Euro72Hz laufen in 640x400 und
>256 Farben. Woran kann das liegen?


Beim zugriff auf die Customchips wird der Prozessor ausgebremst,
um so höher die Auflösung/Farben um so höher der Aufwand für die
Darstellung.

Deswegen ist AGA ab 68040 Verschwendung.



>Wenn der Prozessor erst mal auf das ChipRAM zugreifen muss, wird er natürlich ausgebremst.

Kann natürlich auch oder mit der Grund sein.


Nun hat er wieder nicht geschrieben wieviel Ram er hat.
Wenn er aber meine Kommandozeile benutzt müsste er beim Lame start
mindestens 4 MB für ein normales Lied frei haben da das lied
in die Ram Disk geht. Deswegen muss Lame normalerweise noch
genug freien Fastram haben.

[ - Antworten - Zitieren - Direktlink - ]
15.04.2008, 10:06 Uhr

Rindenmolch
Posts: 176
Nutzer 		Ich hab 64MB EDO-Fast auf ner Blizzard 1260. Ich denke das sollte genügen :D . Vermutlich wird es aber tatsächlich am Bus liegen, weil sich die Grafik schon extrem lahm aufbaut.

[ - Antworten - Zitieren - Direktlink - ]
15.04.2008, 11:40 Uhr

MaikG
Posts: 5172
Nutzer 		Ja, wie gesagt wenn du die Lame Text ausgaben wärend des encodierens
nach NIL: leiten würdest könnte das auch schon was ausmachen.
Immer auf 2 Farben zu gehen ist etwas umständlich.

FBlit sollte das ganze eigentlich Positiv beeinflussen,
die meisten Operationen werden damit im Fastmem gemacht.
Also sollte es Custom zugriff viel seltener geben.

[ - Antworten - Zitieren - Direktlink - ]
15.04.2008, 12:17 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von MaikG:
Deswegen ist AGA ab 68040 Verschwendung.
Auch beim '030er. Genau genommen, wird auch schon der '020 beim A1200 und CD³² so stark ausgebremst, dass man es ganz klar als großen Fehler ansehen kann, diese Geräte nicht schon ab Werk mit FastRAM (und wenns damals nur 1MB gewesen wäre) auszustatten.
Zitat:
Ja, wie gesagt wenn du die Lame Text ausgaben wärend des encodierens
nach NIL: leiten würdest könnte das auch schon was ausmachen.
Immer auf 2 Farben zu gehen ist etwas umständlich.
Außerdem bleibt Textausgabe eine prinzipiell aufwändige Rechenoperation (aus Sicht einer CPU). Selbst (bzw. gerade) bei xyzGHz Prozessoren kann man einen deutlichen Geschwindigkeitsunterschied sehen, wenn man Textausgaben vermeidet (als Programmierer schaltet man öfters Debug-Output an und wieder aus...)
Zitat:
FBlit sollte das ganze eigentlich Positiv beeinflussen,
die meisten Operationen werden damit im Fastmem gemacht.
Also sollte es Custom zugriff viel seltener geben.
Das Ziel ist bei einer Bildschirmausgabe trotzdem immer im ChipRAM. Geht ja gar nicht anders.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]
15.04.2008, 14:19 Uhr

MaikG
Posts: 5172
Nutzer 		>Außerdem bleibt Textausgabe eine prinzipiell aufwändige
>Rechenoperation (aus Sicht einer CPU). Selbst (bzw. gerade)


Deswegen macht Lame seine ausgaben auch nicht alle paar microsekunden.


>Das Ziel ist bei einer Bildschirmausgabe trotzdem immer im ChipRAM.
>Geht ja gar nicht anders.

Der Transfer ins Chipram wird mittels FBlit aber deutlich reduziert.
Inwieweit das Textausgaben betrifft weiss ich nicht, das war alles
viel zu lange her.
Seit ich die erste Grafikkarte hatte möchte AGA nur noch um
alte Sachen laufen zu lassen.

[ - Antworten - Zitieren - Direktlink - ]
15.04.2008, 16:22 Uhr

Rindenmolch
Posts: 176
Nutzer 		Ich versuche es nochmal mit NIL:. Mal sehen was dabei rauskommt. Dennoch kann ich mir nicht vorstellen, daß es nur an der Textausgabe liegt.

[ - Antworten - Zitieren - Direktlink - ]

1 2 -3- [ - Beitrag schreiben - ]


amiga-news.de Forum > Amiga, AmigaOS 4 > Lame 3.93.1 und 68060 vs. PPC [ - Suche - Neue Beiträge - Registrieren - Login - ]


.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten.
.