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
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 Xorg nem subiu. Bug reportado e consertado no driver
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!
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
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 direitinho. Pena a interface alien[1] arruinar seu potencial.
KDE 4.8
Havia planos para que o KDE distribuído no F17 também usasse o
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
Mais uma vez o Btrfs por padrão mixou. Ficou para o Fedora 18 porque a prometida ferramenta de verificação (
ConsoleKit se foi (com Gnome/KDE): o systemd agora é o responsável pelas sessões dos usuários.
[1] Fedora 16 And GNOME Shell: Tested And Reviewed (Tom's Hardware)
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 Xorg nem subiu. Bug reportado e consertado no driver
openchrome (o Xorg 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 direitinho. Pena a interface alien[1] 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.
[1] Fedora 16 And GNOME Shell: Tested And Reviewed (Tom's Hardware)
Re: Marcos FRM
ResponderExcluirPrimeiramente, 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... :)
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".
ResponderExcluirE o llvmpipe faz "apenas" a parte da GPU.
Foi o que entendi... :)
Valeu Marcos
ResponderExcluirO que eu estava em dúvida era justamente se os drivers caducos ainda tinham alguma função, e qual.