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

amiga-news.de Forum > Programmierung > Transverspeed PPC603e -> BVision [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- 2 3 4 [ - Beitrag schreiben - ]

19.04.2005, 17:38 Uhr

Ralf27
Posts: 2779
Nutzer
Ich hab eben mein kleines Programm umgeschrieben auf only CybergraphX und hab mal denn Speed getestet.

Für ein 24Bit, 3,6MB großes Bild braucht mein Programm für denn Transver zur Grafikkarte (1600*1200*24) ca. 1 Sekunde. Somit erreiche ich in dieser Auflösung ca. 3,6MB pro Sekunde.

Wie schnell ist eigentlich die BVision? Wie schnell kann ich Daten auf die Grafikkarte schaufeln?

Es müßte doch eigentlich schneller gehn als 3,6MB pro sek, oder?


PS: Need more Speed. :D
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

19.04.2005, 18:28 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Ralf27:

Wie schnell ist eigentlich die BVision? Wie schnell kann ich Daten auf die Grafikkarte schaufeln?

Es müßte doch eigentlich schneller gehn als 3,6MB pro sek, oder?


PS: Need more Speed. :D
--
http://www.alternativercomputerclub.de.vu


:D

Dann beschreib doch mal, auf welche Weise Du die Bilddaten zur GraKa übertragen läßt, davon hängt die Geschwindigkeit nämlich unmittelbar ab. Im übrigen solltest Du ganz scharf darauf achten, ob Du die Bilddaten nicht zufällig im Chip RAM liegen hast. Wenn doch, brauchst Du Dich über die "Geschwindigkeit" nicht zu wundern :D

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

19.04.2005, 18:59 Uhr

MaikG
Posts: 5172
Nutzer
PCI geschwindigkeit?

Muss am Sourcecode liegen.

Beim 68060

REM $NOOVERFLOW

Die Funktion verlangsamt das Programm auf 060 extrem.

[ - Antworten - Zitieren - Direktlink - ]

19.04.2005, 20:44 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Original von whose:
Dann beschreib doch mal, auf welche Weise Du die Bilddaten zur GraKa übertragen läßt, davon hängt die Geschwindigkeit nämlich unmittelbar ab. Im übrigen solltest Du ganz scharf darauf achten, ob Du die Bilddaten nicht zufällig im Chip RAM liegen hast. Wenn doch, brauchst Du Dich über die "Geschwindigkeit" nicht zu wundern :D

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233


Die Daten liegen im Fastram. Wenn sie im Chip wären und diesen Speed erreichen würde, dann wäre es doch eigentlich unglaublich, oder? :D

Ich jag die Daten mit einem einzigen Befehl komplett in die Grafikkarte:
Bis 8Bit mit WriteLUTPixelArray und bei 24Bit mit WritePixelArray.

Somit läuft der gesamte Transver ab. Und genau diese Befehle brauchen so lange.

Wie kann man das beschleunigen? Andere Befehle?

--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

19.04.2005, 20:49 Uhr

Holger
Posts: 8090
Nutzer
Zitat:
Original von Ralf27:
Für ein 24Bit, 3,6MB großes Bild braucht mein Programm für denn Transver zur Grafikkarte (1600*1200*24) ca. 1 Sekunde. Somit erreiche ich in dieser Auflösung ca. 3,6MB pro Sekunde.

Bei mir sind 1600x1200x3 5760000 bytes, also 5,5 MB, die transferiert werden müssen.

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

[ Dieser Beitrag wurde von Holger am 19.04.2005 editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

19.04.2005, 20:57 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Original von MaikG:
PCI geschwindigkeit?

Muss am Sourcecode liegen.

Beim 68060

REM $NOOVERFLOW

Die Funktion verlangsamt das Programm auf 060 extrem.


Unwahrscheinlich das es am Programm liegt, denn ich rufe gerade mal einen Befehl auf aus dem System (cybergraphX) und dieser braucht so lange.

Aber die ganzen Compileroptionen setze ich schon, das macht schon recht viel aus.
Das hab ich ja auch schon alles ausgetestet.


:D
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

19.04.2005, 20:58 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Original von Holger:
Zitat:
Original von Ralf27:
Für ein 24Bit, 3,6MB großes Bild braucht mein Programm für denn Transver zur Grafikkarte (1600*1200*24) ca. 1 Sekunde. Somit erreiche ich in dieser Auflösung ca. 3,6MB pro Sekunde.

Bei mir sind 1600x1200x3 5760000 bytes, also 5,5 MB, die transferiert werden müssen.

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

[ Dieser Beitrag wurde von Holger am 19.04.2005 editiert. ]



Ja, aber das Bild ist kleiner das da rein verschoben wird. Und dieses hat ca. 3,6MB Rohdaten (24Bit RGB)
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

19.04.2005, 22:00 Uhr

Holger
Posts: 8090
Nutzer
Zitat:
Original von Ralf27:
24Bit RGB

Ist das in jedem Fall RGB oder auch BGR etc, ja nach Bedarf? Wenn ich mich recht entsinne, erlaubt die CGX-Funktion verschiedene Formate, die dann in das tatsächliche Screen-Format konvertiert werden. Das tatsächliche Pixelformat vorher zu ermitteln, und die Bilddaten gleich in diesem Format vorzuhalten, könnte durchaus die Performance verbessern.

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

[ - Antworten - Zitieren - Direktlink - ]

19.04.2005, 22:14 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Holger:
Ist das in jedem Fall RGB oder auch BGR etc, ja nach Bedarf? Wenn ich mich recht entsinne, erlaubt die CGX-Funktion verschiedene Formate, die dann in das tatsächliche Screen-Format konvertiert werden. Das tatsächliche Pixelformat vorher zu ermitteln, und die Bilddaten gleich in diesem Format vorzuhalten, könnte durchaus die Performance verbessern.


Das ist auch bei P96 so, weil sonst z.B. die Workbench auf nem 24Bit-Screen nicht machbar wäre.

Allerdings hätt ich auch darauf kommen können, daß das Format der zu übertragenden Daten dem Screen "nicht paßt". Das könnte des Rätsels Lösung sein, diesen Zusammenhang übersieht man leicht.

Naja, mal schauen was Ralf uns jetzt dazu sagt 8)

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

19.04.2005, 22:24 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Original von whose:
Naja, mal schauen was Ralf uns jetzt dazu sagt 8)


