Através de uma mudança no seu driver de kernel i915, a Intel quer facilitar a execução de seus gráficos discretos em ARM, e outras arquiteturas.
Uma mudança está sendo avaliada atualmente para o driver gráfico do kernel Linux “i915” da Intel que facilitaria a construção de suporte ao driver para seus próximos produtos gráficos discretos para direcionar outras arquiteturas de CPU não x86, como a Arm, por exemplo.
Intel quer facilitar a execução de seus gráficos discretos em ARM, e outras arquiteturas
Enviados hoje como um “pedido de comentários” foram os patches que alteram o driver gráfico Intel Linux kernel para permitir que ele seja construído opcionalmente sem suporte para gráficos integrados – deixando o driver apenas capaz de suporte gráfico discreto.
Enquanto os gráficos Intel têm sido tradicionalmente sobre seus gráficos integrados em seus processadores, a Intel está se movendo duro e rápido para trazer seu suporte gráfico discreto no Linux com as placas gráficas DG2/Alchemist para Intel Arc, bem como seu acelerador Xe HPC.
Como os gráficos integrados fazem parte dos processadores x86 da Intel, seu driver realmente não teve que se preocupar com outras arquiteturas de CPU, já que tais combinações não eram possíveis.
Mas agora com placas gráficas discretas e seus aceleradores HPC, será possível ter gráficos Intel em uma plataforma Arm, POWER ou RISC-V.
A mudança proposta por esta série de patches RFC permitiria construir o driver gráfico do kernel Linux com apenas esse suporte gráfico discreto incluído.
O suporte gráfico integrado seria compilado fora do driver se desabilitar a opção DRM_I915_INTEGRATED_GPU_SUPPORT proposta.
Por sua vez, isso tornaria o driver menor, renunciando às enormes quantidades de código neste driver de kernel para suportar gráficos integrados da era i915 até a Gen12.
Além disso, quaisquer x86-ismos no caminho do código gráfico integrado ao longo do tempo seriam ignorados e, portanto, mais fáceis de construir o driver gráfico Intel para outras arquiteturas de CPU.
A capacidade de criar um driver de kernel Intel somente para dGPU/remover o suporte a iGPU é pouco mais de cem linhas de código alterado, mas, considerando os comentários do código, provavelmente seriam revisados antes da atualização.
As primeiras séries de patches RFC para esta opção podem ser encontradas na lista de discussão.
A série de patches reconhece o interesse em ter placas gráficas discretas da Intel potencialmente aparecendo em sistemas Arm, “hack [rápido] e sujo baseado em algumas idéias antigas. Pensei que talvez a abordagem pudesse interessar os caras do porte Arm.”
Não se sabe neste momento se os “caras do porte do Arm” são uma equipe da Intel trabalhando em seu suporte gráfico para o Arm ou uma referência à comunidade Arm Linux em geral.
Isso faz parte do benefício dos drivers de código aberto é que o código pode ser adaptado e construído para outras arquiteturas de CPU em comparação com apenas se o driver foi tornado público como um binário.
As GPUs AMD Radeon desfrutaram de popularidade como resultado de seus drivers de código aberto no POWER, MIPS e RISC-V e em outras plataformas.
Embora, como mostrado pela execução de gráficos Radeon no RISC-V, possa haver obstáculos em torno de algumas GPUs que não funcionam corretamente devido a problemas de firmware e outros problemas de codificação, vários problemas de endianess surgiram no passado para gráficos Radeon em sistemas POWER9 livres, etc., provavelmente veremos placas gráficas Intel Arc rodando em placas de desenvolvimento Arm SBCs e RISC-V ou até mesmo Ponte Vecchio em robustos servidores Arm, graças a drivers de código aberto e Linux.
Os drivers/suporte radeon de código aberto também permitiram desfrutar de sistemas POWER9 de código aberto com sistemas de computação Raptor.
Embora, como as placas gráficas recentes da AMD, há binários de firmware necessários para o hardware gráfico Intel moderno com o driver de código aberto.
A Intel, em qualquer caso, parece se juntar ao partido por permitir que suas GPUs discretas trabalhem em outras arquiteturas de CPU sob Linux.