Bildwiederholspeicher

Der Bildspeicher bzw. Framebuffer (engl. frame – Einzelbild, buffer – Puffer) ist Teil des Video-RAM von Computern und entspricht einer digitalen Kopie des Monitorbildes. Das heißt, jedem Bildschirmpixel kann genau ein bestimmter Bereich des Framebuffers zugewiesen werden, der dessen digital übersetzten Farbwert enthält. Seit den 90er-Jahren befindet sich der Framebuffer vorwiegend auf der Grafikkarte.

Speicherbedarf

Die Größe des Framebuffers ist abhängig von zwei Faktoren: die verwendete Farbtiefe (genauer: Pixelformat) und die verwendete Bildauflösung.

Farbtiefe

Die Farbtiefe des Framebuffers definiert die Maximalzahl der gleichzeitig auf dem Bildschirm angezeigten Farben. Die angegebenen Pixelformate geben an, wie viele Bits pro Pixel auf die einzelnen Farbkanäle (rot, grün, blau, alpha) vergeben wird - bei Farbmodi, die Paletten benutzen, fehlt diese Angabe, weil sie keinen Sinn ergibt.

• 1 Bit pro Pixel
  • MDA
  • zwei Farben
• 2 Bit pro Pixel
  • CGA
  • vier Farben aus einer Palette mit 16 Farben
• 4 Bit pro Pixel
  • EGA
  • 16 Farben aus einer Palette mit 64 Farben
• 8 Bit pro Pixel
  • VGA
  • 256 Farben aus einer Palette mit 262144 Farben
• 15 Bit pro Pixel
  • Real Color
  • 32768 Farben
  • Pixelformat 5-5-5, d. h. 5 Bit pro Farbkanal (also 32 Farbabstufungen pro Kanal)
• 16 Bit pro Pixel
  • High Color
  • 65536 Farben
  • Pixelformat 5-6-5, d. h. 5 Bit für Rot und Blau (32 Farbabstufungen) und 6 Bit für Grün (64 Farbabstufungen)
  • alternativ auch 4-4-4-4, d. h. 4 Bit pro Farbkanal (16 Farbabstufungen), wobei die letzten vier Bits entweder ungenutzt sind oder als Alphakanal verwendet werden (s. 32 Bit True Color)
• 24 Bit pro Pixel
  • True Color
  • 16777216 Farben
  • Pixelformat 8-8-8, d. h. 8 Bit pro Farbkanal (256 Farbabstufungen)
• 32 Bit pro Pixel
  • True Color
  • Pixelformat 8-8-8-8, d. h. 8 Bit pro Farbkanal (256 Farbabstufungen)
  • Die gegenüber 24 Bit True Color hinzugekommenen 8 Bit werden normalerweise nicht genutzt; auf Rechnern mit 32-Bit-Architektur ist die Verarbeitung von 32-Bit-Werten aber effizienter als die von 24-Bit-Werten, weil dies genau der Wortbreite des Prozessors entspricht, weswegen trotz des 33% höheren Speicherbedarfs True-Color-Framebuffer meistens 32 Bit Farbtiefe benutzen.

In der 3D-Computergrafik werden auch Framebuffer mit höherer Genauigkeit benutzt. Dort benötigt die Bestimmung der Farbe eines Pixels oftmals mehrere Rechenschritte, wobei bei jedem Zwischenergebnis Rundungsfehler entstehen können, die bei herkömmlichen Framebufferformaten schnell sichtbar sind und störend wirken.

Bei diesen genaueren Formaten interpretiert man die Farbkanalwerte als Kommawerte auf einer Skala von 0.0 bis 1.0, damit bei der Verwendung mehrerer Pixelformate die Handhabung vereinfacht wird.

• FX8
  • pro Farbkanal 8 Bit Festkomma, somit 256 Farbabstufungen linear skaliert
  • identisch mit oben genannten 32 Bit pro Pixel. Ob man die 256 verschiedenen Werte pro Farbkanal als ganze Zahl zwischen 0 bis 255 oder als Festkommawert zwischen 0.0 und 1.0 ($\frac{wert}{255}$) auffasst, ist lediglich Interpretationssache.
  • maximaler Kontrast 255:1, daher geeignet für Low Dynamic Range (LDR) Rendering, wie es gewöhnliche Bildschirme aller Art anzeigen können
• FX12
  • pro Farbkanal 12 Bit Festkomma, somit 4096 Farbabstufungen linear skaliert
  • höhere Genauigkeit als FX8
  • maximaler Kontrast 4095:1, geeignet für Low Dynamic Range (LDR) Rendering
• FX16
  • pro Farbkanal 16 Bit Festkomma, somit 65536 Farbabstufungen linear skaliert
  • höhere Genauigkeit als FX12
  • maximaler Kontrast 65535:1, geeignet für Medium Dynamic Range (MDR) Rendering