Ich hab immer was zu tippen! :D :D


Also, das mit dem Format ist so eine Sache. Es wäre wohl wirklich am besten wenn beides zusammenpast: Screen und Daten.

Hm, mal sehn wie ich das mach. Muß mich mal später mal durch die AutoDocs stöbern und mal sehn wie ich das mach. Eigentlich würde dieser Speed auch reichen, aber ich will mehr! :lach: :D



Wie hoch ist aber denn nun eigentlich der theoretische MaxSpeed von der 603e über den miniPCI-Port in die Grafikkarte? :dance3:
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

19.04.2005, 23:01 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Ralf27:
Zitat:
Original von whose:
Naja, mal schauen was Ralf uns jetzt dazu sagt 8)


Ich hab immer was zu tippen! :D :D


Das hab ich mir irgendwie schon gedacht :D

Zitat:
Also, das mit dem Format ist so eine Sache. Es wäre wohl wirklich am besten wenn beides zusammenpast: Screen und Daten.

So siehts aus. bei CGFX und P96 ists so, daß WritePixelArray() bei passendem Format der Grafikdaten einfach ein MemCopy() durchführt, viel schneller geht nur mit handoptimiertem Assembler und direktem Zugriff aufs Video RAM. Warum man das vermeiden sollte, muß ich, glaub ich, nicht erklären, oder? ;)

