A inovação no X Window: bem-vindo ao novo Xorg

Ao longo dos anos, muitas pessoas têm reclamado do sistema X Window. O X Window (ou sua implementação mais popular no momento, o Xorg) é a camada que fica entre os aplicativos e a placa de vídeo. Ele tem recursos fantásticos (como a capacidade de executar aplicativos via rede), mas tem alguns probleminhas (como parecer ter sido construído de trás para a frente).

Uma coisa é certa: ele evoluiu enormemente de um ano para cá, especialmente no que diz respeito aos gráficos 3D e à aceleração por hardware.

Neste artigo, vou explicar como o X Window mudou, e o que podemos esperar dele no futuro.

Várias coisas relevantes aconteceram, e uma depende da outra. Mas antes de mais nada, algumas explicações básicas.

Métodos de aceleração do Xorg

Os drivers do Xorg costumam ser formados por várias partes, sendo que uma delas é essencial:

• O driver DDX é a parte que permite ao X desenhar na tela: ele configura a resolução e a profundidade do buffer de pixels e passa isso tudo para a tela. Esse driver costuma ficar hospedado totalmente no espaço de usuário, e tradicionalmente incluía algumas funções de aceleração, como fills (preenchimentos). Esses métodos de aceleração eram usados originalmente por meio de uma API chamada XAA, que depois foi simplificada e reescrita na maioria dos drivers, tornando-se a EXA. Esse é o componente 'essencial'.

• O componente duplo DRI/DRM foi acrescentado depois, na época do Xfree86 4.0, e permite ao X conversar diretamente com o hardware gráfico: um componente do kernel (o módulo DRM) e um componente do X (o driver DRI) interagem seguindo métodos rígidos, burlando as cópias para a memória feitas pelo kernel para a maior parte das funcionalidades. É aqui que as coisas ficam interessantes para extensões como RENDER e Composite, já que elas permitem ao X manipular diretamente a RAM de vídeo. Juntas, a API EXA e a extensão RENDER usarão esse tipo de acesso para acelerar ainda mais as operações de desenho. Só que esse componente não foi criado para lidar com quantidades tão grandes de dados, e um gerenciador de memória precisava ser programado especificamente para cada driver.

• O driver GLX ([Open]GL no X) fica sobre os dois componentes mencionados. Geralmente recorrendo à biblioteca Mesa, ou ele usa as funções de aceleração por hardware (se o DRI e o DRM estiverem habilitados) ou recorre ao modo de renderização por software para desenhar na tela por meio do driver DDX. Mas esse sistema é limitado e exige um driver específico para cada placa de vídeo.

Há um componente separado dos gráficos do X: o driver de console do kernel interage com o mesmo hardware que o X usa, e precisa ser "desligado" e ligado novamente quando o X assume o comando ou quando o usuário muda para um console virtual.

O que mudou

Quando foi lançado, o Compiz se apoiava em um servidor minimalista compatível com o X11R6 e que funcionava totalmente por meio do driver GLX da placa: era um servidor dentro de um servidor, mais conhecido com XGL. Cada componente gráfico era escrito como uma textura e mapeado para polígonos dentro de um aplicativo. Isso funcionava bem, mas havia grandes limitações:

• Não havia aceleração de vídeo: qualquer decodificação era realizada pelo processador, e cada quadro era copiado como uma textura para a GPU. A conversão do espaço de cores e a compensação de movimentos, dentre outros, ficavam a cargo da CPU, e isso consumia muitos recursos.

• O X não podia mais ser executado em rede: o modelo cliente/servidor do X permite que um aplicativo seja executado em uma máquina e exibido em outra. Embora isso não seja diretamente útil em desktops comuns, poderia causar problemas em outras áreas, como na troca de usuários.

