atari-home.de - Foren
Software => Coding => Thema gestartet von: tuxie am Mo 26.03.2018, 14:36:52
-
Wie viele mitbekommen haben Arbeiten wir aktuell an der Vampire für den ST. Die Realisierung ist voll im gange. Biggun hat mich angefragt ob wir den Treiber den Vincent für den Saga Core geschrieben hat zu optimieren.
Der Treiber speichert den Inhalt der an die Grafikkarte geschrieben wird mehrmals durch memorymove hin und her. Was dazu führt das alles langsam ist. Wenn man diesen Optimieren würde und einige Routinen direkt in Assembler durchführen würden könnte man die Geschwindigeit mindestens verdoppeln.
Infos gibt es auch hier
http://wiki.apollo-accelerators.com/doku.php/start?do=search&id=saga
Treiber von Vincent
https://github.com/vinriviere/fvdi/tree/master/fvdi
Jetzt ist die Frage könnte sich dies jemand mit anschauen ? Eventuell jemand der fvdi kennt und weiß wie es Arbeitet .
-
...Der Treiber speichert den Inhalt der an die Grafikkarte geschrieben wird mehrmals durch memorymove hin und her ...
Der Treiber wurde ursprünglich für den Falcon mit CT60 geschrieben und hat deshalb einen Backbuffer. Jede Bildschirmveränderung wird in einer FastRAM-Kopie mitgeschrieben (ein Pixel setzen setzt also zwei, eins auf dem Schirm und eins auf dem Backbuffer). Bei Falcon + CT60 ist das eine Beschleunigung (weil der Zugriff auf den Backbuffer im Vergleich zu einem Zugriff auf den "echten" Bildschirmspeicher bei Rasterkopien fast nichts kostet).
Der Backbuffer ist über Präprozessor-Definitionen in fvdi/fvdi/drivers/16_bit/16b_blit.c konfiguriert. Einfach das '#if 1' ganz am Anfang der Datei in '#if 0' ändern und neu kompilieren müsste eigentlich ausreichen.
-
Vielen Dank schon mal für den Hinweis. Bei dem Saga core ist es ja so das kein Externer Bus benutzt wird und wir mit 600Mb/s lesen und schreiben können. Beim debuggen direkt im Core ist halt aufgefallen das er nicht optimal Arbeitet und verschiedene Dinge mehrmals schreibt und liest.
Habe die besagte stelle gefunden, werde dies mal umbauen und neu kompilieren. Es gibt halt viele Assemblerroutinen für z.b. standard Funktionen wie clearen, Flächen füllen. Die man da einbauen könnte..
-
Läuft die Vampire denn schon rudimentär in einem ST-Board? Im Apollo-Forum wasr ja zu lesen, dass die nächste Core-Versions-Veröffentlichung schon das Atari-Hardware-Mapping beherrschen soll.
-
Wir Arbeiten hart daran, aktuell stöbert er noch über den Bus Error. Der Saga Treiber hat nun auch schon Optimierung erfahren, memory performance ist auf das fast 2fache gestiegen.
Siehe Blitting
https://usercontent.irccloud-cdn.com/file/6RFiIoIp/IMG_6301.JPG
https://usercontent.irccloud-cdn.com/file/WnIqh33p/IMG_6303.JPG
Aktuell bei 310% gegenüber Falcon SuperVidel... die anderen Funktionen sind noch nicht im Treiber implementiert.
-
Prima, weiter machen!
-
Kurzes Update... haben die letzten tage am fVDI Treiber gearbeitet.
Folgendes haben wir erreichen können
Original fVDI von Vincent
(https://usercontent.irccloud-cdn.com/file/i0AsfN4V/irccloudcapture-1534434408.jpg)
(https://usercontent.irccloud-cdn.com/file/DcF7WmxX/irccloudcapture-661499295.jpg)
(https://usercontent.irccloud-cdn.com/file/dn4Yp155/irccloudcapture-529362476.jpg)
Modifziert
(https://usercontent.irccloud-cdn.com/file/4jdEefBO/irccloudcapture119059402.jpg)
(https://usercontent.irccloud-cdn.com/file/uov7w4Bf/irccloudcapture-1357950332.jpg)
(https://usercontent.irccloud-cdn.com/file/pGqpZv2B/irccloudcapture35915123.jpg)
Da haben wir bisher nur die Blit routinen durch optimierten Assembler code getauscht. Für viele Funktionen gibt es Hardware funktionen im Saga Core die noch eingebaut werden müssen. Was sicherlich in den nächsten Tagen geschieht.
Sobald der Atari ST mit der Vampire Hochfährt ist der Treiber einsatzbereit.Wo ich sogar denke das der ST noch mehr schaft da der Amiga nur mit 7,09 Mhz taktet und die Vampire den Bustakt als Basistakt verwendet um einen eigenen Takt zu erzeugen. Einstellbar von X5-X15 Wobei das von dem FPGA abhängig ist ob Stabil oder nicht.
-
Das ist schon toll. Das scheint aber noch ein Apollo-Core ohne Hardware-FPU zu sein. Gibts ja schon, ist halt ein Platzproblem im FPGA auf der Vampire V600. Ist erst mit Vampire V4 lösbar.
Startet eigentlich die selbe Vampire-Platine im Amiga und ST (gut, da bombts momentan noch), oder ist dafür eine unterschiedliche Konfiguration der Vampire-Karte notwendig?
-
Du solltest eventuell mal deinen Cache leeren weil auf meinen Bildern wurde gar kein CPU und FPU Benchmark gemacht sondern rein VDI und Memory.. aber kann ja sein das du andere Bilder hast. Und nein die FPU wird voll Unterstützt.
-
Wäre den keiner der Programmierer unter uns bereit mal mit in den Chat zu kommen um sich gewisse dinge mit anzuschauen und tips zu geben wo wir ansetzen können ? Die Amiga Jungs bauen für UNS die Treiber damit diese dann auf dem Atari laufen mit Vampire.... es würde schon viel helfen wenn wir einfach Tips bekommen könnten wo wir ansetzen können.
-
Wäre den keiner der Programmierer unter uns bereit mal mit in den Chat zu kommen um sich gewisse dinge mit anzuschauen und tips zu geben wo wir ansetzen können ? Die Amiga Jungs bauen für UNS die Treiber damit diese dann auf dem Atari laufen mit Vampire.... es würde schon viel helfen wenn wir einfach Tips bekommen könnten wo wir ansetzen können.
Das kann man schon machen, aber wär's nicht sinnvoller, das Ding erst mal ans Fliegen zu bekommen und hinterher zu optimieren?
Bislang hat man viele Benchmarks zu Gesicht bekommen, aber (zumindest, soweit ich verstanden habe) noch keinen "echten Atari" mit der Vampire.
-
Die SAGA-Optimierung kann ja auch schon auf Amiga parallel erfolgen. Es muss nur sichergestellt werden, dass durch die Treiberoptimierung die Hardwareanpassung nicht zu kurz kommt, sprich, dass das nicht die selben Leute machen.
-
Die ganzen Amiganer sind hoch Motiviert alles sauber ans laufen zu bekommen, haben alles erdenkliche ins System integriert. Alles vorbereitet das sobald die Vampire im ST startet das alles gleich läuft.
-
Ich bräuchte hier nochmal Unterstützung von einen unserer C Geeks,
eine aus dem Apollo Core Team hat die 16bit Blitting Routinen neu geschrieben. Es funktioniert soweit das ein Bild angezeigt wird und auch so im Tos normal etwas gemacht werden kann. Immer dann wenn Inhalte Kopiert werden sieht es so aus also ob ein Offset nicht stimmt, also die Daten an falsche Bereiche kopiert werden.
Das sieht dann so aus
https://usercontent.irccloud-cdn.com/file/c4wuSCvc/1552071156.JPG
Und beim Kronos Benchmark wenn die Nette Frau gespiegelt wird, passiert es wie im Video.
https://usercontent.irccloud-cdn.com/file/nHmto9Sd/IMG_1814.MP4
Und hier der Code
https://paste.ofcode.org/34MDBRNzPsuGvEqnyCw2vZM
Vielleicht hat jemand einmal die Zeit und Lust sich das mal mit anzuschauen ?
-
Ohne das alles ganz genau angeguckt zu haben: das hier
#define EXPR_XORN(D,S) D=~(D^S)
MAKE_OP(op9,EXPR_ORN)
sieht mir stark nach einem Copy & Paste Fehler aus.
Mal mit
#define EXPR_XORN(D,S) D=~(D^S)
MAKE_OP(op9,EXPR_XORN)
probieren?
-
Würde auch helfen zu wissen welcher code vorher verwendet wurde, der ja scheinbar funktioniert hat.
Ist das der aus 16b/16b_blit.c?
Was auch suspekt aussieht ist der merkwürdige Zugriff auf keep_order. Da dort kein asm-code vewendet wird scheint mir der unnötig, ganz abgesehen davon daß man das auch mit __asm__ __volatile__ verhindern könnte.
-
@tuxie, kannst du die Screenshots noch mal direkt auf forum.atari-home.de hoch laden?
-
#define EXPR_OP15(D,S) D=-1U
MAKE_OP(op15,EXPR_OP15)
Funktioniert so sieht. Da der Treiber mit -mshort (hoffentlich) übersetzt wird, macht gcc daraus
move.l #65535,(%a0)
move.l #65535,4(%a0)
move.l #65535,8(%a0)
move.l #65535,12(%a0)
Davon abgesehen ist die Deklaration von
typedef uint32_t (*blit)(PIXEL*,int32_t,PIXEL *,int32_t,int16_t,int16_t);
falsch, und müsste als void deklariert werden (erzeugt aber vermutlich keine Fehler, nur jede Menge Warnungen).
-
Würde auch helfen zu wissen welcher code vorher verwendet wurde, der ja scheinbar funktioniert hat.
Ist das der aus 16b/16b_blit.c?
Was auch suspekt aussieht ist der merkwürdige Zugriff auf keep_order. Da dort kein asm-code vewendet wird scheint mir der unnötig, ganz abgesehen davon daß man das auch mit __asm__ __volatile__ verhindern könnte.
Dies ist ein Trick um out of order execution daran zu hintern die Reihenfolge der Abarbeitung zu ändern.. zumindest wird es so bei den Amiganern genutzt.
-
Wenn man das verhindern muss, ist aber wohl irgendwas an dessen implementation in Apollo faul ;) Abgesehen davon, daß
#define KEEP_ORDER() __asm__ volatile("" : "+m"(keep_order))
keine outputs definiert hat, und die Zugriffe deshalb komplett wegoptimiert werden.
-
wenn das eine "memory barrier" sein soll, würde ich das so schreiben:
__asm__ __volatile__("" ::: "memory");
Aber nur, wenn es tatsächlich gebraucht wird - schließlich hindert das gcc ja am Optimieren.
-
Das würde wohl nichts nutzen, weil gcc nichts von nötigen memory barriers für m68k weiss, und das genauso ignoriert würde. Wenn überhaupt, müsste man wohl einfach
#define KEEP_ORDER() (void)keep_order
verwenden.
Abgesehen davon, die bisherigen Änderungen könnten den Fehler beim Bild-Spiegeln erklären, aber noch nicht die merkwürdigen Effekte in der Menüzeile. Müsste man aber wohl erstmal ausprobieren.
-
Das würde wohl nichts nutzen, weil gcc nichts von nötigen memory barriers für m68k weiss, und das genauso ignoriert würde.
Das muss es doch auch nicht. Das Statement oben bedeutet m.E. für den gcc, daß da asm-Code eingestreut wurde, der Hauptspeicher geändert hat.
Alles, was danach kommt, muß demzufolge seine Register neu laden, alles was davor kommt, sie zurückschreiben -> memory barrier.
-
Ist das schon auf "unserer" Hardware, oder noch drüben?
-
@tuxie, kannst du die Screenshots noch mal direkt auf forum.atari-home.de hoch laden?
Ingo, ich schieb hier mal ein wenig.
-
Habe nur den einen und den habe ich angehaengt!
-
@mfro: memory-barrier sind was anderes als out-of-order execution. Ersteres wird z.B. benötigt um sicherzustellen, daß Variablen die zur thread-synchronisation benutzt werden, tatsächlich im Speicher stehen. Letzteres ist was, was lediglich die CPU betrifft. Da sowohl mit dem bisherigen Konstrukt und mit deinem Vorschlag (oder auch wenn man es ganz weglässt) der gleiche Code erzeugt wird, kann es hier allerdings keinen Effekt haben. Es gibt lediglich einen Unterschied: wenn man es ganz weglässt, wird tatsächlich die Funktion für EXPR_NOP komplett wegoptimiert. Wenn man eines der Konstrukte benutzt, besteht die aus Schleifen die absolut keinen Effekt haben, weil sie weder Speicher lesen noch schreiben.
@tuxie: welchen Compiler verwendet ihr denn bzw. die Amiga-Leute? ich weiss daß Beppo da schon was Richtung Apollo-Code-Erzeugung gemacht hat, aber ist das auch schon im Einsatz?
-
Mal nebenbei: Vielleicht kann @Chocco euch noch helfen? Der schreibt zur Zeit ein VDI für Linux/ARM. ;D
-
@mfro: memory-barrier sind was anderes als out-of-order execution.
Natürlich.
Mit letzerem werden m68k-Compiler (und erst recht "Legacy"-Code) schlicht nicht umgehen können. M.E. darf der Apollo-Core so etwas nur dann machen, wenn es keine Auswirkungen auf das Ergebnis hat.
M.W. macht auch ein 68060 - obwohl er "die Kraft der zwei Pipelines" hat - immer in-order. ColdFire genauso.
-
Ich nutze aktuell den Compiler von Vincent auf meinem MacBook, hatte jetzt versucht den GCC 8 von Thorsten einzurichten, es fehlt allerdings noch ein Paket ein -as fehlt. Habe aber gestern Abend dann nicht weiter geschaut.
Die nonarkitten aus dem Apollo Team die auch die Blit Routinen geschrieben hat, hat mir auch schon gesagt das Beppos Compiler den 68080 bereits Unterstützt. Nur die Frage wie man ihn am besten einbinden könnte.
-
Hab ihn eben gefunden, er hat ihn auf Github
https://github.com/bebbo/amiga-gcc
-
es fehlt allerdings noch ein Paket ein -as fehlt.
Der Assembler? Sollte eigentlich bei den binutils dabei sein (ist es auch wenn ich nachschaue). Zur Not müssten aber auch die binutils-2.30 von Vincent funktionieren.
[quoteNur die Frage wie man ihn am besten einbinden könnte.[/quote]
Hauptproblem ist vermutlich, daß er momentan noch vasm verwendet, und gas noch nicht die opcodes versteht.
-
Schaue ich heute Abend, bin Arbeiten und habe heute meinen Rechner nicht mit.
-
Mal nebenbei: Vielleicht kann @Chocco euch noch helfen? Der schreibt zur Zeit ein VDI für Linux/ARM. ;D
Nein, das passt leider nicht ganz. Für den ARM-Port habe ich mich inzwischen vom Framebuffer getrennt und nutze openvg mit HW-Beschleunigung.
Augenscheinlich würde ich auf vro_cpyfm() tippen, wenn sowohl SCR- als auch DST-Raster im aktuellen Bildspeicher liegen. In diesem Fall wird NULL als Zeiger auf das Raster gesetzt und vielleicht werden die MFDB-Strukturen mit inkorrekten Default-Werten belegt.
-
Wie ist den da eigentlich der Status bei deinem Port ?
-
Wie ist den da eigentlich der Status bei deinem Port ?
Das ist noch eine große Baustelle. Dazu mache ich mal einen extra Thread zu auf.