Framebuffer

El búfer de fotogramas o memoria de imágenes ( fotograma inglés - imagen única, búfer - almacenamiento intermedio) es parte de la memoria gráfica de las computadoras y corresponde a una copia digital de la imagen del monitor . Esto significa que a cada píxel de la pantalla se le puede asignar un área específica del búfer de fotogramas que contiene su valor de color traducido digitalmente. Desde la década de 1990, el framebuffer se ha ubicado principalmente en la tarjeta gráfica .

Requisitos de memoria

El tamaño mínimo requerido del búfer de fotogramas depende de dos factores: la profundidad de color utilizada (más precisamente: formato de píxeles) y la resolución de imagen utilizada .

Profundidad del color

La profundidad de color del búfer de fotogramas define el número máximo de colores o matices de color que se muestran en la pantalla al mismo tiempo. En el área de las computadoras IBM compatibles con PC , los tamaños que se dan en la siguiente lista fueron y son comunes. Los formatos de píxeles especificados indican cuántos bits por píxel se asignan a los canales de color individuales (rojo, verde, azul, canal alfa ); esta información falta para los modos de color que usan colores indexados (paletas) porque no tiene ningún sentido.

• 1 bit por píxel, dos colores (generalmente claro y oscuro en un monitor monocromático )
  • MDA
• 2 bits por píxel, cuatro colores
  • CGA : paleta con 4 colores de 16 posibles
• 4 bits por píxel, 16 colores
  • EGA : paleta con 16 colores de 64 posibles
• 8 bits por píxel, 256 colores
  • VGA : paleta con 256 colores de 262144 posibles
• 15 bits por píxel, 32768 colores
  • Color real : formato de píxel 5-5-5, es decir H. 5 bits por canal de color (es decir, 32 niveles de intensidad por canal)
• 16 bits por píxel, 65536 colores
  • Color de alta densidad: formato de píxel 5-6-5, es decir H. 5 bits para rojo y azul (32 niveles de intensidad) y 6 bits para verde (64 niveles de intensidad)
  • alternativamente también 4-4-4-4, es decir H. 4 bits por canal de color (16 niveles de intensidad), por lo que los últimos cuatro bits no se utilizan o se utilizan como canal alfa (consulte color verdadero de 32 bits)
• 24 bits por píxel: 16777216 colores
  • Color verdadero : formato de píxel 8-8-8, es decir, H. 8 bits por canal de color (256 niveles de intensidad)
• 32 bits por píxel
  • Color verdadero: formato de píxel 8-8-8-8, es decir, H. 8 bits por canal de color (256 niveles de intensidad)
  • Los 8 bits que se han agregado al color verdadero de 24 bits normalmente no se utilizan; En computadoras con arquitectura de 32 bits, sin embargo, el procesamiento de valores de 32 bits es más eficiente que el de valores de 24 bits, porque esto corresponde exactamente a la longitud de palabra del procesador, razón por la cual los búferes de tramas de color verdadero principalmente a pesar del requisito de memoria un 33% más alto Utilice una profundidad de color de 32 bits.

Con hardware de gráficos que funciona con planos de bits (por ejemplo, Amiga ), 3, 5, 6 y 7 bits por píxel con los correspondientes 8, 32, 64 o 128 colores también son comunes para los colores indexados.

En los gráficos por ordenador en 3D, también se utilizan búferes de fotogramas con mayor precisión. Allí, la determinación del color de un píxel a menudo requiere varios pasos de cálculo, por lo que pueden ocurrir errores de redondeo con cada resultado intermedio , que son rápidamente visibles en los formatos de memoria intermedia de cuadros convencionales y tienen un efecto disruptivo.

Con estos formatos más precisos, los valores del canal de color se interpretan como valores de coma en una escala de 0.0 a 1.0, de modo que el manejo se simplifica cuando se utilizan varios formatos de píxeles.

• FX8
  • Punto fijo de 8 bits por canal de color , por lo tanto 256 gradaciones de color escaladas linealmente
  • idéntico a los 32 bits por píxel anteriores. Si toma los 256 valores diferentes por canal de color como un número entero entre 0 y 255 o como un valor de punto fijo entre 0.0 y 1.0 es solo una cuestión de interpretación.${\ Displaystyle \ left ({\ frac {\ text {value}} {255}} \ right)}$
  • contraste máximo 255: 1, por lo tanto, adecuado para renderizado de rango dinámico bajo (LDR), como se puede mostrar en pantallas normales de todo tipo
• FX12
  • Punto fijo de 12 bits por canal de color, por lo tanto 4096 gradaciones de color escaladas linealmente
  • mayor precisión que FX8
  • contraste máximo 4095: 1, adecuado para renderizado de rango dinámico bajo (LDR)
