Was im RAM des TT passiert, das soll eine GK behindern? Das glaubst Du doch wohl selber nicht. Was sollen diese Verwirrspiele, Thorsten?
Klar ist außerdem, daß aus KompatibilitätsGründen nicht das VDI im TT durch Handles erweitert werden kann - wohl aber wäre das lokal im BeePi möglich.
-------
Ich möchte den Fokus noch mal auf die Ü-Rate im VME-Bus lenken.
Meine CrazyDots kann zB. 1024x768x8@60; wie man leicht nachrechnet, bedeutet dies, daß über den VGA-Port 45MB/sec gehen. Eine Nova kann noch viel mehr. Es ist inzwischwen völlig klar, daß diese DatenMengen nicht auch über den VME-Bus gehen können. Das RAM dieser GKs wird also vom TT _wesentlich_ langsamer befüllt. Leider habe ich trotz einiger Suche keine Zahlen dafür gefunden. Oben in #12 hat
@czietz dunkel geraunt "Im MegaSTE und TT deutlich weniger als 20MB/s". Würde mich mal interessieren, was CratzDots & Nova tatsächlich über den VME-Bus schaufeln... Wenn die Leistung der GPIO am RPi zu gering ist (lt. Chocco immerhin max. 5MB/s), wie
@tuxie in #1 meint, und ich andererseits sehe, daß die Lightning_VME nicht einmal 1MB/s macht, dann paßt da irgendetwas nicht so recht zusammen...
Kurz, ich halte dafür, daß auch ohne den oben skizzierten Trick eines VDI-Terminals eine GK auf Basis des RPi möglich ist. Und wenn der RPi die Daten vom VME-Bus erst einmal übernommen hat, dann sollte es auch gelingen, sie an dessen (BeePi-) eigenen ScreenTreiber weiterzuleiten. Und die Leistung einer solchen GK sollte die der Nova deutlich übertreffen.
PS: Die Argumente in diesem Posting wurden vorgetragen, um den Einwand eines zu langsamen Transfers zum und vom RPi zu widerlegen. Es ist nicht gemeint, auf den Gedanken eines VDI-Terminals oder noch besser eines VDI-Coprozessors zu verzichten.