¿Qué conjunto de controladores de gráficos es mejor probar a largo plazo?

Entonces, mi computadora tiene una tarjeta de movilidad Radeon y Compiz no parece querer jugar bien con ella. Esto me da una compensación: puedo usar los controladores patentados y obtener el rendimiento mejorado y tener éxito en varios elementos de usabilidad, o puedo usar los controladores "estándar" y llevar el éxito al rendimiento a favor de que todo funcione correctamente.

También hago muchas pruebas alfa en una partición de repuesto en esta máquina. Esto me hace preguntarme, ¿qué controlador debo usar? ¿Es más importante lograr que los controladores "estándar" realmente funcionen mejor? ¿O debería presentar errores contra Unity porque no funciona correctamente con el conjunto propietario? O ambos.

¿Qué sugieren los desarrolladores que corro para beneficiar más el proyecto a largo plazo? Independientemente del tipo de tarjeta gráfica que se use. ¿O es eso un factor en qué conjunto debe usarse?

Como uno de los mantenedores de Ubuntu X puedo decir: las pruebas en los controladores de código abierto y propietarios son valiosas; Tenemos muchos usuarios de ambos, y es importante que la Unidad funcione bien tanto en la pila libre como en la pila patentada.

Sin embargo, si desea que sus pruebas tengan el mayor impacto, probar la pila gratuita sería el camino a seguir, al menos para las tarjetas AMD.

El controlador radeon de código abierto tiene un conjunto razonable de desarrolladores: no es grande y siempre puede hacer más, pero es compatible con AMD. Salvo la afluencia de cientos de desarrolladores a tiempo completo, estos controladores no lograrán el mismo rendimiento que fglrx, pero es completamente posible que logren el 90-95% del rendimiento; Es el último dos por ciento que es extremadamente caro.

También son mucho más fáciles de mejorar, ya que son de código abierto, tenemos visibilidad de las correcciones y podemos justificar mucho más fácilmente la corrección de errores en las versiones estables. Con el controlador fglrx solo obtenemos características y arreglos de mezcla de volcado de código, con potencial de regresión desconocido. Esto nos dificulta actualizar los controladores propietarios en una versión estable.

Finalmente, hay más perspectivas de mejora para radeon que para fglrx. Los desarrolladores de Radeon se preocupan por toda la pila de escritorio, fglrx está dirigido principalmente a usuarios de estaciones de trabajo.

Para Nouveau, la respuesta es un poco más oscura. Todavía hay más posibilidades de mejoras en nouveau que nvidia, una vez más, nvidia está dirigida principalmente al mercado de estaciones de trabajo, pero a nouveau le resulta más difícil avanzar que Radeon, ya que además necesitan realizar ingeniería inversa en todo.

Todo esto se aplica principalmente a errores en lugar de rendimiento. En general, es más difícil generar un buen error de rendimiento que generar un buen bloqueo o un error de representación incorrecto. Los errores de renderizado y bloqueo generalmente están aislados en una pequeña sección de código, mientras que los problemas de rendimiento generalmente involucran una pila completa de código. Cuando encuentre problemas de rendimiento aislados, puede valer la pena informarlos, pero ese no es el caso común.

En resumen, los problemas de rendimiento generalmente requieren un esfuerzo activo para identificarlos; es poco probable que tropiece con un problema de rendimiento procesable. Los errores, tanto los bloqueadores como los errores, pueden identificarse fácilmente durante el uso normal.

Si desea ayudar a contribuir a un mayor desarrollo y soporte de controladores para Ubuntu, asignar, apoyar y contribuir a la corrección de errores en ambas versiones es el camino a seguir. Ambos son importantes, pero debe diferenciar entre lo que realmente está en sus manos.

Conductor cerrado significa solo eso, está cerrado. Puede decir que Unity está roto debido al controlador cerrado, pero al final, si el controlador no funciona, no hay mucho que hacer. Las pruebas se realizan en los lanzamientos oficiales, pero eso no significa que funcionará para todos.

Tengo que decir que no creo que el rendimiento del controlador de código abierto sea tan bueno como el controlador cerrado, pero hablando de Ubuntu y Linux, queremos tener al menos la alternativa de que nuestro hardware se ejecute en condiciones mínimas con un controlador de código abierto.

Queremos asegurarnos de que, dada la opción, un usuario podrá ejecutar Unity sin muchas fallas en el controlador de código cerrado, pero lo más importante es que esté disponible un controlador de código abierto, bien construido y estable.

Con el controlador cerrado, puede abrir errores, quejas, ayudar a otros a informar datos para solucionar cualquier problema, pero al final, será responsabilidad del constructor establecer el camino para el desarrollo del controlador.

Por otro lado, el controlador cerrado es ampliamente compatible, los errores se toman más directamente en serio, el desarrollo se lleva a cabo, pero también se implementa la corrección de errores caso por caso. La comunidad de código abierto trabaja duro para que funcione lo mejor posible y con la menor cantidad de problemas posible.

Su tiempo es valioso para informar problemas en Unity que se ejecuta con el controlador cerrado, pero en mi humilde opinión, el controlador de código abierto se lo merece mucho más y obtendrá más valor por su esfuerzo para apoyarlo.