• FX16
  • Punto fijo de 16 bits por canal de color, por lo que 65536 gradaciones de color escaladas linealmente
  • mayor precisión que FX12
  • contraste máximo 65535: 1, adecuado para renderizado de rango dinámico medio (MDR)
• FP16
  • Punto flotante de 16 bits por canal de color (de los cuales exponente de 5 bits y mantisa de 10 bits ), por lo tanto 32768 gradaciones de color escaladas exponencialmente
  • En comparación con el FX16, la escala exponencial permite una resolución mucho más fina para valores pequeños, pero es menos precisa para valores más grandes.
  • contraste máximo aprox. , adecuado para renderizado de alto rango dinámico (HDR) .${\ Displaystyle 10 ^ {12}: 1}$
• FP24
  • Punto flotante de 24 bits por canal de color (incluido el exponente de 7 bits y la mantisa de 16 bits), por lo tanto, más de 8 millones de gradaciones de color escaladas exponencialmente
  • mayor precisión que FP16, por lo tanto, muy adecuado para renderizado HDR
• FP32
  • Punto flotante de 32 bits por canal de color (de los cuales exponente de 8 bits y mantisa de 23 bits), por lo tanto, más de 2000 millones de gradaciones de color escaladas exponencialmente
  • incluso mayor precisión que FP24

Resolución de imagen

La resolución de la imagen indica cuántos píxeles tiene el framebuffer. Por lo general, especifica el número de píxeles horizontal y vertical, lo que significa que también puede calcular la relación de aspecto directamente; 4: 3, 5: 4 y 16:10 son comunes aquí.

Ejemplos de

• Modo de texto (por ejemplo, al arrancar una PC compatible con IBM con BIOS )
  Para una consola con 80 × 25 caracteres, cada carácter y su color se guardan con 8 bits cada uno (es decir, un total de 16 bits), el búfer de tramas ocupa 80 × 25 × 16 = 32000 bits = 4 KB.
• Búferes de cuadros EFI en PC modernas con Interfaz de firmware extensible unificada (UEFI)
  Con EFI 1.x, el Adaptador de gráficos universal (UGA) era un controlador EFI independiente del hardware disponible para usar un búfer de cuadros de video simple. Esto fue reemplazado con UEFI 2.x por el Protocolo de salida de gráficos (GOP), que ahora también puede usar el modo de texto independientemente de la tarjeta gráfica. Tanto UGA como GOP reemplazan completamente el BIOS de video (VBIOS para abreviar, solo en PC con BIOS); por lo tanto, el controlador de gráficos ya no puede usar las funciones de VBIOS, por lo que algunos controladores de gráficos de PC más antiguos bajo (U) EFI no funcionan con hardware idéntico, pero con CSM activado (la emulación de BIOS de EFI o UEFI). Por lo tanto, los sistemas operativos y los controladores de dispositivos deben usar EFI-UGA o -GOP para poder usar el modo de texto (con GOP) o video y otras funciones de búfer de cuadros de firmware. En Linux hay conefifbun controlador de gráficos framebuffer genérico que funciona en todas las PC EFI y, por lo tanto, también es independiente de la tarjeta gráfica específica. Windows y macOS también usan el búfer de fotogramas EFI, pero como solo está disponible sin aceleración de gráficos, solo está disponible en un modo restringido.
• Modo de gráficos (por ejemplo, en Windows o el sistema X Window en Linux)
  Con una resolución de pantalla de 1024 × 768 píxeles y una profundidad de color de 24 bits, el búfer de fotogramas ocupa 1024 × 768 × 24 = 18874368 bits = 2,25 MiB .

En el caso de TrueColor, la descripción general tiene en cuenta que los datos se almacenan internamente con 24 bits.

Mejoras

Debido a las deficiencias en la continuidad de la secuencia de imágenes y con el fin de aumentar aún más la calidad de visualización general, el concepto del búfer de cuadros se ha revisado con el tiempo. Un framebuffer en los sistemas actuales corresponde a varios búferes.

• En el búfer doble ( búfer doble ) del búfer de trama en dos regiones ( búfer frontal y búfer posterior ) dividido.
• En el almacenamiento en búfer triple ( almacenamiento en búfer triple ) del búfer de tramas se encuentra (1 en tres áreas del búfer frontal y 2 BackBuffer dividido).

Framebuffer de Linux

Captura de pantalla de arranque de Knoppix

El dispositivo Linux Framebuffer ( fbdev para corto ) es una capa de abstracción de hardware-independiente bajo Linux a los gráficos de visualización en la consola o con una X-Window (XF86_FBdev). El dispositivo framebuffer no depende de bibliotecas específicas del sistema como SVGALib o el sistema X Window y, por lo tanto, es una alternativa que ahorra recursos al servidor X generalizado en el que se basan la mayoría de las interfaces gráficas para Linux en la actualidad. Se ha incluido en el kernel estándar para todas las plataformas desde la versión 2.1.107 del kernel de Linux.