Zitat:
Hm, mal sehn wie ich das mach. Muß mich mal später mal durch die AutoDocs stöbern und mal sehn wie ich das mach. Eigentlich würde dieser Speed auch reichen, aber ich will mehr! :lach: :D

GetCyberMapAttr() dürfte das Gesuchte sein ;)

Zitat:
Wie hoch ist aber denn nun eigentlich der theoretische MaxSpeed von der 603e über den miniPCI-Port in die Grafikkarte? :dance3:
--
http://www.alternativercomputerclub.de.vu


Gute Frage, nächste Frage. Kannst ja mal mit direktem Zugriff aufs Video RAM messen (und nur zum Messen direkter Zugriff ;) )

Grüße



--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

19.04.2005, 23:09 Uhr

Ralf27
Posts: 2779
Nutzer
So, ich hab eben mal nachgesehn. Also, die WB ist wirklich ein BGR-Screen, aber auch der Screen der mein Compiler aufmacht.

Das bedeutet, das ich ein RGB-Screen verlangen muß, da ich ja leider nicht die Daten im BGR-Format an WritePixelArray übergeben kann.

Hm, jetzt vermute ich mal das nicht alle Grafikarten einen RGB-Screen aufbauen können. Da muß ich wohl noch einiges einbauen.

Zur Zeit benutze ich ja in Basic einfach denn Screen Befehl, um einen Screen zu öffnen. Ich muß wohl bald die Systemroutinen benutzen. :D

Mal sehn ob ich auch testweise die WB auf ein RGB-Screen legen kann.

Was für ein Vorteil hat denn ein BGR-Screen gegenüber einem RGB-Screen? Wieso gibt es denn 2 Varianten und nicht nur eine? Wollte da jemand die Programmierer ärgern? :lach: Oder wollte da Microsoft einen neuen Standard definieren(die machen ja die Hardware über ihre Software verrückt)? :lach:
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

20.04.2005, 00:12 Uhr

Ralf27
Posts: 2779
Nutzer
Nicht so einfach mit dem BGR-Screen aufmachen. Hab es eben mit dem CModeRequestTagList versucht, aber leider lief das auch nicht richtig. Ich hab als einzige TAG-Übergabe angegeben das ich nur BGR-Screens will, die Auswahl bringt mir nur 8Bit-Screens... ?

Gehe ich recht in der Annahme, das ein RGB-Screen nur eine andere ID hat als ein BGR-Screen?

Was für eine ID hat 1024*768*24 RGB (BGR) auf der BVision?
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

20.04.2005, 02:48 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Ralf27:
Nicht so einfach mit dem BGR-Screen aufmachen. Hab es eben mit dem CModeRequestTagList versucht, aber leider lief das auch nicht richtig. Ich hab als einzige TAG-Übergabe angegeben das ich nur BGR-Screens will, die Auswahl bringt mir nur 8Bit-Screens... ?

Gehe ich recht in der Annahme, das ein RGB-Screen nur eine andere ID hat als ein BGR-Screen?

Was für eine ID hat 1024*768*24 RGB (BGR) auf der BVision?
--
http://www.alternativercomputerclub.de.vu


:dance3:

Erst ists BGR, dann gehts nicht? Naja, lange Rede, kurzer Sinn: Schau Dir mal in den CGFX-Autodocs die Abteilung über das modifizierte AllocBitMap() an, damit kannst Du einer Bitmap bereits beim Anlegen das benötigte Format mitgeben und die später relativ einfach z.B. via Blit...-Funktionen in eine Screen-Bitmap "blitten" (klingt komisch, wenn man bedenkt, daß die Daten im FastRAM liegen können :D ). AllocBitmap() ist wie gesagt durch CGFX (P96) modifiziert, um auch Bitmaps eines anderen Formats als Planar einigermaßen systemkonform anlegen zu können. Das entsprechende Flag hört auf den Namen BMB_SPECIALFMT

