Accelerated graphics driver, DMA, QImage and pixel buffer, Linux



  • Hallo Forum,

    Ich habe folgendes Problem. Ich soll ein Plugin schreiben wie hier http://doc.trolltech.com/4.5/qws-svgalib.html beschrieben und dabei die Funktionen blit() und solidFill() "beschleunigen". Dabei soll DMA benutzt werden und das Ganze läuft unter Linux mit 2.6er Kernel und ARM CPU. Ich habe bereits einen funktionierenden Treiber geschrieben, der DMA initialisiert und entsprechenden Kopiervorgang startet. Nun ist es so, dass der DMA Controller unabhängig von der MMU auf den physikalischen Speicher zugreift - die Pixel-Daten müssen also im Speicher schön sequentiell in einem Block stehen.
    Den Zeiger auf die Pixel-Daten bekomme ich im Plugin von einem QImage Objekt und es ist vermutlich so, dass QImage diese Pixel-Daten dynamisch mit malloc() allokiert. Im virtuellen Adressraum sind diese Daten sequentiell, physikalisch werden sie aber auf 4 kB Pages verteilt und es kommt immer vor, dass es da "Löcher" gibt, die natürlich vom DMA mitkopiert werden.
    Meine Frage wäre: Gibt es eine Möglichkeit, Qt vielleicht so zu konfigurieren, dass alle Objekte, die irgendwas mit Grafik zu tun haben, den Speicher nicht mehr dynamisch reservieren, sondern dass man denen einen Pointer auf einen Speicherbereich übergibt, den sie stattdessen benutzen sollen? Ich stelle es mir so vor, dass ich in meinem Treiber einen sequentiellen Block reserviere, auf den man in der Qt Applikation mit mmap() "mappen" könnte...
    Weiss jemand vielleicht einen anderen Trick, wie man es machen könnte?



  • es kommt immer vor, dass es da "Löcher" gibt, die natürlich vom DMA mitkopiert werden.

    Du weisst dass die Scanlines eines QImage auf 8-Byte aligned sind?

    dass alle Objekte, die irgendwas mit Grafik zu tun haben, den Speicher nicht mehr dynamisch reservieren

    Nein aber schau Dir vielleicht mal in qimage.cpp QImageData::create an.

    Sind denn wirklich alle Objekte relevant?
    Haeufig hat man doch nur wenige grosse Bilder die davon profitieren.
    Fuer die kann man das QImage ja mit selbstalloziertem Speicher erstellen.



  • hellihjb schrieb:

    Du weisst dass die Scanlines eines QImage auf 8-Byte aligned sind?

    Ja, "pagealigned" (4096 Byte) wäre besser 😉

    hellihjb schrieb:

    Sind denn wirklich alle Objekte relevant? Haeufig hat man doch nur wenige grosse Bilder die davon profitieren.

    Ich weiss nicht genau, wie viele Objekte es sein sollen, war bloss ein Gedanke von mir.
    Habe gerade mit Kollegen gesprochen und es soll so sein, dass mein Plugin im Prinzip nichts von der Applikation wissen sollte...
    Die Applikationen selbst werden dann so gestartet, z.B.:

    ./demos/deform/deform -qws -display mygagaplugin

    Und mygagaplugin ist laut file

    > file /opt/qt-embedded-linux-4.5.1_armv6/plugins/gfxdrivers/libmygagaplugin.so
    /opt/qt-embedded-linux-4.5.1_armv6/plugins/gfxdrivers/libmygagaplugin.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, stripped


Anmelden zum Antworten