• FP16
  • pro Farbkanal 16 Bit Gleitkomma (davon 5 Bit Exponent und 10 Bit Mantisse), somit 32768 Farbabstufungen exponentiell skaliert
  • Die exponentielle Skala erlaubt im Vergleich zu FX16 eine wesentlich feinere Auflösung bei kleinen Werten, bei größeren Werten ist es aber ungenauer.
  • maximaler Kontrast ca. 10¹²:1, geeignet für High Dynamic Range (HDR) Rendering.
• FP24
  • pro Farbkanal 24 Bit Gleitkomma (davon 7 Bit Exponent und 16 Bit Mantisse), somit mehr als 8 Mio. Farbabstufungen exponentiell skaliert
  • höhere Genauigkeit als FP16 (max. Kontrast ca. 10⁴³:1), daher sehr gut geeignet für HDR-Rendering
• FP32
  • pro Farbkanal 32 Bit Gleitkomma (davon 8 Bit Exponent und 23 Bit Mantisse), somit mehr als 2 Mrd. Farbabstufungen exponentiell skaliert
  • noch höhere Genauigkeit als FP24 (max. Kontrast ca. 10⁸³:1)

Bildauflösung

Die Bildauflösung gibt an, aus wie vielen Pixeln der Framebuffer besteht. Üblicherweise gibt man hierbei die horizontale und vertikale Pixelanzahl an, wodurch man auch das Seitenverhältnis direkt berechnen kann, üblich sind hier 4:3, 5:4 und 16:10.

Typische Framebuffer-Auflösung:

• 640 × 480: 307200 Pixel, Seitenverhältnis 4:3
• 800 × 600: 480000 Pixel, Seitenverhältnis 4:3
• 1024 × 768: 786432 Pixel, Seitenverhältnis 4:3
• 1280 × 1024: 1,31 Mio. Pixel, Seitenverhältnis 5:4
• 1680 × 1050: 1,76 Mio. Pixel, Seitenverhältnis 16:10
• 1600 × 1200: 1,92 Mio. Pixel, Seitenverhältnis 4:3
• 1920 × 1200: 2,3 Mio. Pixel, Seitenverhältnis 16:10
• 2048 × 1536: 3,15 Mio. Pixel, Seitenverhältnis 4:3
• 2560 × 1600: 4,10 Mio. Pixel, Seitenverhältnis 16:10

Beispiele

• Textmodus (z. B. beim Hochfahren eines IBM-kompatiblen PCs oder im Konsolenmodus unter Linux)
  Bei einer 80 × 25 Zeichen großen Konsole, wobei jedes Zeichen und seine Farbe mit jeweils 8 Bit (also zusammen 16 Bit) gespeichert wird, belegt der Framebuffer 80 × 25 × 16 = 32000 Bit = 4 KB.
• Grafikmodus (z. B. unter Microsoft Windows oder beim X Window System unter Linux)
  Bei einer Bildschirmauflösung von 1024 x 768 Pixel und einer Farbtiefe von 24 Bit belegt der Framebuffer 1024 × 768 × 24 = 18874368 Bit = 2,25 MB.

Breite × Höhe × Farben	Speicherbedarf[1]	Standard
320 × 200 × 2	≈ 8 KB (8 kB)	C64
640 × 200 × 2	≈ 16 KB (16 kB)	CGA
750 × 350 × 2	≈ 32 KB	Hercules
640 × 350 × 16	≈ 109 KB (112 kB)	EGA
640 × 480 × 16	150 KB	VGA
320 × 200 × 256	62,5 KB (64 kB)	VGA
640 × 480 × 256	300 KB	VGA-extended
800 × 600 × 256	468,75 KB (480 kB)	SVGA
1024 × 768 × 256	768 KB	XGA
1024 × 768 × 64k	1,5 MB	XGA
1024 × 768 × TrueColor	2,25 MB	XGA
1280 × 960 × TrueColor	≈ 3,5 MB	SXGA
1400 × 1050 × TrueColor	≈ 4,2 MB	SXGA+
1600 × 1200 × TrueColor	≈ 5,5 MB	UXGA
1920 × 1200 × TrueColor	≈ 6,6 MB	WUXGA
2048 × 1536 × TrueColor	9 MB	SUXGA
2560 × 960 × TrueColor	≈ 7 MB	Dual SXGA
2560 × 1600 × TrueColor	≈ 12 MB	QWXGA/WQXGA

In der Übersicht wurde im Fall von TrueColor berücksichtigt, dass Daten intern mit 24 Bit gespeichert werden.

Verbesserungen

Durch Unzulänglichkeiten in der Kontinuität der Bildfolge, und um die allgemeine Darstellungsqualität weiter zu erhöhen, wurde das Konzept des Framebuffers im Laufe der Zeit überarbeitet. So entspricht ein Framebuffer auf aktuellen Systemen mehreren Pufferspeichern.

• Bei der Doppelpufferung (double buffering) wird der Framebuffer in zwei Bereiche (Frontbuffer und Backbuffer) unterteilt.
• Bei der Dreifachpufferung (triple buffering) wird der Framebuffer in drei Bereiche (1 Frontbuffer und 2 Backbuffer) unterteilt.

