4 de abr de 2012

GNOME Shell sem driver 3D

Hoje resolvi testar o GNOME 3.4 no meu velho Notebook Itautec. A intenção era experimentar as "novidades" da interface Fallback (GNOME Clássico). Mas, para minha surpresa, a interface padrão - o GNOME Shell - entrou direto, com sombras, transparências e outros efeitos.

Já tinha lido na Linux Magazine que, futuramente, o GNOME Shell poderia ser executado em sistemas com drivers e placas gráficas que não possuem suporte 3D. Mas não dei muita atenção - não botei fé. Não achei que o recurso estaria disponível para placas de vídeo VIA (meu Note conta com chipset/vídeo VIA VN896/Chrome 9 HC). Me enganei.

Screenshot
VIA + GNOME Shell 3.4, sem driver 3D!

Ainda que o Xorg faça o carregamento do driver openchrome, o GNOME utiliza o LLVMpipe, que faz a renderização 3D por software, via CPU (detalhes técnicos AQUI).

Screenshot
Driver llvmpipe: renderização 3D por software

O desempenho, no meu Notebook, não é muito bom. Com aceleração 3D pela CPU, a culpa agora é do processador, que é fraquinho - um Celeron. Embora utilizável, o sistema ficou lento, pesado.

Mas creio - agora acredito! - que isso pode melhorar no futuro. (:

Já a interface Fallback - que ainda pode ser ativada manualmente nas configurações do sistema - funciona muito bem.

Enfim, uma boa notícia. A experiência padrão do GNOME 3 está agora disponível para todos (ou quase todos), independentemente do hardware ou driver suportar 3D ou não. Isso inclui as máquinas virtuais. E o Fallback, a interface clássica, está com os dias contados.

Quer experimentar o GNOME 3.4? Baixe a imagem ISO - Live CD/USB, recomendável apenas para testes - AQUI.

Uma dica: para iniciar o Live CD/USB diretamente em modo Fallback, adicione o parâmetro gnome.fallback=1 no GRUB (menu de boot).

Referências:

9 comentários

Marcos FRM disse...

Rapaz, eu estou com um rascunho no meu Blog dizendo exatamente a mesma coisa! (esperando apenas sair o Fedora 17 Beta final para publicar)

Você foi mais rápido no gatilho, porém. :-) No meu VIA P4M800 (+ um caduco Pentium 4 524) também ficou uma carroça o 3D via llvmpipe. Eu participei do test day que o time do Fedora organizou dia 29 do mês passado e tinha outro cara lá com a mesma reclamação. Adam Jackson nos pediu um teste com o perf e concluiu que o problema está no Gnome Shell e que ele tentará melhorar o que for possível.

Pelo menos eu não notei glitches nem bugs fora a lentidão (havia glitches feios com o pacote mesa "-7" do Fedora 17, porém no "-9" foi arrumado). É alguma coisa pelo menos...

Abraço!

Rodrigo Miguel disse...

Re: Marcos FRM

Primeiramente, obrigado pelos comentários, neste e em outros posts.

Pelo jeito você está bem por dentro do assunto. Aliás, o seu blog (http://caixaseca.blogspot.com.br/) 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. 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... :)

Marcos FRM disse...

É como se fosse uma GPU virtual, que usa o LLVM (a mesma infraestrutura do compilador patrocinado pela Apple) para rasterizar os objetos 3D na CPU. Os drivers 2D tem pouco papel com o Mutter/Kwin/etc + llvmpipe. Eles juntam tudo e montam a imagem a ser exibida na tela.

No final das contas, o X.Org em harware atual (com suporte a KMS e DRI2) e um gerenciador de janelas com "compositing" serve para quase nada. Que venha o Wayland para simplificar!

DRI é uma interface disponibilizada pelo kernel para permir acesso direto à GPU.

Em teoria o llvmpipe pode ser usado por todos os drivers que não sejam suportados na libMesa (Mesa 8.0 passou a faca no hardware obsoleto todo), que tenham implementações muito antigas do OpenGL ou sejam muito lentos.

Ao usar o llvmpipe a necessidade da DRI desaparce. Não existe mais hardware que precise ser gerenciado pelo kernel. O trabalho é feito na libMesa em conjunto com o LLVM -- tudo software.

Rodrigo Miguel disse...

Re: Marcos FRM

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... :)

Marcos FRM disse...

Quase. Minha frase não ficou clara. "juntar tudo e exibir a imagem na tela" são na verdade duas etapas: "juntar" é feito pelo compositor (o Mutter no Gnome 3); "exibir" é pelo X.

Menos coisa ainda que o X faz...

Rodrigo Miguel disse...

Valeu Marcos

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

Lex Aleksandre disse...

Pois então, eu comprei um novo notebook só para poder usar o Debian Wheezy com Gnome Shell. A versão do Gnome ainda é a 3.2.1; não funciona em meu antigo notebook com um bom processador mas com um chip SiS.
Espero que até o lançamento do Wheezy seja essa versão aí ou uma mais atual que venha com ele.

Brenno disse...

Duvido que funcione em SiS, mesmo que seja lentamente. =/

Rodrigo Miguel disse...

Re: Brenno

Faça o teste:
http://ftp.gnome.org/pub/GNOME/misc/promo-cd/

(: