Como verificar se uma GPU integrada continua disponível após uma atualização do kernel
Uma GPU integrada só fica disponível quando o novo kernel a deteta, associa o controlador correto, cria nós de renderização e os disponibiliza à carga de trabalho.
Após uma atualização do kernel de um servidor doméstico, uma aplicação multimédia pode recorrer ao software mesmo que a opção de aceleração por hardware continue ativada. A falha pode ocorrer na deteção PCI, na associação do módulo do kernel, no carregamento do firmware, na criação do dispositivo DRM, na inicialização da VA-API, nas permissões do dispositivo, no mapeamento do Docker ou no caminho do FFmpeg do servidor multimédia. Verifique essas camadas por ordem e compare-as com o arranque anterior antes de alterar as definições da aplicação.
Registe o novo kernel e confirme a iGPU no barramento PCI
Registe a versão do kernel em execução, os kernels anteriores instalados, os parâmetros de arranque e a hora da atualização. Em seguida, liste os dispositivos PCI da classe de visualização com IDs numéricos e o controlador do kernel atualmente associado à GPU integrada.
Se a iGPU estiver ausente da enumeração PCI, verifique as definições do firmware ou da BIOS antes de investigar a VA-API. Um servidor pode expor apenas uma GPU dedicada quando a opção da iGPU ou de vários monitores está desativada, como demonstrado num caso em que a iGPU estava oculta no Linux.
Compare o ID do dispositivo e o controlador associado com o último arranque conhecido como funcional. Nos sistemas Intel, este é normalmente o i915 ou, em caminhos mais recentes compatíveis, o xe; utilize o controlador realmente destinado ao hardware e à distribuição, em vez de forçar o nome de um módulo de outra plataforma.
Leia os registos do kernel para verificar a inicialização do controlador e do firmware
Procure no registo do arranque atual o controlador da GPU, o DRM, o firmware GuC ou HuC, a inicialização da visualização, falhas de deteção, tempos limite e listas negras de módulos. Compare as mesmas mensagens do kernel anterior, se estiverem disponíveis registos persistentes.
Uma falha do controlador multimédia pode ocorrer mesmo quando o hardware está listado. Um problema da Intel documenta uma falha de inicialização da VA-API numa GPU integrada Xe-LPG após alterações na restante pilha de software, demonstrando que detetar o hardware não é suficiente.
Confirme que os pacotes de firmware necessários continuam presentes e que o módulo não está bloqueado por um novo parâmetro do kernel, uma lista negra ou uma política de arranque seguro. Não reinstale o servidor multimédia até o controlador do anfitrião inicializar corretamente.
Confirme que o nó de renderização DRM continua a existir
Inspecione /dev/dri e registe os números major e minor, proprietários, grupos e destinos das ligações simbólicas de cada placa e nó de renderização. Não presuma que a iGPU permanecerá sempre como renderD128 quando existe outra GPU.
A aceleração por hardware falha quando o FFmpeg aponta para um nó que existe, mas que já não fornece um ecrã VA válido. Um relatório do Jellyfin apresenta o erro decisivo: não existe ecrã VA para o dispositivo de renderização.
Associe o nó de renderização ao respetivo dispositivo PCI através do sysfs e atualize a configuração do contentor ou da aplicação apenas se a identidade do nó tiver realmente mudado. Evite permissões abrangentes, como o modo 777; mantenha o modelo do grupo de renderização e confirme a pertença da conta de serviço.
Teste a VA-API ou o Quick Sync no anfitrião antes do Docker
Execute a ferramenta de diagnóstico de VA-API da distribuição contra o nó de renderização verificado e registe o nome do controlador, a versão da VA-API, os perfis de descodificação suportados, os pontos de entrada de codificação e as capacidades de processamento de vídeo.
O controlador multimédia do espaço do utilizador tem de corresponder à geração do hardware e à interface do kernel. Um caso resolvido no Linux salienta que os módulos DRM do kernel e os controladores DRI ou VA do espaço do utilizador são camadas separadas; confundi-los pode deixar o controlador errado do espaço do utilizador instalado.
Se a VA-API falhar no anfitrião, compare os pacotes atuais do media-driver e do firmware com as versões anteriores à atualização. Se a VA-API funcionar no anfitrião, mantenha o kernel e o controlador inalterados enquanto avança para o limite do contentor.
Verifique o mesmo dispositivo e os mesmos grupos dentro do contentor
Inspecione os dispositivos, os IDs dos grupos e o acesso ao nó de renderização escolhido no contentor em execução. Execute o diagnóstico de VA-API ou a compilação do FFmpeg incluída no servidor multimédia dentro do contentor, pois o sucesso no anfitrião não garante o sucesso no contentor.
Um contentor pode receber /dev/dri/renderD128 e ainda assim falhar porque o processo não tem a permissão correspondente do grupo de renderização. Um relatório de um contentor Jellyfin demonstra que o mapeamento do dispositivo e o acesso ao grupo têm de ser ambos validados.
Compare os IDs numéricos dos grupos no anfitrião e no contentor e, se necessário, recrie o serviço com uma configuração explícita do dispositivo e dos grupos. O guia da ZimaSpace sobre verificação da transcodificação por hardware fornece a prova seguinte ao nível da aplicação.
Force um pequeno teste de codec e observe os motores reais da GPU
Utilize um exemplo H.264 ou HEVC conhecido como funcional e force uma transcodificação de vídeo sem legendas nem mapeamento de tons HDR. Registe o estado do painel, o comando do FFmpeg, a velocidade da transcodificação, a utilização do CPU e a atividade dos motores de descodificação ou codificação da GPU.
Um servidor multimédia pode indicar suporte de hardware, mas selecionar automaticamente o dispositivo VA-API errado. Um problema do Jellyfin documenta um caso em que a seleção explícita do dispositivo alterou a deteção do caminho de aceleração pelo FFmpeg.
Teste a descodificação e a codificação separadamente, quando possível. Se um codec falhar enquanto um codec básico funcionar, a iGPU está disponível, mas esse perfil, funcionalidade do firmware, caminho do controlador ou filtro não é compatível. Não conclua que toda a GPU está ausente devido a uma única falha avançada de mapeamento de tons.
Utilize o kernel anterior como comparação controlada
Se a deteção PCI, os nós de renderização ou a VA-API do anfitrião falharem apenas no novo kernel, arranque com o kernel anterior instalado sem alterar a imagem do contentor, a versão do servidor multimédia ou a configuração do espaço do utilizador.
Um caso de resolução de problemas do Jellyfin recomenda reverter o kernel como o discriminador mais simples quando se suspeita que a falha surgiu após uma alteração do kernel. O valor está numa comparação controlada do kernel, e não em tratar a reversão como solução permanente.
A verificação está concluída quando o kernel atual mostra a iGPU no PCI, associa o controlador pretendido, cria o nó de renderização correto, inicializa a VA-API, expõe o dispositivo dentro do contentor e acelera um teste real de codec. Se apenas o kernel anterior passar, mantenha-o como opção de arranque temporária enquanto isola a regressão do kernel, do firmware ou do media-driver.
Produtos recomendados
Suporte e Dicas
Mais para Ler
O Plex pode partilhar uma GPU com outro contentor Docker?
O Plex e outro contentor conseguem frequentemente aceder à mesma GPU, mas é necessário testar o suporte dos controladores, o mapeamento de dispositivos, a...
Como saber se um erro do Plex vem do cliente ou do servidor
Reproduza o mesmo item noutro cliente, compare o percurso da sessão e, em seguida, recolha provas do servidor apenas depois de o âmbito lhe...
Como configurar a cache do Plex e o armazenamento temporário de transcodificação
Proteja o estado persistente do Plex enquanto coloca os ficheiros temporários de transcodificação num armazenamento local adequado e, em seguida, verifique a limpeza, o...