Du kannst diese "selbstgebaute" Bitmap allerdings nicht zum Öffnen eines Screens verwenden, mußt schon noch die Daten selbst von Deiner selbstgebastelten Bitmap in den gewünschten Screen übertragen, z.B. über die Blit...-Funktionen.

Also erst das Pixelformat des geöffneten Screens ermitteln und dann dementsprechend per AllocBitmap() eine Bitmap basteln lassen, die später die geladenen Bilddaten im dem Screen genehmen Format enthält.

Mit der Methode kannst Du alle möglichen Formate verarzten (sofern die von CGFX/P96 unterstützt werden).

Hast aber sicher gemerkt, daß Du da um eine Konvertierung so oder so nicht herumkommst, aber auf diese Weise verlegst Du die Konvertierung geschickt auf den Ladevorgang, wo es nicht so auffällt ;) . Zusätzlich umgehst Du damit das (in CGFX) lahme WritePixel() (bevor wer weint: P96 hat auch so seine "Flaschenhälse" in der 68K-Version).

Im Zweifelsfall bleibt Dir immer noch der harte Weg des direkten Zugriffs offen, aber vor dem Weg warne ich Dich nicht ohne Grund. Müßtest nämlich _alle_ möglichen Bitmap-Formate berücksichtigen I-)

Grüße

P.S.: Übrigens: Halt Dich nicht so sehr an den "speziellen" Formaten und schon gar nicht an bestimmten Screenmode-IDs fest, das geht ins Auge! Nimms einfach hin, daß es verschiedene Formate gibt und leg entsprechend aufgebaute Bitmaps mit den dafür vorgesehenen Systemfunktionen an. Dann läufts nämlich auch auf anderen GraKas als der BVisionPPC ;) Kleiner Tip noch zum Schluß: Schau mir mal die BlitzBasic2-Includes von Thilo Köhler an, da findet man ne Menge Information, wie man mit GraKa-Bitmaps >8Bit und Systemfunktionen arbeitet, und das sogar ziemlich fix.

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

20.04.2005, 09:08 Uhr

gni
Posts: 1106
Nutzer
Zitat:
Holger:
Zitat:
Ralf27:
Transver

transferiert
Du hättest das f groß schreiben sollen. So fällt es kaum auf ;-)

[ - Antworten - Zitieren - Direktlink - ]

20.04.2005, 09:22 Uhr

Ralf27
Posts: 2779
Nutzer
Ja, ist etwas verwirrend. Also die Daten liegen im BGR-Format vor. Die CybergraphX-Funktion braucht die Daten im RGB-Format (ok, gibt es die Möglichkeit mit RGBA, ARGB, etc.), also muß ich diese Wandeln.
Der Screen war bis jetzt immer BGR, aber leider würde dann wieder(!) die Funktion von CybergraphX die Daten wandeln, also müßte ein RGB-Screen her.

Ich hab mich da oben auch schon etwas verschrieben mit RGB<->BGR.



Achja, die Transfer-Sache:
Ich dachte auch erst, da würde eventuell Dreck auf dem Monitor liegen, da der eine Buchstabe so fett ist :lach:


Das sind die lieben kleinen Fehler die einem nie auffallen das sie falsch sind wie z.b. der berühmte Standard. :lach:
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

20.04.2005, 09:40 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Original von whose:
Hast aber sicher gemerkt, daß Du da um eine Konvertierung so oder so nicht herumkommst


Hm, wenn das wirklich funktioniert (muß mich erst mal wieder durcharbeiten, aber jetzt geht wieder die Firma vor), dann muß ich gar nicht konvertieren und hab so gleich nochmal viel mehr Speed! :shock2: :D

Die Rohdaten liegen im BGR-Format vor und wenn ich so die Daten in denn Speicher bekomme und ich auch so "blitten" kann, dann geht es wirklich sehr viel schneller.