Uma solução "melhor" surgiu, integrando as funções tridimensionais ao servidor X "básico": isso levou ao desenvolvimento do AIGLX e o GL_EXT_texture_from_pixmap tornou-se um requisito em todos os drivers. Na época, só drivers livres implementaram a extensão, ao contrário dos drivers proprietários da ATI, da Intel e da Nvidia. Por outro lado, devido à falta de documentação e de desenvolvedores, os drivers livres ofereciam suporte 3D de desempenho rudimentar/instável/baixo.

Várias coisas aconteceram:

• Um projeto, utilizando recursos espalhados pela web, começou a implementar a aceleração no hardware da Nvidia. O projeto, chamado de Nouveau, atingiu seu primeiro marco após um ano de desenvolvimento, rodando um Quake 3 limitado em modo com aceleração 3D com um driver totalmente livre em uma placa da Nvidia. Mas o projeto foi abandonado (nós veremos o motivo mais adiante).

• A Intel, seguida pela ATI/AMD, liberou a documentação de seu hardware gráfico e ofereceu ajuda aos desenvolvedores externos para que desenvolvessem drivers 2D e 3D completos para a maior parte de seu hardware atual e também para hardware obsoleto.

• O Compiz não foi o único gerenciador de janelas com composição 3D por muito tempo, e logo vieram forks e experimentos em que os desenvolvedores arriscavam coisas mais exóticas o tempo todo. Isso fez com que se chegasse às limitações da estrutura interna do Xorg, e levou ao desenvolvimento de diversas extensões como a randr1.2/1.3 ou a autodetecção de hardware do Xorg.

• O Ubuntu fez do desktop GNU/Linux um lugar comum.

• Chegaram os OpenGL 2.1 e 3.0, com a proposta de uma linguagem de programação completa para os shaders: chegava ao fim a era da biblioteca Mesa, na qual uma extensão era mapeada para um recurso específico do chip (o que nós chamávamos de "fixed function shaders", ou shaders de função fixa)

Os desafios que surgiram

Primeiro houve uma certa explosão no desenvolvimento de aplicativos relacionados ao desktop: gerenciadores de janelas melhores, um novo kit de ferramentas para a interface (ou melhorias de kits anteriores), recriação de ambientes de desktop (KDE 4) e um interesse muito mais aprofundado nas tecnologias de renderização de fontes: o desktop Linux tinha um visual 3D arrasador, mas era meio esquisito ver aquelas fontes de glifos toscos em meio às moderníssimas janelas em chamas.

A renderização de fontes passou por grandes melhorias, mas começou a esbarrar nas limitações do Xorg: renderizar fontes com anti-aliasing e subpixels consumia muitos recursos quando não havia aceleração por hardware.

Até quem não usava os recursos "descolados" do Compiz tinha que reconhecer que mover as janelas sem que elas ou o fundo delas fosse continuamente redesenhado era legal, e o uso bidimensional do composite virou febre. Mas isso tocou em um nervo exposto do Xorg: para economizar memória, a EXA trabalha diretamente na RAM de vídeo, geralmente escrevendo nela (o que sai barato em termos de consumo de recursos), e às vezes fazendo leituras (o que já sai mais caro, mas não muito se forem usados alguns truques). Só que um desktop com uso total de composição exige MUITA RAM para funcionar bem, fazendo com que o X tenha que trocar dados frequentemente da VRAM para a RAM, algo que a EXA não tem como fazer sem consumir muitos recursos.

Some a isso os problemas causados quando se alterna entre uma instância do X e um terminal virtual (gerenciado pelo driver de console independente do kernel), ou a suspensão para a RAM e/ou a suspensão para o HD, e o resultado é uma dor de cabeça: quem lida com a memória gráfica?

E só para piorar, como a GPU agora pode fazer um monte de coisas que antes eram exclusividade da CPU e não está limitada a funções fixas, quem fornece os dados a ela e de que maneira? A GPU não é mais um mágico de um truque só.

O que foi decidido

Ficou acertado que o X seria completamente reescrito, e alguns recursos promissores começaram a aparecer rapidamente.

