Un cambio que se está evaluando actualmente para el controlador de gráficos del kernel de Linux”i915″de Intel facilitaría la creación de soporte de controlador para sus próximos productos de gráficos discretos para apuntar a otras arquitecturas de CPU que no sean x86 como Arm
Enviado hoy como una”solicitud de comentarios”eran parches que cambiaban el controlador de gráficos Intel Linux kernel para permitirle construir opcionalmente sin soporte para gráficos integrados, dejando al controlador solo capaz de admitir gráficos discretos. Mientras que los gráficos de Intel tradicionalmente se han centrado en sus gráficos integrados en sus procesadores, Intel se está moviendo fuerte y rápido para traer su soporte de gráficos discretos bajo Linux con DG2/Alchemist para las tarjetas gráficas Intel Arc, así como su acelerador Xe HPC.
Debido a que los gráficos integrados son parte de las CPU x86 de Intel, su controlador realmente no ha tenido que preocuparse por otras arquitecturas de CPU ya que tales combinaciones no han sido posibles. Pero ahora, con tarjetas gráficas discretas y sus aceleradores HPC, será posible tener gráficos Intel en, por ejemplo, una plataforma Arm, POWER o RISC-V. El cambio propuesto por esta serie de parches RFC permitiría construir el controlador de gráficos del kernel de Linux con solo ese soporte de gráficos discretos incluido.
La compatibilidad con gráficos integrados se compilaría fuera del controlador si se desactiva el conmutador DRM_I915_INTEGRATED_GPU_SUPPORT propuesto. A su vez, esto haría que el controlador fuera más pequeño al renunciar a las enormes cantidades de código en este controlador de kernel para admitir gráficos integrados de la era i915 a Gen12. Además, cualquier x86-ismo en la ruta del código de gráficos integrados a lo largo del tiempo se ignoraría y, por lo tanto, sería más fácil construir el controlador de gráficos Intel para otras arquitecturas de CPU.
La capacidad de crear un controlador de núcleo Intel solo para dGPU/eliminar la compatibilidad con iGPU es un poco más de cien líneas de código modificado, pero dados los comentarios del código, es probable que se revisen más antes de la línea principal. La primera serie de parches RFC para esta opción se puede encontrar en la lista de correo.
La serie de parches reconoce el interés en que las tarjetas gráficas discretas de Intel aparezcan potencialmente en los sistemas Arm,”truco [rápido] y sucio basado en algunas ideas antiguas. Pensé que tal vez el enfoque podría interesar a Arm muchachos del puerto”. No se sabe en este momento si los”chicos del puerto Arm”son un equipo dentro de Intel que trabaja en su soporte de gráficos para Arm o una referencia a la comunidad Arm Linux en general.
Esto es parte del beneficio de los controladores de código abierto: el código se puede adaptar y crear para otras arquitecturas de CPU en comparación con solo si el controlador se hiciera público como binario. Como resultado, las GPU AMD Radeon han gozado de popularidad con sus controladores de código abierto en POWER, MIPS y RISC-V y otras plataformas. Aunque, como se muestra al ejecutar los gráficos Radeon en RISC-V, puede haber obstáculos en torno a algunas GPU que no funcionan correctamente debido al firmware y otros problemas de codificación, en el pasado han surgido varios problemas de endianess para los gráficos Radeon en sistemas POWER9 libres, etc. Con Es probable que veamos tarjetas gráficas Intel Arc ejecutándose en placas de desarrollo Arm SBC y RISC-V o incluso Ponte Vecchio en servidores Arm robustos gracias a los controladores de código abierto y Linux.
Los controladores y la compatibilidad de Radeon de código abierto también han hecho posible disfrutar de sistemas POWER9 de código abierto con Raptor Computing Systems. Aunque al igual que las tarjetas gráficas AMD recientes, existen binarios de firmware necesarios para el hardware de gráficos Intel moderno con el controlador de código abierto. Intel, en cualquier caso, parece unirse a la fiesta para permitir que sus GPU discretas funcionen en otras arquitecturas de CPU bajo Linux.