Bin schon gespannt, mich juckt es sogar schon in den Fingern das ganze auszutesten. :D
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

20.04.2005, 10:15 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Ralf27:
Die Rohdaten liegen im BGR-Format vor und wenn ich so die Daten in denn Speicher bekomme und ich auch so "blitten" kann, dann geht es wirklich sehr viel schneller.


Allerdings nur für den Fall, daß die GraKa die Bitmap im BGR-Format anlegt. Das gilt "leider" nicht für alle GraKas. Denk auch an die armen "Schweine", die keine B/CVisionPPC ihr eigen nennen können :D

Probiers aber erstmal aus. Später kannst Du ja immer noch die Konvertierung ins jeweils passende Bitmap-Format in Deine Laderoutinen einbauen.

Grüße


--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

20.04.2005, 10:29 Uhr

MaikG
Posts: 5172
Nutzer
>Zur Zeit benutze ich ja in Basic einfach denn Screen
>Befehl, um einen Screen zu öffnen. Ich muß wohl
>bald die Systemroutinen benutzen.

Solltest du unbedingt, dir scheint nicht bekannt zu
sein das MB für Screen und Windows Chip-Speicher benutzt?

[ - Antworten - Zitieren - Direktlink - ]

20.04.2005, 10:43 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Original von MaikG:
>Zur Zeit benutze ich ja in Basic einfach denn Screen
>Befehl, um einen Screen zu öffnen. Ich muß wohl
>bald die Systemroutinen benutzen.

Solltest du unbedingt, dir scheint nicht bekannt zu
sein das MB für Screen und Windows Chip-Speicher benutzt?


Ne, das ist mir wirklich nicht bekannt. Auch wenn der Screen auf der Grafikkarte aufgemacht wird? :dance3: :dance3:

Darauf habe ich nie geachtet. Mit dem Screen-Befehl ist es halt sehr einfach einen beliebigen Screen aufzumachen.

Aber irgendwie... wie bekommt er bei 1600*1200*24 über 5MB Chipram?
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

20.04.2005, 12:13 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Ralf27:
Zitat:
Original von MaikG:
>Zur Zeit benutze ich ja in Basic einfach denn Screen
>Befehl, um einen Screen zu öffnen. Ich muß wohl
>bald die Systemroutinen benutzen.

Solltest du unbedingt, dir scheint nicht bekannt zu
sein das MB für Screen und Windows Chip-Speicher benutzt?


Ne, das ist mir wirklich nicht bekannt. Auch wenn der Screen auf der Grafikkarte aufgemacht wird? :dance3: :dance3:


Eben. Deswegen: Keine Panik! :D

MaxonBasic nutzt dazu (wie es sich gehört ;) ) OS-Funktionen, die durch das RTG-System schon "zurechtgepatcht" sind damit nix im ChipRAM landet, wenn nicht zwingend notwendig.

Ich weiß allerdings nicht, ob Du an die RastPort-Struktur der MB-internen Screens/Windows herankommst. Die brauchst Du, wenn Du von Deiner "selbstgebauten" in die Screen-/Window-Bitmap "blitten" willst. Aber selbst, wenn das nicht gehen sollte: Dir bleiben immer noch die OS-Funktionen I-)

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

20.04.2005, 12:27 Uhr

Ralf27
Posts: 2779
Nutzer
[quote]
Original von whose:
Zitat:
BMB_SPECIALFMT

Leider hab ich diesen Flag nicht in meiner Include gefunden und hab eben mal in der C-Include nachgesehn und ihn dort gefunden. Ist der Wert 7? Denn müßte ich dann auch in meinen MB-Includes einfügen.

PS:
Blöder Tag heute. Ich hab hier nur Minutenweise Arbeit in der Firma und heute Abend geht es wieder rund mit einem Auftrag. Zsss. Arbeiten, wenn Arbeit da ist und Freizeit wenn keine da ist. Aber ich denke mir mal, das das bald bei vielen so gehen wird. Allerdings bekommen die Arbeiter immer mehr Lasten aufgedrückt und die reichen Leute werden immer reicher... grummel... :angry:

