Las GPU de AMD de hace 22 años siguen recibiendo actualizaciones
Los controladores gráficos de código abierto siguen optimizándose para GPU ATI/AMD de principios de los 2000, lo que subraya cómo el software mantenido por la comunidad puede durar mucho más que el soporte oficial del fabricante. Los comentaristas contrastan esto con la ventana de soporte relativamente corta de AMD para arquitecturas más nuevas como Vega y Polaris, y con ecosistemas propietarios como CUDA de Nvidia, donde el hardware y las API antiguos se abandonan con mayor agresividad. El hilo se amplía hacia un debate sobre la obligación de publicar como código abierto los controladores y el firmware, la obsolescencia programada y si hacen falta regulación o competencia para mantener el hardware utilizable y ambientalmente sostenible durante más tiempo.
Lo que realmente se está actualizando
- Varios comentaristas señalan que el título es engañoso: las actualizaciones son para controladores Mesa de código abierto para GPU ATI/AMD de hace unos ~22 años, no para versiones oficiales de AMD.
- El hardware ya era compatible; el trabajo actual se centra en mejoras de rendimiento y funciones, en gran parte por contribuyentes individuales de la comunidad.
Experiencias con GPU antiguas y nuevas
- Muchos recuerdan con nostalgia las primeras tarjetas Radeon (por ejemplo, 9700 Pro, X1000/X1800, portátiles antiguos) y juegos clásicos.
- Algunos informan que los kernels modernos de Linux o Mesa rompen la compatibilidad con GPU de hace ~10–20 años, salvo que se usen rutas específicas (por ejemplo, EXA en lugar de Glamor).
- Otros planean probar GPU heredadas (por ejemplo, X1950 Pro) con las pilas actuales de Linux gracias a estas mejoras en los controladores.
AMD frente a Nvidia y soporte del fabricante
- Se elogia a AMD por publicar las especificaciones del hardware, permitir buenos controladores abiertos y seguir parcialmente estándares abiertos, especialmente en comparación con Nvidia.
- Al mismo tiempo, se critica a AMD por retirar o fragmentar el soporte de hardware relativamente reciente (Polaris, Vega, ROCm en RX 580), incluso mientras esos productos siguen vendiéndose.
- Los usuarios informan regresiones en controladores recientes de Windows para GPU AMD antiguas (por ejemplo, RX 580 + VR), y necesitan volver a ramas de controladores más antiguas.
Código abierto para controladores y firmware
- Hay una fuerte opinión de que los controladores (y a menudo el firmware) deberían estar obligatoriamente en código abierto después del fin de vida del hardware, o incluso desde el primer día.
- Argumentos a favor: mayor vida útil del hardware, mantenimiento por la comunidad, menos residuos electrónicos, evitación de limitaciones artificiales (impresoras, cámaras, grabadores de vídeo).
- Contraargumentos: enredos de propiedad intelectual/licencias, el código del controlador como “secreto comercial”, riesgo legal por patentes/derechos de autor, temor del fabricante a menores ventas y demandas.
Regulación, medio ambiente y obsolescencia programada
- Algunos abogan por normas ambientales y de compras (por ejemplo, ecoetiquetas) para forzar indirectamente la apertura y la longevidad.
- Otros describen industrias en las que los productos que siguen vendiéndose solo reciben un soporte simbólico, vinculándolo con la obsolescencia programada y la integración vertical de hardware + controladores.
Computación, ROCm y ecosistema de ML
- ROCm es nominalmente de código abierto, pero se percibe como desarrollado de forma torpe; el soporte oficial para GPU AMD antiguas se abandona rápidamente.
- Los esfuerzos de la comunidad (por ejemplo, rusticl, KFD, empaquetado/CI de distros) intentan mantener el cómputo usable en hardware Radeon antiguo.
- En ML, los comentaristas señalan la rápida depreciación de arquitecturas Nvidia antiguas (por ejemplo, Kepler), justificada por conjuntos de instrucciones de GPU que cambian con rapidez, pero frustrante para la experimentación básica en tarjetas antiguas.