Originalmente se implementó para Linux68k con el fin de emular un modo de texto en los sistemas correspondientes (Amiga, Atari, Macintosh) con una baja aceleración de hardware y solo más tarde se extendió a la plataforma compatible con IBM-PC.

Hoy en día el framebuffer puede ser usado directamente por diferentes programas como MPlayer y librerías como GGI, SDL , GTK + y Qt Extended . El concepto de ahorro de recursos hace que el uso sea particularmente interesante para los sistemas integrados.

En particular, es utilizado por varias distribuciones ( Ubuntu , openSUSE ) para habilitar la salida gráfica en forma de pantalla de bienvenida durante el arranque .

El controlador de framebuffer VESA más utilizado (vesafb) se basa en especificaciones uniformes de estándares de video y, por lo tanto, permite el acceso a tarjetas gráficas en gran medida independientes del fabricante. Esto significa que también es posible una implementación de código abierto. Además, varios fabricantes de chips gráficos ( Nvidia : rivafb, nvidiafb; AMD : radeonfb) introdujeron controladores propietarios en el mercado.

El dispositivo framebuffer se hizo conocido por su capacidad para mostrar un logotipo de Tux al usuario durante el proceso de carga del kernel de Linux . Sin embargo, para hacer esto, primero debe estar contenido en el kernel y activado especificando el parámetro durante el siguiente reinicio por parte del cargador de arranque , que también carga el sistema operativo en la memoria principal video.

A continuación se muestran dos ejemplos en los que se carga un controlador AMD con una resolución de imagen de 1024 × 768 píxeles, una profundidad de color de 8 bits por píxel y una frecuencia de actualización de 76 Hz:

Ejemplo de un archivo de configuración de LILO

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

Ejemplo de un archivo de configuración de GRUB

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

No es necesario escribir un módulo del kernel para el acceso de hardware al dispositivo de búfer de tramas. La aplicación también tiene la opción de /dev/fb*acceder al dispositivo en modo usuario a través del archivo del dispositivo y escribirlo en la memoria gráfica. El siguiente ejemplo demuestra cómo se puede utilizar el lenguaje de programación C para escribir linealmente en el búfer de tramas. Aquí, el valor hexadecimal 0x000000FF (binario: 0b00000000000000000000000011111111) se establece para cada píxel:

#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>
#include <stdio.h>

int main(int argc, char **argv) {
   int row, col, width, height, bitspp, bytespp;
   unsigned int *data;

   // Öffnen des Gerätes
   int fd = open("/dev/fb0", O_RDWR);

   // Informationen über den Framebuffer einholen
   struct fb_var_screeninfo screeninfo;
   ioctl(fd, FBIOGET_VSCREENINFO, &screeninfo);

   // Beende, wenn die Farbauflösung nicht 32 Bit pro Pixel entspricht
   bitspp = screeninfo.bits_per_pixel;
   if(bitspp != 32) {
     // Ausgabe der Fehlermeldung
     printf("Farbaufloesung = %i Bits pro Pixel\n", bitspp);
     printf("Bitte aendern Sie die Farbtiefe auf 32 Bits pro Pixel\n");
     close(fd);
     return 1; // Für den Programmabbruch geben wir einen Rückgabetyp != 0 aus.
   }

   width  = screeninfo.xres;
   height = screeninfo.yres;
   bytespp = bitspp/8; //Bytes pro Pixel berechnen

   // Überprüfen ob der Typ unsigned int die gleiche Byte-Grösse wie ein Pixel besitzt.
   // In unserem Fall 4 Byte (32 Bit), falls nicht wird das Programm beendet
   if(sizeof(unsigned int) != bytespp) {
      close(fd);
      return 1;
   }

   // Zeiger auf den Framebufferspeicher anfordern
   data = (unsigned int*) mmap(0, width * height * bytespp, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);

   // In den Framebuffer-Speicher schreiben. Hier wird Pixel für Pixel auf
   // die Farbe 0x000000FF (Blau) gesetzt, da ein Pixel das AARRGGBB Format hat
   for(row = 0; row < height; row++)
     for(col = 0; col < width; col++)
        data[row * width + col] = 0xFF;

   // Zeiger wieder freigeben
   munmap(data, width * height * bytespp);

   // Gerät schließen
   close(fd);
   // Rückgabewert
   return 0;
}

Ver también

• DirectFB , búfer de marco directo, una biblioteca de programas basada en el búfer de marco de Linux

Evidencia individual

1. ↑ Edgar Hucek: ¿Qué es efifb? En: Archivos del kernel de Linux. Consultado el 25 de agosto de 2020 .