[ Dieser Beitrag wurde von Ralf27 am 20.04.2005 editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

20.04.2005, 12:37 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Original von whose:

Ich weiß allerdings nicht, ob Du an die RastPort-Struktur der MB-internen Screens/Windows herankommst. Die brauchst Du, wenn Du von Deiner "selbstgebauten" in die Screen-/Window-Bitmap "blitten" willst. Aber selbst, wenn das nicht gehen sollte: Dir bleiben immer noch die OS-Funktionen I-)

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233


Da ich immer denn Screen-Befehl benutze und auch eigentlich immer denn Windows Befehl, benutze ich auch die Windows-Funktion, um an die Strukturen zu kommen wie z.b. rastport&=window(8) oder win&=window(7)

Wenn dies nicht möglich gewesen wäre, dann hätte ich ja viele Betriebssystemroutinen nicht nutzen können.

Allerdings finde ich es sehr interesant zu sehn das viele MB-Demos über die Systemroutinen gehn. Allerdings sehen dann die MB-Demos aus wie C-Quellcode. Teilweise versteh ich dann nur Bahnhof, denn dann sieht für mich wirklich C und MB gleich aus. :lach:

Man sieht da schon das die Entwickler da aus dem C-Bereich kommen und halt logischerweise so in MB proggen wie sie es halt auch im C machen würden.

Aber ich möchte halt das ganze in MB durchziehn und eigentlich müßte das auch soweit gehn und ich dürfte auch an die maximale Geschwindigkeit der Grafikkarte kommen, da ja die ganze "Rechenlast" auf den Systemroutinen liegt.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

20.04.2005, 14:03 Uhr

Ralf27
Posts: 2779
Nutzer
Hab mich eben mal etwas erkundigt:

Laut http://www.amigaspeed.de.vu erreichte ich maximal ca. 6,2MB pro Sekunde bei 24Bit. (bei 210MHz, ich hab 240MHz)
Das hat mich sehr überrascht, denn ich erreiche diesen Wert zur Zeit auch und das mit der Konvertierung! Bei der letzten Messung hab ich bei mir einen kleinen Fehler gemacht. Es lief einfach zuviel im Hintergrund, bzw. irgendwas hat zu diesem Zeitpunkt Rechenleistung "gefressen", denn der jetzige Test brachte 3,6MB pro 0,41 Sek= ca. 8,8MB pro Sekunde bei 1600*1200*24.

Laut amigaspeed ist der 16Bit-Screen nochmal 4 mal so schnell, wobei wir dann bei 35MB pro Sek wären. Ich muß echt tippen das es wirklich langsam schnell wird.
(bevor hier jetzt einige anfangen zu tippen: für Amiga-Verhältnisse)

Und dann sollte man noch tippen das da noch die Konvertierung in Echtzeit läuft, die man ja auch vorher auch noch machen kann.

Ich sehe da noch SpeedUp-Möglichkeiten. :D :D
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

20.04.2005, 19:10 Uhr

MaikG
Posts: 5172
Nutzer
>Ne, das ist mir wirklich nicht bekannt. Auch wenn der
>Screen auf der Grafikkarte aufgemacht wird?

Das hab ich nicht probiert.
Auf meiner Workbench sind immer 2 MB Chip frei,
wenn dann 200kb fehlen wenn MB ein Fenster auf macht,
ist klar was sache ist.
Das Fenster war auf der Workbench - 16 Bit Grafikkarten
Schirm.

Seitdem nehme ich die Fenster vom System, sind viel schneller.

>Darauf habe ich nie geachtet. Mit dem Screen-Befehl ist
>es halt sehr einfach einen beliebigen Screen aufzumachen.

