quinta-feira, 5 de abril de 2012

Fedora 17 Beta

GNOME SHELL + ACELERAÇÃO 3D POR SOFTWARE

Adam Jackson, no ciclo de desenvolvimento do Fedora 17, tem como um de seus trabalhos fazer o Gnome Shell rodar sobre drivers sem aceleração 3D por hardware (DRI2) através do llvmpipe (Mesa), que faz o trabalho por software na CPU.

Será que funciona num VIA P4M800 + Pentium 4 524 + 1,5 GB de RAM? O começo não foi dos melhores, pois com a mídia de instalação F17-Beta-TC1 x86-64 (esse P4 possui EM64T ao menos...) o X.Org nem subiu. Bug reportado e consertado no driver openchrome (o Xserver do F17 é compilado com XAA desativado, que o driver tentava usar). A partir da mídia F17-Beta-RC3 o pacote está corrigido.

Se você é um infeliz usuário de chips gráficos VIA e usa o Fedora, me deve um café. Se bem que é como Adam Williamson comentou no f17-beta-blocker-review-4: o suporte às GPUs da VIA é borderline, nicho do nicho...

Em chips gráficos sem KMS (como os VIA) o boot não é flicker-free, porque existe uma mudança de resolução no momento em que o X iniciar. Aquela barrinha azul do Plymouth não-KMS-FB eu acho charmosa ainda assim.

Relacionado, dois bugs (já consertados) que podem ter quebrado o boot flicker-free do Fedora: RHBZ#785548, RHBZ#785662

Voltando. Depois do logar caio no Gnome Shell!

Gnome Shell em chip gráfico VIA

Funciona sem glitches, mas fica lento demais. Participei do Test Day ocorrido em 29/03/2012 e outro relato similar apareceu. Adam Jackson nos pediu um teste simples com o perf e obteve informação para mais uma rodada de trabalho para tentar otimizar o Gnome Shell quando rodando com o llvmpipe. Esperemos para ver no que vai dar.

GNOME 3.4

Já disse que me desgostei do Gnome Shell, porém é o ambiente mais bem implementado no Fedora. É nele que programadores da Red Hat despendem maior parte do seu tempo. A integração com as novas interfaces do systemd, por exemplo, primeiro chega nele.

O Gnome 3.4 está funcionando diretinho. Pena a interface alien¹ arruinar seu potencial.

KDE 4.8

Havia planos para que o KDE distribuído no F17 também usasse o llvmpipe para os efeitos do KWin. Inclusive durante um tempo o pacote da distribuição esteve com um patch que habilitava-o. Todavia por problemas de desempenho acabaram desistindo neste ciclo. É coisa para o Fedora 18.

Estava vacinado antes da instalação terminar que não poderia esperar bom desempenho por causa do infame vídeo integrado VIA. Porém não ficou tão ruim quanto eu esperava; algo do tipo tolerável. Continua, entretanto, sendo uma experiência que não recomendo a ninguém. Qualquer vídeo chinfrim da Intel, AMD ou nVidia (prefira Intel/nVidia) dará resultados bem melhores.

DIVERSOS

Ver Fedora 17 Alpha se aproxima.

O Fedora 17 virá com a suíte xfsprogs 3.1.8 (não entrou no Beta), cujo mkfs.xfs cria sistemas de arquivos com o tamanho do setor de acordo com o setor físico reportado pelo dispositivo de armazenamento, como comentado aqui.

Mais uma vez o Btrfs por padrão mixou. Ficou para o Fedora 18 porque a prometida ferramenta de verificação (btrfsck) ainda não está pronta (parto de burro, hein?).

ConsoleKit se foi (com Gnome/KDE): o systemd agora é o responsável pelas sessões dos usuários.

Notas de rodapé:

¹ Fedora 16 And GNOME Shell: Tested And Reviewed (Tom's Hardware)

3 comentários:

  1. Re: Marcos FRM

    Primeiramente, obrigado pelos comentários lá no http://linuxlike.blogspot.com.br/

    Pelo jeito você está bem por dentro do assunto. Aliás, o seu blog me ajudou a entender melhor como a coisa toda funciona.

    Só não tenho certeza se entendi bem o seguinte: o LLVMpipe substitui completamente os drivers caducos ou apenas a parte que era feita pelo DRI1?

    Eu entendi que substitui o DRI1.

    Como relatei no post (http://linuxlike.blogspot.com.br/2012/04/gnome-shell-sem-driver-3d.html), no meu Note, o openchrome é carregado pelo Xorg. Então, julgo que o LLVMpipe seja responsável pela renderização 3D e que todo resto fique por conta do openchrome.

    Com os outros drivers obsoletos também é assim?

    Se você puder dar mais detalhes sobre isso... :)

    ResponderExcluir
  2. Então o openchrome ou o sis (ou outro driver caduco) continua lá, sendo carregado e utilizado pelo sistema e cumprindo sua função de "juntar tudo e exibir a imagem na tela".

    E o llvmpipe faz "apenas" a parte da GPU.

    Foi o que entendi... :)

    ResponderExcluir
  3. Valeu Marcos

    O que eu estava em dúvida era justamente se os drivers caducos ainda tinham alguma função, e qual.

    ResponderExcluir