커널 업데이트 후 통합 GPU를 계속 사용할 수 있는지 확인하는 방법

통합 GPU는 새 커널이 이를 감지하고, 올바른 드라이버를 연결하며, 렌더 노드를 생성하고, 해당 노드를 워크로드에 노출할 때만 계속 사용할 수 있습니다.

홈 서버의 커널을 업데이트한 후 미디어 앱의 하드웨어 가속 스위치가 활성화된 상태에서도 소프트웨어 처리로 전환될 수 있습니다. 문제는 PCI 감지, 커널 모듈 연결, 펌웨어 로드, DRM 장치 생성, VA-API 초기화, 장치 권한, Docker 매핑 또는 미디어 서버의 FFmpeg 경로에서 발생할 수 있습니다. 애플리케이션 설정을 변경하기 전에 이러한 계층을 순서대로 확인하고 이전 부팅 상태와 비교하세요.

새 커널을 기록하고 PCI 버스에서 iGPU 확인하기

현재 실행 중인 커널 버전, 설치된 이전 커널, 부팅 매개변수 및 업데이트 시간을 기록하세요. 그런 다음 숫자 ID와 통합 GPU에 현재 연결된 커널 드라이버를 포함하여 디스플레이 클래스 PCI 장치를 나열하세요.

PCI 열거에서 iGPU가 보이지 않는다면 VA-API를 디버깅하기 전에 펌웨어 또는 BIOS 설정을 확인하세요. iGPU 또는 다중 모니터 옵션이 비활성화되면 서버에 외장 GPU만 표시될 수 있습니다. iGPU가 Linux에서 숨겨졌던 사례도 있습니다.

장치 ID와 연결된 드라이버를 마지막으로 정상 작동했던 부팅 상태와 비교하세요. Intel 시스템에서는 일반적으로 i915를 사용하며, 지원되는 최신 경로에서는 xe를 사용할 수 있습니다. 다른 플랫폼의 모듈 이름을 강제로 지정하지 말고 하드웨어와 배포판에 맞는 드라이버를 사용하세요.

드라이버 및 펌웨어 초기화를 위해 커널 로그 확인하기

현재 부팅 로그에서 GPU 드라이버, DRM, GuC 또는 HuC 펌웨어, 디스플레이 초기화, 프로브 실패, 시간 초과 및 모듈 블랙리스트 관련 항목을 검색하세요. 영구 로그를 사용할 수 있다면 이전 커널의 동일한 메시지와 비교하세요.

하드웨어가 목록에 표시되더라도 미디어 드라이버가 실패할 수 있습니다. Intel의 한 이슈에서는 주변 소프트웨어 스택이 변경된 후 통합 Xe-LPG GPU에서 VA-API 초기화가 실패했습니다. 이는 하드웨어가 감지되는 것만으로는 충분하지 않음을 보여줍니다.

필요한 펌웨어 패키지가 여전히 존재하는지, 새 커널 매개변수나 블랙리스트 또는 보안 부팅 정책으로 모듈이 차단되지 않았는지 확인하세요. 호스트 드라이버가 정상적으로 초기화될 때까지 미디어 서버를 재설치하지 마세요.

DRM 렌더 노드가 여전히 존재하는지 확인하기

/dev/dri를 검사하고 각 카드와 렌더 노드의 주 번호와 부 번호, 소유자, 그룹 및 심볼릭 링크 대상을 기록하세요. 다른 GPU가 존재할 때 iGPU가 항상 renderD128로 유지된다고 가정하지 마세요.

FFmpeg가 존재하지만 더 이상 유효한 VA 디스플레이를 제공하지 않는 노드를 대상으로 지정하면 하드웨어 가속이 실패합니다. Jellyfin 보고서에는 결정적인 오류인 렌더 장치에 대한 VA 디스플레이 없음이 나타납니다.

sysfs를 통해 렌더 노드를 해당 PCI 장치에 다시 매핑한 다음, 노드 ID가 실제로 변경된 경우에만 컨테이너 또는 애플리케이션 설정을 업데이트하세요. 777과 같은 광범위한 권한은 피하고 렌더 그룹 모델을 유지하면서 서비스 계정이 해당 그룹에 속해 있는지 확인하세요.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Docker를 사용하기 전에 호스트에서 VA-API 또는 Quick Sync 테스트하기

