Qual conjunto de drivers gráficos é melhor para testar a longo prazo?

Portanto, meu computador possui uma placa de mobilidade Radeon e o Compiz parece não querer se sair bem com ela. Isso me oferece uma vantagem: eu posso usar os drivers proprietários e obter o desempenho aprimorado e obter vários itens de usabilidade, ou posso usar os drivers "padrão" e obter o desempenho em favor de tudo funcionar corretamente.

Também faço muitos testes alfa em uma partição sobressalente nesta máquina. Isso me deixa pensando, qual driver devo usar? É mais importante que os drivers "padrão" tenham um desempenho melhor? Ou devo registrar erros contra o Unity porque ele não funciona corretamente com o conjunto proprietário? Ou ambos.

O que os desenvolvedores sugerem que eu corra para beneficiar mais o projeto a longo prazo? Independentemente do tipo de placa gráfica usada. Ou isso é um fator em que conjunto deve ser usado?

Como um dos mantenedores do Ubuntu X, posso dizer: testar os drivers de código aberto e proprietários é valioso; temos muitos usuários de ambos, e é importante que o Unity funcione bem na pilha livre e na pilha proprietária.

No entanto, se você deseja que seu teste tenha o maior impacto, testar a pilha livre seria o caminho a percorrer - pelo menos para placas AMD.

O driver radeon de código aberto possui um conjunto razoável de desenvolvedores - não é grande e sempre pode ser usado com mais, mas é suportado pela AMD. Exceto o influxo de centenas de desenvolvedores em tempo integral, esses drivers não terão o mesmo desempenho que o fglrx, mas é inteiramente possível que eles atinjam 90-95% do desempenho; é o último par de por cento que é extremamente caro.

Eles também são muito mais fáceis de melhorar - porque são de código aberto, temos visibilidade das correções e podemos justificar muito mais facilmente a correção de erros em versões estáveis. Com o driver fglrx, obtemos apenas recursos e correções de mixagem de despejo de código, com potencial de regressão desconhecido. Isso dificulta a atualização dos drivers proprietários em uma versão estável.

Finalmente, há mais perspectivas de melhoria para a radeon do que para a fglrx. Os desenvolvedores da Radeon se preocupam com toda a pilha de desktops, o fglrx é amplamente direcionado aos usuários de estações de trabalho.

Para nouveau, a resposta é um pouco mais obscura. Ainda há mais perspectivas de melhorias no nouveau do que na nvidia - novamente, a nvidia é amplamente direcionada ao mercado de estações de trabalho -, mas a nouveau tem mais dificuldade em progredir do que a radeon, pois eles também precisam fazer engenharia reversa de tudo.

Tudo isso se aplica principalmente a erros, e não a desempenho. Geralmente, é mais difícil gerar um bug de bom desempenho do que gerar uma boa falha ou um erro de renderização incorreto. Os erros de renderização e de travamento geralmente são isolados em uma pequena seção de código, enquanto os problemas de desempenho geralmente envolvem uma pilha inteira de código. Onde você encontra problemas isolados de desempenho, vale a pena relatar, mas esse não é o caso comum.

Em resumo, os problemas de desempenho geralmente exigem um esforço ativo para serem identificados - é improvável que você depare com um problema de desempenho acionável. Bugs - tanto travadores quanto incorretos - você pode facilmente identificar durante o uso normal.

Se você quiser ajudar a contribuir para o desenvolvimento e suporte de drivers do Ubuntu, designar, dar suporte e contribuir para a correção de bugs nas duas versões é o caminho a seguir. Ambos são importantes, mas você precisa diferenciar entre o que realmente está em suas mãos.

Driver fechado significa exatamente isso, está fechado. Você pode dizer que o Unity está quebrado por causa do driver fechado, mas no final, se o driver não funcionar, não há muito o que fazer. Os testes são feitos nos lançamentos oficiais, mas isso não significa que funcionará para todos.

Devo dizer que não acredito que o desempenho do driver de código aberto seja tão bom quanto o driver fechado, mas falando do Ubuntu e Linux, queremos ter pelo menos a alternativa de ter nosso hardware rodando em condições mínimas com um driver de código aberto.

Queremos garantir que, dada a opção, um usuário possa executar o Unity sem muitas falhas no driver de código fechado, mas o mais importante é que esteja disponível um driver de código aberto, bem construído e estável.

Com o driver fechado, você pode abrir bugs, reclamações, dar suporte a outras pessoas no relatório de dados para corrigir quaisquer problemas, mas, no final, será responsabilidade do construtor traçar o caminho para o desenvolvimento do driver.

Por outro lado, o driver fechado é amplamente suportado, os erros são levados mais a sério, o desenvolvimento é feito, mas também a correção de erros é implementada caso a caso. A comunidade de código aberto trabalha duro para que funcione da melhor maneira possível e com o menor número possível de problemas.

Seu tempo é valioso, relatando problemas no Unity em execução com o driver fechado, mas IMHO, o driver de código aberto merece muito mais e você terá mais valor pelo seu esforço em apoiá-lo.