FVDI Saga Treiber für Saga Optimieren

[tuxie]

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 .

[mfro]

...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.

[tuxie]

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..

[1ST1]

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.

[tuxie]

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.

[1ST1]

Prima, weiter machen!

[tuxie]

Kurzes Update... haben die letzten tage am fVDI Treiber gearbeitet.
Folgendes haben wir erreichen können

Original fVDI von Vincent




Modifziert




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.

[1ST1]

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?

[tuxie]

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.

[tuxie]

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.

[mfro]

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.

[1ST1]

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.

[tuxie]

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.

[tuxie]

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 ?

[mfro]

Ohne das alles ganz genau angeguckt zu haben: das hier

Code: [Auswählen]

#define EXPR_XORN(D,S) D=~(D^S)
MAKE_OP(op9,EXPR_ORN)

sieht mir stark nach einem Copy & Paste Fehler aus.

Mal mit

Code: [Auswählen]

#define EXPR_XORN(D,S) D=~(D^S)
MAKE_OP(op9,EXPR_XORN)

probieren?

[Thorsten Otto]

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.

[Arthur]

@tuxie, kannst du die Screenshots noch mal direkt auf forum.atari-home.de hoch laden? 

[Thorsten Otto]

Code: [Auswählen]

#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

Code: [Auswählen]

        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

Code: [Auswählen]

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).

[tuxie]

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.

[Thorsten Otto]

Wenn man das verhindern muss, ist aber wohl irgendwas an dessen implementation in Apollo faul Abgesehen davon, daß

Code: [Auswählen]

#define KEEP_ORDER() __asm__ volatile("" : "+m"(keep_order))

keine outputs definiert hat, und die Zugriffe deshalb komplett wegoptimiert werden.