[ - Antworten - Zitieren - Direktlink - ]

16Bit sind schon recht interesant. Ich werd später einfach mal in mein Programm so ein 24->16 Konverter einbauen und mal sehn wie die Sache mit 16Bit rennt.

PS: Konverter in Basic.

PPS: Ich werd irgend wann mal einfach mal aus Fun das ganze mit AmigaBasic laufen lassen. Mal sehn wie das läuft. Allerdings verträgt AmigaBasic leider keinen echten Fastram. Denn muß ich dann abschalten... (mir ist klar das das total sinnlos ist, aber es interesiert mich eben! )
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

Erstmal ein grosses Dankeschön an alle hier in diesem Thread!
Ich habe die Tipps erfolgreich "mitbenutzen" können um eine meiner Grafikroutinen (bisher 4Byte pro Pixel ARGB und mit WritePixelArray) auf 16Bit (mit besagter zweiten Bitmap) runterzubauen, PC Screenmodes zu erkennen und zu verwenden, dabei um den gefühlten Faktor 2 bis 3 mal so schnell zu laufen und nur noch halb so viel Speicher zu verbrauchen!
Und ich dachte, ich hätte vorher schon was über Grafikkartenprogrammierung gewusst...
Nochmals Danke!

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MarkusPohlmann:
Erstmal ein grosses Dankeschön an alle hier in diesem Thread!
Ich habe die Tipps erfolgreich "mitbenutzen" können um eine meiner Grafikroutinen (bisher 4Byte pro Pixel ARGB und mit WritePixelArray) auf 16Bit (mit besagter zweiten Bitmap) runterzubauen, PC Screenmodes zu erkennen und zu verwenden, dabei um den gefühlten Faktor 2 bis 3 mal so schnell zu laufen und nur noch halb so viel Speicher zu verbrauchen!
Und ich dachte, ich hätte vorher schon was über Grafikkartenprogrammierung gewusst...
Nochmals Danke!

---

Dazu ist doch das Forum mit seinen User da.

Ich hab da aber eine Frage:
Ist bei dir der Speed mit BltBitMap höher als mit WritePixelArray? Ich hab leider festgestellt das es bei mir nicht der Fall ist, obwohl es eigentlich schneller sein müßte. Da war bzw. ist schon depremierend.

Aber denn 16Bit-Mode werde ich auch bald mal "geniesen".

Aber zur Zeit hab ich andere Sachen vor und bin weniger am Computer. Vorallem das Wetter ist einfach zu genial als am Computer zu sitzen.

In diesem Sinne -->

(Zur Zeit hab ich leider auch etwas denn Faden an meinem Programm verloren...)
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

Hm, also ich habe das jetzt nicht explizit nachgemessen, kann ich ja aber vielleicht heute mal nachholen.

Der Hauptknackpunkt wodurch ich eigentlich Geschwindigkeit gewinne ist die Speicherersparnis.

Meine Grafikroutine bisher:
Ich habe einen Bildpuffer ULONG *Buffer in mit 640*480*4 Bytes
Jetzt kopiere ich die Grafik dafür zusammen und zwar pro Pixel 4 Byte im Format PIXFM_ARGB.
WritePixelArray füttere ich dann mit dem Buffer so dass das auf die Grafikkarte kommt (zur Zeit jetzt auch 16Bit Screen, war vorher aber sogar passend 24).

Meine Grafikroutine neu, wie im Prinzip hier im Thread beschrieben:
Ich allokiere eine passende zweite Bitmap, locke die und verwende einen Pointer UWORD *Grafik den ich auf die Adresse der Bitmapdaten lege. Jetzt kopiere ich die Grafik aus nur noch zwei Byte pro Pixel zusammen, direkt in diese Bitmap.
Anschliessen "un-gelocked" und mit BltBitmap rüber zur Grafikkarte.

Ich denke, die nun "fehlenden" 640*480*2 Bytes sind der Knackpunkt, aber ich kann mal Messen, wie lange was dauert. Vielleicht gibt's ja noch was zu tunen?

P.S.: Interessant ist allerdings, dass mein Programm für sich alleine gestartet - auch mehrmals - bestens läuft und auch allen Speicher wieder freigibt.
Im Debugger laufen gelassen crasht das Programm nach einmaligem Lauf die Entwicklungsumgebung vielleicht (Icons sind schonmal hinüber), nach dem zweiten Lauf 100%ig.
Da huschen mir wohl noch ein paar Bit in falsche Speicherbereiche...

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Ralf27:

Ich hab da aber eine Frage:
Ist bei dir der Speed mit BltBitMap höher als mit WritePixelArray? Ich hab leider festgestellt das es bei mir nicht der Fall ist, obwohl es eigentlich schneller sein müßte. Da war bzw. ist schon depremierend.

---

Naja, inzwischen kenne ich den Grund, hätte aber auch früher drauf kommen können *stirnklatsch*

Im Grunde passiert sowohl bei WritePixelArray() als auch bei BltBitmap()&Co. unter CGFX/P96 jeweils das Gleiche, wenn die Bitmap im FastRAM liegt: Ist der Bildschirmmodus der zur Bitmap passende, MemCopy(), wenn nicht, Transfer FastRAM->VideoRAM mit impliziter Konvertierung.

Das bedeutet, daß sowohl bei WritepixelArray() als auch bei BltBitMap() jeweils die höchstmögliche Transferrate (des 68K-Prozessors über Zorro bzw. verkrüppeltem Mini-PCI) erreicht wird. Über den Bus bedeutet ja automagisch auch "aus dem FastRAM", da kann BlitBitMap() kaum etwas an Speedgewinn erreichen (wie auch, wenn der Blitter gar nicht an die Daten herankommt? ).