Ich denke das schaffst du auch mit Betriebssystem Routinen.

[ - Antworten - Zitieren - Direktlink - ]

20.04.2005, 20:22 Uhr

Holger
Posts: 8090
Nutzer
Zitat:
Original von whose:
So siehts aus. bei CGFX und P96 ists so, daß WritePixelArray() bei passendem Format der Grafikdaten einfach ein MemCopy() durchführt, viel schneller geht nur mit handoptimiertem Assembler und direktem Zugriff aufs Video RAM. Warum man das vermeiden sollte, muß ich, glaub ich, nicht erklären, oder? ;)

Man sollte vor allem unabhängig von der Frage, ob die momentan betrachtete Hardware das so macht, berücksichtigen, daß manche Systeme den entsprechenden Transfer von der Grafikkarte und nicht vom Prozessor erledigen lassen könnten.
Und dann kann der Assembler-Code noch so handoptimiert sein, gegen ein Busmaster-Transfer kommt er nicht an.
Deshalb ist auch ein Transfer ohne Konvertierung besser. Nicht weil sie Zeit kostet (meist kann sie parallel ausgeführt werden), sondern weil manch ein Chip möglicherweise Direkttransfers unterstützt, aber keine Pixelformat-Konvertierung in Hardware besitzt. Und somit die Frage Konvertierung oder nicht über die Frage Hardwarebeschleunigung oder nicht entscheidet.

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

[ - Antworten - Zitieren - Direktlink - ]

20.04.2005, 20:53 Uhr

Holger
Posts: 8090
Nutzer
Zitat:
Original von whose:
Also erst das Pixelformat des geöffneten Screens ermitteln und dann dementsprechend per AllocBitmap() eine Bitmap basteln lassen, die später die geladenen Bilddaten im dem Screen genehmen Format enthält.

Zu kompliziert. Zu genau diesem Zweck gibt es ja "friend bitmaps". Beim Anlegen der Offscreen-BitMap die Screen-BitMap angeben und gut is.
Das reale Pixelformat überprüft man nur, um herauszufinden, ob es zu den direkt unterstützten Formaten, wie eben BGR (wenn die Bild-Daten ohnehin schon so vorliegen) gehört, oder ob man den Umweg über RGB geht.

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

[ - Antworten - Zitieren - Direktlink - ]

20.04.2005, 22:24 Uhr

Ralf27
Posts: 2779
Nutzer
So, erstmal Stück für Stück:

BMB_SPECIALFMT:
Leider hab ich diesen Flag nicht in meiner Include gefunden und hab eben mal in der C-Include nachgesehn und ihn dort gefunden. Ist der Wert 7? Denn müßte ich dann auch in meinen MB-Includes einfügen.

Rohdaten BGR:
Ich hab die Daten ins RGB-Format gewandelt, weil es so die WritePixelArray-Funktion verlangt.

Wenn ich aber die BGR-Daten so in eine mit AllocBitmap generierte Map (mit BGR-Format) ablege, kann ich also die BGR-Daten direkt in ein BGR-Screeen mit ClipBlit(?) kopieren?

Langsam bekomm ich en Knoten im Hirn. :lach:

Andere Frage:
Ich hab versucht mit CModeRequestTagList eine Auswahl mit entsprechenden Screens (Farbtiefe vorgegeben=24, RGB-Farbformat=9) zur Auswahl zur stellen, aber leider bringt er mir dann nur 8Bit-Screens? :dance3:
PS: Mir ist klar das man ASL-Requester nehmen sollte.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

20.04.2005, 22:26 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Original von MaikG:
>Ne, das ist mir wirklich nicht bekannt. Auch wenn der
>Screen auf der Grafikkarte aufgemacht wird?

Das hab ich nicht probiert.
Auf meiner Workbench sind immer 2 MB Chip frei,
wenn dann 200kb fehlen wenn MB ein Fenster auf macht,
ist klar was sache ist.
Das Fenster war auf der Workbench - 16 Bit Grafikkarten
Schirm.

