png nutzt z.B. zlib für die verlustfreie kompression und wenn du ein reader hast, dann rate ich zu dem format.
Wenn deine Bilder immer 24Bit farbtiefe haben, dann kannst du die Bilddaten direkt in OpenGL verwenden.
Du willst doch aber noch die einzelnen Bitebenen und da verstehe ich noch nicht wieso.
Im Prinzip läuft es so ab, man erstellt eine Textur von der benötigten größe und stellt ein puffer, wo man das nächste Datenpaket reinlegt.
Wenn du das 24Bit bild direkt nehmen würdest, dann wäre der Speicherbereich, den z.B. png für die Daten nimmt, dein Puffer.
Sobald der Puffer fertig geschrieben ist und es Zeit ist zu swappen, dann wird das Bild in die Textur kopiert, sonnst wird keine änderung an der Textur vollzogen.

Das Problem ist halt das Verständnis mit den einzelnen Bitebenen.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Also ich bin gerne bereit es genauer zu erklären, ich hoffe das bringt nicht mehr Verwirrung

0. Es soll ein Hologramfilm belichtet werden.
1. Die Bilder sind Steuersignale
2. Mit jedem Bild werden 24Pixel belichtet, d.h. eine Bitebene enthält die Steuersignale für ein Pixel.
3. Die Maschine führt einen Laser über den Film, hier sind die 40Hz wichtig, damit jeder Pixel an der richtigen Stelle belichtet wird. Diese geschieht Zeilenweise danach geht der Genlock kurz aus und wartet bis die neue Zeile erreicht wird.

Also glCompressedTexSubImage wird vermutlich raus fallen, denn dabei ist nur DXT gemeint. Was aber Aufgrund der doch starken Verluste einfach nicht zu gebrauchen ist. glTexSubImage2D ist vermutlich eher der Kandidat der gesucht wird.

Generell sehe ich das Hochladen da auch eher unkritisch. Allerdings deine Anwendung besteht doch in erster Linie "nur" aus dem Hochladen von den Bildern, oder? Wenn ja, dann würde ich sagen darf der Cache ruhig auch etwas größer ausfallen. Da du auf Performace angewiesen bist kann jede kleine Störung zu einem Abreißen des Datenstroms führen. Und das muss ein Buffer auffangen können. Mit 25ms Buffer ist das vermutlich kaum zu gewährleisten.

Das Laden der Dateien würde ich in einem seperaten Thread machen. Nur einer, denn zwei+ würden sich vermutlich beim Lesen selber ausbremsen. Evtl ist es sogar empfehlenswert in einem Thread die Dateien komplett in einem Stück in den Speicher zu laden und sie in anderen Threads zu dekodieren. Denn dann hättest du nur einen Zugriff pro Datei und der Thread wäre nur mit Lesen der Dateien beschäftigt, wärend ein oder mehrere andere Threads sie nur dekodieren. Damit könntest du die Last des Dekodierens auf 1-4 Prozessoren verteilen und das Lesen der Festplatte müsste nicht auf das Dekodieren warten und umgekehrt. Die fertig geladenen Daten (nur die Pointer) könntest du dann cachen und bei Bedarf weiterreichen und hochladen.

Wenn du mit pascal arbeitet kann ich dir folgenden header anbieten um PNGs zu lesen. Der benutzt die Referenzbibliothek von PNGs und ist entsprechend schnell. Bei C++ kannst du die Bibliothek direkt nutzen.

Zum Hochladen entweder mit glTexSubImage2D. Oder aber du könntest evtl. auch PixelBufferObjects benutzen. Das ist ein Speicherbereich der in den RAM gemappt werden kann und denn könntest du in aller Ruhe (auch in anderen Threads) befüllen. Wenn der Buffer entmappt wurde, dann können die Daten zum GRAM und anschließend in die Textur übertragen werden. Das passiert dann nur auf der Grafikkarte via DMA und sollte asynchron geschehen wodurch die CPU nicht blockiert wird. Bei glTexSubImage2D muss die CPU blockiert werden, da nur für den Aufruf der übergebene Buffer gültig ist. Auch wenn das vermutlich nur eine Millisekunde dauern würde.

Ich würde da sogar mehr als eine Textur empfehlen, denn du hast nur einen Stream und wenn du da 10 Texturen hast, dann sind das 12 MB. Das ist auch noch keine wirkliche Größenordnung. Bei nur 2 Texturen wäre das zur Verfügung stehende Zeitfenster in der die Textur übertragen werden könnte auch nicht gerade sonderlich groß.

PS: Evtl kann auch die Reihenfolge beim Übertragen einen entscheidenden Vorteil bringen bzw eine Falsche auch ausbremsen.

Das selektieren einer datei im fs dauert in etwa 2-4ms, drum sagte ich ja, pack alle files in eine datei, damit fallen pro bild 2-4ms weniger zeitverlust an.
Mit dem Thread würde ich dies auch lösen, ein Thread, der die file in den cache liest und je nach bildformat entpackt/encodiert.
Der Hauptprozess holt sich dann nur noch aus dem Cache das benötigte Bild und makiert es als gelesen.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004