Liegt die Bitmap im GraKa-Speicher wirds per BlitBitMap() enorm schnell. Allerdings funktioniert in diesem Fall auch nur BltBitMap()

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Ralf27:
Schon klar das bei beiden Funktionen das gleiche passiert, aber wenn die Bitmap schon in dem Format vorliegt wie es auch der Grafikkartenscreen braucht, dann müßte das doch schneller gehn als mit WritePixelArray und Konvertierung.

---

Jain. Das "Problem" dabei ist, daß bei der Übertragung über den Bus eine Pause eingelegt werden muß (der ist halt nicht ganz so schnell wie das CPU-RAM-Gespann). Das bemerkst Du besonders gut bei Zorro-Systemen. In dieser "Pause" wird (unabsichtlich, aber praktisch ) die Konvertierung durch die CPU im FastRAM (oder in CPU-Registern, je nach Aufwand) schon mal "im Voraus" erledigt. Das bedeutet, daß trotz Konvertierung der Bus voll ausgelastet wird, genau wie ohne Konvertierung.

Schön kann man das auf 040ern beobachten, die bei 24Bit enorm einknicken, auch wenn sie über Zorro3 übertragen können (und bei einem 060er die "Pause" bei der Übertragung für die Konvertierung reicht). Bei denen reicht die Zeit der "Pause" nicht ganz, um die Konvertierung zu erledigen. Da ist dann angesagt, erstmal die Konvertierung zu beenden und dann auf das nächste "Transfer-Fenster" des Zorro-Bus zu warten. Bin durch meinen anderen 1200er mit CV64/3D drauf gestoßen. Der ist bei 24Bit nämlich enorm lahm, die selbe Karte in meinem 4000/060 war deutlich "schneller"

Zitat:

---

Aber das bringt mich zur Schlussfolgerung das die Konvertierung von der Grafikkarte gemacht wird? Ist dies möglich?!? Das würde einiges erklären.

---

Auch wieder: Jain. Ich weiß nicht genau, welche der GraKas für den Amiga solche Hardware integriert hatten (ich glaub, die Merlin2 wars), aber das waren wenn nur ganz, ganz wenige. Das CD32 besitzt mit dem Akiko so etwas ähnliches, das ist ein Chunky2Planar-Konverter in Hardware. Allerdings kann der keine Chunky-Formate in ein anderes verwandeln. Die modernen Chips (wie der Permedia2) besitzen sowas nicht mehr (wofür auch?).

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MarkusPohlmann:
Folgender Codeschnippsel...

...

Also dauert das umrechnen der 4Byte in 2Byte und darstellen ca. 6000 Microsekunden.

Ist leider durch die unterschiedliche Datenhaltung kein sehr brauchbarer Vergleich, oder?

Das füllen der Puffer für beide Routinen kann ich leider nicht vergleichen, bzw. der Aufwand lohnt nicht. Ist beides sehr stark im Programm verteilt und angepasst.

Die Hardware ist ein 68060er mit Mediator und Voodoo3 Graka (Picasso).

---

Naja, WritePixelArray() ist nicht gerade als Geschwindigkeitswunder bekannt (warum auch immer das so ist). Insofern ist der Vergleich nicht besonders brauchbar. Besser wäre es gewesen, das Ganze ebenfalls mit BlitBitMapRastPort() zu erledigen (was normalerweise problemlos funktionieren sollte). Das dürfte den Faktor auf <4 drücken.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MarkusPohlmann:
Ich habe keinen dieser Patches am laufen.
Den Speedtest hätte ich ja gerne auch mit 24 Bit und Bitmap gemacht, aber dazu müsste ich zuviel in dem Programm umbauen.
Wäre möglich, aber vorher diesem Thread hatte ich keine Ahnung wie und jetzt ist mir der Umbau zu umständlich.

---

Die Patchs bringen vorallem unter AGA extrem viel. Ich vermute auch mal, das es was unter CybergraphX bringt, getestet habe ich das aber noch nicht.

Wegen dem Umbau:
Bei mir ist es genau anderstherum: 24 -> 16bit (bzw. 16bit noch hinzufügen)

Allerdings hab ich jetzt schon seit Wochen nix mehr an meinem Programm gemacht...
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Ralf27:
Die Patchs bringen vorallem unter AGA extrem viel. Ich vermute auch mal, das es was unter CybergraphX bringt, getestet habe ich das aber noch nicht.

---

Hm, ich glaube, ich muß hier mal kurz einhaken

BlazeWCP patcht und beschleunigt WriteChunkyPixels() und WritePixelArray8().

WritePixelArray() (ohne 8! ) ist eine reine CGFX/P96-Funktion, die (neben den 8-Bit Modi) hauptsächlich zum einfachen Übertragen von Pixeldaten >8Bit gedacht ist. Soweit ich weiß, wird die aber nicht durch BlazeWCP() gepatcht. Vielleicht wäre da mal ein ähnlicher Patch fällig

Bisher habe ich jedenfalls immer wieder gelesen, daß diese Funktion wohl deutlich schneller sein könnte, aber leider nicht ist.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

Stimmt, du hast recht. Ich hab wohl schon zu lange nichts mehr programmiert.

Wenn ich das jetzt richtig verstanden habe, dann ist noch nicht alles in CybergraphX eingebaut was möglich wäre, bzw. teilweise sind die Funktionen etwas langsam.
Sehe ich das richtig? Aber ich denk mal das es keine Weiterentwicklung geben wird...
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]