확인된 렌더 노드에 배포판의 VA-API 진단 도구를 실행하고 드라이버 이름, VA-API 버전, 지원되는 디코딩 프로필, 인코딩 진입점 및 비디오 처리 기능을 기록하세요.

사용자 공간 미디어 드라이버는 하드웨어 세대 및 커널 인터페이스와 일치해야 합니다. 해결된 한 Linux 사례에서는 커널 DRM 모듈과 사용자 공간 DRI 또는 VA 드라이버가 서로 다른 계층임을 강조합니다. 이를 혼동하면 잘못된 사용자 공간 드라이버가 남을 수 있습니다.

호스트에서 VA-API가 실패한다면 현재 미디어 드라이버 및 펌웨어 패키지를 업데이트 전 버전과 비교하세요. 호스트에서 VA-API가 성공한다면 컨테이너 경계로 이동하는 동안 커널과 드라이버를 변경하지 마세요.

컨테이너 내부에서 동일한 장치와 그룹을 확인하기

실행 중인 컨테이너의 장치, 그룹 ID 및 선택한 렌더 노드에 대한 액세스를 검사하세요. 호스트에서 성공했다고 해서 컨테이너에서도 성공한다는 의미는 아니므로 컨테이너 내부에서 미디어 서버에 포함된 VA-API 진단 도구 또는 FFmpeg 빌드를 실행하세요.

컨테이너에 /dev/dri/renderD128이 전달되더라도 프로세스에 일치하는 렌더 그룹 권한이 없으면 실패할 수 있습니다. Jellyfin 컨테이너 보고서는 장치 매핑과 그룹 액세스를 모두 검증해야 함을 보여줍니다.

호스트와 컨테이너의 숫자 그룹 ID를 비교한 다음, 필요한 경우 명시적인 장치 및 그룹 설정으로 서비스를 다시 생성하세요. ZimaSpace의 하드웨어 트랜스코딩 확인 가이드에서 다음 애플리케이션 수준의 검증 방법을 확인할 수 있습니다.

간단한 코덱 테스트를 강제하고 실제 GPU 엔진 확인하기

정상 작동이 확인된 H.264 또는 HEVC 샘플 하나를 사용하고 자막이나 HDR 톤 매핑 없이 비디오 트랜스코딩을 강제하세요. 대시보드 상태, FFmpeg 명령, 트랜스코딩 속도, CPU 사용량 및 GPU 디코드 또는 인코드 엔진 활동을 기록하세요.

미디어 서버가 하드웨어 지원을 보고하더라도 잘못된 VA-API 장치를 자동으로 선택할 수 있습니다. Jellyfin 이슈에는 장치를 명시적으로 선택했을 때 FFmpeg가 가속 경로를 감지하는 여부가 달라진 사례가 기록되어 있습니다.

가능하다면 디코드와 인코드를 পৃথ로 테스트하세요. 기본 코덱은 작동하지만 특정 코덱만 실패한다면 iGPU는 사용 가능하지만 해당 프로필, 펌웨어 기능, 드라이버 경로 또는 필터가 지원되지 않는 것입니다. 고급 톤 매핑 실패 하나만으로 GPU 전체가 누락되었다고 판단하지 마세요.

이전 커널을 통제된 비교 기준으로 사용하기

새 커널에서만 PCI 감지, 렌더 노드 또는 호스트 VA-API가 실패한다면 컨테이너 이미지, 미디어 서버 버전 또는 사용자 공간 설정을 변경하지 않고 설치된 이전 커널로 부팅하세요.

Jellyfin 문제 해결 사례에서는 커널 변경 이후 문제가 발생한 것으로 의심될 때 가장 간단한 판별 방법으로 커널 복귀를 권장합니다. 중요한 것은 롤백을 영구적인 해결책으로 간주하는 것이 아니라 통제된 커널 비교를 수행하는 것입니다.

현재 커널에서 iGPU가 PCI에 표시되고, 의도한 드라이버가 연결되며, 올바른 렌더 노드가 생성되고, VA-API가 초기화되며, 컨테이너 내부에 장치가 노출되고, 실제 코덱 테스트가 가속되면 검증이 완료된 것입니다. 이전 커널에서만 통과한다면 커널, 펌웨어 또는 미디어 드라이버의 회귀 문제를 분리하는 동안 이전 커널을 임시 부팅 옵션으로 유지하세요.