Confira!!
Se você tentar executar o GNOME Shell hoje no Raspberry Pi, é uma experiência frustrantemente lenta. Enquanto algum trabalho está sendo feito para lidar com a GPU, a CPU e o consumo de memória do GNOME, é possível que ele nunca esteja em condições de funcionar sem problemas no hardware do Raspberry Pi.
No início deste mês foi o GNOME 2018 Performance Hackfest e um dos participantes foi Eric Anholt, da Broadcom, que mantém as pilhas de drivers gráficos VC4 e V3D. O primeiro é mais notável por ser a solução de driver gráfico totalmente de código aberto para o hardware VideoCore encontrado em computadores de placa única Raspberry Pi até este ponto.
Enquanto estava no hackfest do GNOME, Eric estava trabalhando na adição de suporte para capturar eventos de DRM dentro do gerenciador de perfis do sistema sysprof. Isso é útil para quem faz o perfil do desempenho do GNOME e tenta fazer otimizações para ver também o que está acontecendo no espaço do Direct Rendering Manager, como tarefas e vblanks da GPU.
Esse trabalho é empolgante e beneficiará a maioria dos drivers de DRM para poder expor mais análises de desempenho por meio do sysprof. Mas mesmo com a recente motivação do GNOME em melhorar o desempenho, Eric Anholt duvida que o GNOME 3 funcionará bem no Raspberry Pi.
Eric escreveu:
Por fim, porém, sou cético quanto ao uso do GNOME 3 em um Raspberry Pi. A pintura gnome-shell baseada em desordem é muito lenta (60% de um CPU queimado no shell tentando apresentar apenas um glxgears de 60fps), e não parece haver um plano para melhorá-lo além de "talvez nós" ll apagar a desordem algum dia? ”Além disso, o sistema de extensão javascipt sendo no segmento de compositor significa que você soltar quadros de aplicativos quando algo mais (mudanças de estatísticas de rede, notificações, etc) acontece no sistema. Essa era uma escolha ruim de arquitetura de software, e sair daquele buraco agora levaria muito tempo. (Eu sou agnóstico sobre se foi errado movê-los para o mesmo processo que o compositor, mas o mesmo thread estava definitivamente errado). Continuarei trabalhando nas ferramentas de depuração para tentar habilitar qualquer um a trabalhar nesses problemas.
Os interessados no restante de seu perfil de DRM e melhorias no VC4 / V3D podem ver o restante de sua atualização de status do driver . A outra novidade que ele relata é que o driver V3D Gallium3D está habilitado por padrão agora como parte do driver DRM V3D (antigo "VC5") definido para ir a montante no ciclo de kernel Linux 4.18.
Fonte
Até a próxima!!
Nenhum comentário:
Postar um comentário