A Tungsten Graphics propôs um gerenciador de memória que pudesse ser usado por todos os drivers e placas de vídeo, e que residia no kernel. O projeto Nouveau começou a usá-lo, bem como os projetos Radeon e RadeonHD, mas os desenvolvedores da Intel decidiram escrever um gerenciador mais simples chamado GEM. Outros projetos acharam que a abordagem da Intel era um pouco melhor e começaram a fazer melhorias no projeto original da Intel. O GEM foi incluído pela primeira vez no kernel 2.6.29, e por enquanto suporta apenas hardware da Intel. Ramos experimentais dos projetos Radeon, RadeonHD e Nouveau ainda usam o TTM internamente, mas se comunicam com o kernel por uma interface GEMificada.

Também ficou decidido que o DRI/DRM seria reescrito para tirar proveito do GEM: já que o kernel pode configurar o espaço da memória de uma placa de vídeo, ele também deve ser capaz de inicializar e configurar seus modos de exibição: o DRI2 foi criado para o X e o DRM agora inclui a configuração de modos. Os drivers do kernel para o console, pelo visto, vão trilhar o caminho dos dinossauros. Isso permite que a tela não pisque durante o processo de boot na hora de configurar os diversos modos de exibição, além de facilitar os modos de suspensão. Outra melhoria planejada é um gerenciamento de energia mais detalhado para as GPUs que ofereçam esse recurso.

Como o gerenciador de memória não é mais tarefa específica dos drivers, os criadores de drivers podem trabalhar na melhoria do desempenho. Isso resultou no suporte ao randr1.2 em vários drivers, na aceleração na extensão RENDER e a um grande aumento na velocidade da renderização de fontes, além de maior estabilidade. Por enquanto, a maioria dos drivers lançados ainda se amparam no gerenciador antigo, mas nas versões de desenvolvimento os novos recursos são adicionados toda semana, ou até diariamente. Com os drivers livres, o hardware recente também tem suporte mais rápido.

E o processo ainda não acabou. Se você tiver a sorte de possuir uma combinação que já tenha sido testada, vai poder desfrutar de movimentação e redimensionamento suave de janelas, de um processo de inicialização e volta da hibernação no qual a tela não pisca e de suporte a 3D.

Conquistas recentes:

• A ATI/AMD abandonou o suporte às R300-R500 em seu driver fglrx proprietário; agora essas placas têm suporte total nos drivers livres (2D e 3D). Embora o desempenho 3D ainda perca um pouco, o 2D está bem melhor do que o existente no fglrx. Há suporte para aceleração 2D em todas as placas ATI/AMD, até nas recém-lançadas HD4xxx (inclusive).

• O Ubuntu 9.04 já vem com o driver Nouveau disponível para placas da Nvidia; embora a qualidade ainda não seja a de um produto pronto, a maioria das placas da Nvidia já pode ao menos desfrutar de aceleração 2D, do RENDER e do randr1.3.

• O Gallium3D, componente que supostamente vai ocupar o lugar da biblioteca Mesa GL, já mostrou não apenas polígonos renderizados na tela (oba!) mas também shaders sendo compilados e renderizados nas versões de desenvolvimento de vários drivers livres, como nos dos projetos Radeon/RadeonHD e Nouveau (legal!).

Conclusão

No momento, fazer uma relação do que cada placa suporta (e como suporta) é muito difícil: o mundo do X vive um momento de transição no qual o 3D não é mais a preocupação principal. O 2D e o 3D cada vez se misturam mais e vão sendo considerados em um nível maior do que antes, enquanto as placas de vídeo são consideradas mais como CPUs e RAMs auxiliares e que precisam de tratamento diferenciado; a enorme reformulação pela qual o projeto Xorg e seus afiliados passaram pode causar problemas de suporte, perdas de desempenho e muitas complicações agora, mas o que o novo Xorg reserva para nós no futuro vai valer muito a pena.