PDF de programación - x.org en segunda marxa

X.org en segunda marcha

Franco Catrin Leiva - TUXPAN Software / Editor de FayerWayer

 

 

Temas

 Pre-Historia : X Window System / Xfree 86
 X.org en primera : La deuda histórica
 X.org en segunda : Buscando la perfección
 Futuro : La innovación

Pre-Historia : X Window System / Xfree 86

 

 

X Window System

X Window System

 Sistema gráfico independiente de la plataforma
 Se inicia en 1984 en el MIT con Jim Gettys
 En 1987 llega a la versión actual : 11
 Compatible con “clientes livianos”
 Definido por X Consortium : Todos menos Sun
 Licenciado bajo MIT

 No hay énfasis en compartir
 Cada empresa tenía su fork
 Los parches no regresaban al proyecto

X Window System se abre

 X era previo a GPLv1
 Richard Stallman insistía en que cambiaran la

licencia

 Jim Gettys convenció a DEC a abrir el proyecto
 Finalmente absorbieron a Sun con un nuevo

“estándar de la industria”

XFree86

 Se inicia en 1992 : X Window System para 386

 X 386 → X Three 86 → X Free 86

 Linux lo hizo popular y se convirtió en la

implementación más desarrollada

 Sin embargo, la innovación se estancó a fines de los

'90

El fin de XFree86

 En el Core Team habían discrepancias sobre la

dirección del proyecto

 Keith Packard pensaba que faltaba mucho por hacer,

pero no tenía el apoyo en la organización

 Keith Packard es expulsado del Core Team por

“actitudes sospechosas”

 El Core Team finalmente se desbanda
 Se inicia X.org como un proyecto independiente o

fork, liderado por Keith Packard

X.org en primera: La deuda histórica

 

 

Problemas presentes en X

 X estaba diseñado para un hardware que ya cambió
 El sistema de fonts era inadecuado

 Fonts en el servidor se tenían que descargar al cliente
 Antialias era muy costoso
 Font Servers fueron sólo un parche
 Unicode : Imposible

 Operaciones complejas como blending eran

demasiado caras de implementar e imposibles de
acelerar

Keith Packard y sus ideas

 Fonts en el cliente
 Extensión RENDER (blending/antialias)
 Cambio en el modelo de composición
 Resize and Rotate (RANDR) Extension

 Cambiar resolución on-the-fly
 Cambiar orientación
 Configurar salidas alternativas

Aceleración en X

 DIX : Device Independant X
 DDX : Device Dependant X
 DDX Se ejecuta en user space
 XAA : X Acceleration Architecture

 Operaciones 2D principalmente
 Dependiendo del driver, usaba aceleración completa,

parcial o sólo render por software

 En algunos casos puede ser muy rápido
 No apta para RENDER

Aceleración en X con XAA

X

XAA

DDX

Comandos

SW Render

Kernel

Memoria / MMIO

Direct Rendering Infrastructure

 X envía comandos directos al hardware
 Requiere un módulo en el kernel : DRM
 X → DRI → DRM → Comandos al hardware
 Complejidad limitada : puede botar el kernel
 Usado principalmente en operaciones 3D

Aceleración en X con DRI

X

DDX

SW Render

Kernel

Mem / MMIO

DRI

DRM

EXA Acceleration Architecture

 Reemplaza a XAA
 Se originó en Kdrive: X Server experimental de Keith

Packard

 Diseñada con RENDER en mente
 Limitada a operaciones 2D
 Usa grandes cantidades de VRAM → Swap

 Requiere un gestor de memoria
 Cada driver necesita su propio gestor de memoria
 Requiere copiar RAM ← → VRAM

Composite Extension

 Otra idea de Keith Packard!
 Composite Manager dibuja el contenido de las

ventanas en el escritorio

 Puede aplicar todo tipo de transformaciones : 2D y

3D

 Xcompmgr : Primer Composite Manager

 Sombras/Transparencias necesitaban RENDER

 Compiz : Primer Composite Manager 3D famoso

 Requiere aceleración 3D

Compiz presiona los cambios

 Desarrollado bajo el alero de Novell
 Inicialmente funcionaba sobre XGL

 Compiz → XGL → OpenGL → X Server tradicional
 Todo es una textura
 Reproducción de video era impráctica

 Surge AIGLX desde Red Hat y NVIDIA

 Para qué hacer un nuevo X?
 X Server tradicional + GL_EXT_texture_from_pixmap

Segunda marcha : Buscando la perfección

 

 

Problemas en X.org

 EXA requiere mucha memoria y un gestor de

memoria
 Un gestor de memoria por cada driver dificulta su desarrollo
 Se deben copiar bloques de memoria RAM ← → VRAM
 Mantener el estado del hardware en X dificulta

suspend/resume de la máquina

 La consola, X y cualquier otra aplicación gráfica

deben pelear por acceder al hardware
 Se debe apagar una para usar otra

Gestión de memoria en el kernel

 Intel desarrolla GEM : Graphics Execution Manager
 Es un gestor de memoria en el kernel: Fuera de X
 No usa paginación sino que “buffer objects”
 Permite trabajar en RAM normal y GEM mapea

automáticamente a VRAM. Sin copiar

UXA Acceleration

 UXA = EXA + GEM
 EXA necesitaba copiar de RAM ← → VRAM.
 UXA permite usar memoria de sistema y GEM la

mapea a VRAM : Sin copiar

 UXA es básicamente EXA sin el trabajo innecesario al

tener GEM

DRI2

 En DRI1 cada aplicación accede a un conjunto

compartido de buffers

 Cada aplicación gestionaba el swap en su buffer
 Cuando una aplicación usaba su buffer, bloqueaba

todas las demás

 DRI2 provee buffers privados e independientes para

cada aplicación

 En DRI2 no se requiere usar bloqueo

DRI1

App1

App2

Lock

Buffer1

Buffer2

Buffer3

Buffer4

DRI2

App1

App2

Buffer1

Buffer2

Buffer3

Buffer4

Video Mode Setting

 DRM ahora puede tomar mayor control del hardware
 Cambio de modo de video lo realiza el kernel
 No hay que apagar aplicaciones para acceder al

video

 Si el modo solicitado es el mismo, no se cambia
 Disminuye el parpadeo
 Facilita el desarrollo de nuevos sistemas gráficos o

aplicaciones fullscreen

Kernel Video Mode Setting

Consola

X.org

Wayland

Kernel / DRM / GEM

800x600

1024x768

El Futuro : La innovación

 

 

Wayland

 Sistema gráfico simple, no compatible con X
 Se apoya en GEM y Kernel Mode Setting
 Ya no es tan complejo hacer un sistema gráfico
 X puede correr al interior de Wayland

Gallium 3D

 API gráfica portable para distintos sistemas

operativos

 Permite reducir la complejidad de los drivers
 App → API → State Tracker → Driver → WinSys → HW
 App → OpenGL → State Tracker → i945 → WinSys →

DRI

 App → DX → State Tracker → i945 → WinSys → HW

Consultas