Linux-Framebuffer

Das Linux Framebuffer Device (kurz fbdev) ist eine hardwareunabhängige Abstraktionsschicht unter Linux, um Grafiken auf der Konsole bzw. mit X-Window (xf86_fbdev) anzuzeigen. Dabei setzt das Framebuffer-Device nicht auf systemspezifischen Bibliotheken wie der SVGALib oder dem X Window System auf und ist somit eine ressourcensparende Alternative zum weiterverbreiten X-Server, auf dem heute die meisten grafischen Oberflächen für Linux aufbauen. Es ist seit der Linux-Kernelversion 2.1.107 für alle Plattformen im Standardkernel enthalten.

Ursprünglich wurde es für Linux/m68k implementiert, um auf entsprechenden Systemen (Amiga, Atari, Macintosh) mit einer geringen Hardwarebeschleunigung eine Textkonsole zu emulieren und wurde erst später auf die IBM-PC-kompatible Plattform erweitert.

Heutzutage kann der Framebuffer direkt von verschiedenen Programmen wie MPlayer und Bibliotheken wie GGI, SDL, GTK+ und Qt Extended benutzt werden. Das ressourcensparende Konzept macht den Einsatz besonders für eingebettete Systeme interessant.

Insbesondere wird es von verschiedenen Betriebssystemen (Ubuntu, openSUSE) verwendet, um schon während des Bootstrapping in Form eines Splash Screens eine grafische Ausgabe zu ermöglichen.

Der am häufigsten verwendete VESA-Framebuffer-Treiber (vesafb) baut auf einheitlichen Spezifikationen von Videostandards auf und erlaubt so einen Zugriff auf Grafikkarten größtenteils unabhängig vom Hersteller. Dadurch ist dann auch eine quelloffene Implementation möglich. Außerdem wurden von diversen Grafikchipherstellern (Nvidia: rivafb, nvidiafb; AMD: radeonfb) proprietäre Treiber auf den Markt gebracht.

Bekannt wurde das Framebuffer-Device durch die Möglichkeit, während des Linux-Kernel-Ladevorgangs dem Benutzer ein Tux-Logo anzuzeigen. Dazu muss es aber zunächst im Kernel enthalten sein und beim nächsten Reboot durch den Boot-Loader, der auch das Betriebssystem in den Arbeitsspeicher lädt, durch die Angabe des Paramenters video aktiviert werden.

Im Folgenden werden zwei Beispiele gezeigt, indem ein AMD-Treiber mit einer Bildauflösung von 1024×768 Bildpunkten bei einer Farbtiefe von 8 Bit pro Pixel und einer Bildwiederholungsfrequenz von 76 Hz geladen wird:

Beispiel für eine LILO Konfigurationsdatei

# LILO configuration file
boot = /dev/sda1
# Linux bootable partition config begins
image = /vmlinuz
append = "video=atyfb:1024x768-8@76,font:SUN8x16"

Beispiel für eine GRUB Konfigurationsdatei

# GRUB configuration file
# For booting LINUX
title Linux
kernel (hd0, 0) /vmlinuz video=atyfb:1024x768-8@76,font:SUN8x16 root=/dev/hda1

Für einen Hardwarezugriff auf das Framebuffer-Device muss nicht unbedingt ein Kernelmodul geschrieben werden. Ferner hat die Anwendung die Möglichkeit im User-Mode über die Gerätedatei /dev/fb* auf das Device zuzugreifen und in den Grafikspeicher zu schreiben. In folgendem Beispiel wird demonstriert, wie mit der Programmiersprache C linear in den Framebuffer geschrieben werden kann. Hier wird der hexadezimale Wert 0x01 (Binär: 0b00000001) für jedes Pixel gesetzt:

#include <sys/types.h>
#include <sys/stat.h>
#include <sys/mman.h>
#include <sys/ioctl.h>
#include <fcntl.h>
#include <linux/fb.h>
#include <unistd.h>
 
int main(int argc, char **argv) {
   int row, col, width, height;
   unsigned char *data;
 
   // Oeffnen des Geraetes
   int fd = open("/dev/fb0", O_RDWR);
 
   // Informationen ueber den Framebuffer einholen
   struct fb_var_screeninfo screeninfo;   
   ioctl(fd, FBIOGET_VSCREENINFO, &screeninfo);
 
   if(screeninfo.bits_per_pixel != 8) return 0;
   width  = screeninfo.xres;
   height = screeninfo.yres;
 
   // Zeiger auf den Framebufferspeicher anfordern
   data = (unsigned char*) mmap(0, width * height, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
 
   // in den Framebuffer-Speicher schreiben. Hier wird Pixel fuer Pixel auf 
   // die Farbe 0x01 gesetzt   
   for(row = 0; row < height; row++) 
     for(col = 0; col < width; col++) 
        data[row * width + col] = 0x01;
 
   // Zeiger wieder freigeben
   munmap(data, width * height);
}

Referenzen

1. ↑ hier: 1 KB = 1024 Byte und 1kB = 1000 Byte