Seitdem nehme ich die Fenster vom System, sind viel schneller.

>Darauf habe ich nie geachtet. Mit dem Screen-Befehl ist
>es halt sehr einfach einen beliebigen Screen aufzumachen.

Ich denke das schaffst du auch mit Betriebssystem Routinen.


Ist mir noch nie aufgefallen. Werde mir das später einmal genauer ansehn. Aber ich kann mir kaum vorstellen das MB die Fenster anderst auf macht, bzw. für was er dann z.b. 200kb reserviert. Für die Option 16(Refresh)? Wäre möglich...

Muß ich mir später mal alles ansehn, wenn ich Zeit hab.



--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

21.04.2005, 01:31 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Ralf27:
So, erstmal Stück für Stück:

BMB_SPECIALFMT:
Leider hab ich diesen Flag nicht in meiner Include gefunden und hab eben mal in der C-Include nachgesehn und ihn dort gefunden. Ist der Wert 7? Denn müßte ich dann auch in meinen MB-Includes einfügen.


Das müßte Bit 7 im Flag-Byte sein, also Dezimal 128. Schau ich im Zweifel aber gern nach.

Zitat:
Rohdaten BGR:
Ich hab die Daten ins RGB-Format gewandelt, weil es so die WritePixelArray-Funktion verlangt.


Ja, das habe ich mir schon gedacht :D

Zitat:
Wenn ich aber die BGR-Daten so in eine mit AllocBitmap generierte Map (mit BGR-Format) ablege, kann ich also die BGR-Daten direkt in ein BGR-Screeen mit ClipBlit(?) kopieren?

Langsam bekomm ich en Knoten im Hirn. :lach:


Alles halb so wild :lach: Ja, wenn Du die Daten bereits im passenden Format (also passender Byte-Reihenfolge, Endianess beachten!) aus der Datei bekommst, kannst Du die direkt in Deine eigene Bitmap reinschreiben und diese dann auf die GraKa rüberblitten.

Zitat:
Andere Frage:
Ich hab versucht mit CModeRequestTagList eine Auswahl mit entsprechenden Screens (Farbtiefe vorgegeben=24, RGB-Farbformat=9) zur Auswahl zur stellen, aber leider bringt er mir dann nur 8Bit-Screens? :dance3:
PS: Mir ist klar das man ASL-Requester nehmen sollte.


Das hat mit der Art des verwendeten Requesters wenig zu tun. Das liegt schlicht daran, daß der Permedia2-Grafikchip, der auf der C-/BVisionPPC eingesetzt wird, in den Modi >8Bit nur BGR-Reihenfolge unterstützt (soweit ich weiß. Wenns anders ist, bitte korrigieren). Nur bei den 8Bit-Modi bietet der Chip RGB-Format für die _Paletten-Einträge_ an. Daher siehst Du eben auch nur die 8Bit-Modi im Requester. Probiers doch mal umgekehrt, dann müßten die 8Bit-Modi verschwinden I-)

Du solltest allerdings in Deinem Programm darauf verzichten, bestimmte Pixelformate bei der Screen-Auswahl vorauszusetzen. Nicht jeder hat ne GraKa, die BGR-Pixelformat bietet und diejenigen bleiben dann außen vor. Schreibs lieber gleich so, daß es die Bilddaten gleich in das von der GraKa benötigte Pixelformat konvertiert, dann läufts überall. Ist zwar mehr Arbeit, bringt aber auch mehr "Kunden" :D

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 21.04.2005 editiert. ]

[ Dieser Beitrag wurde von whose am 22.04.2005 editiert. ]

[ - Antworten - Zitieren - Direktlink - ]


-1- 2 3 4 [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > Transverspeed PPC603e -> BVision [ - Suche - Neue Beiträge - Registrieren - Login - ]


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