npu-render 저장소는 윈도우 11의 데스크톱 화면을 그래픽카드 대신 인텔 NPU에서 렌더링하는 연구용 디스플레이 드라이버다. 실제 데스크톱을 수십 분 동안 렌더링하고 GPU 화면으로 복구할 수 있지만, 초당 2~3회 화면 갱신에 그쳐 제품이 아닌 연구 프로토타입이다.
2026년 10월 22일 기준, 프로젝트는 Explorer, 시작 메뉴, 메모장, WPF와 Edge 창을 실제로 렌더링한다. 커널이 실행하는 작업은 호스트 기준 화면과 픽셀 단위로 일치하며, 요청하면 GPU 데스크톱으로 되돌릴 수 있다. 다만 목표인 30Hz에 비해 검증된 화면 갱신은 초당 2~3회뿐이다. 블러가 포함된 합성 작업은 수초가 걸린다. 아래 수치는 모두 인텔 Panther Lake 노트북 한 대에서 측정했다.
화면 전환과 측정 결과
화면 전환 기록에는 데스크톱 화면 녹화가 있다. 녹화는 npu-render desktop enable 한 번으로 시작한 660초간의 실행과 disable이 수행하는 복구를 담았다. 데스크톱에서는 창 하나가 계속 30Hz로 다시 그려져 합성 비용을 측정할 수 있게 했다. 영상은 실제 시간보다 세 배 빠르게 재생된다.
옆 패널은 같은 1초 동안의 Windows GPU Engine 성능 카운터와 실행 중 수집한 프레임 기록을 바탕으로 만들었다. 데스크톱 안의 작은 오버레이도 같은 카운터를 실시간으로 표시하며, 그 오버레이 자체는 당시 데스크톱을 합성하는 어댑터가 그린다.
GPU가 데스크톱을 합성할 때 GPU 3D 엔진 사용률은 3.4%(그중 DWM에서 2.8%)였고 NPU는 0%였다. 전환 뒤에는 NPU가 만든 1024x768 프레임을 화면 크기에 맞춰 표시했다. 실행 기간의 중앙값으로 NPU 엔진 사용률은 58%였으며, 이는 작업 관리자의 NPU 그래프가 읽는 것과 같은 카운터 집합의 Neural 엔진 인스턴스에서 가져온 수치다. 화면에 도달한 프레임은 초당 1.6개로, 실행 기간 전체에서 969개였다. GPU 3D 엔진 사용률은 0.6%로 떨어졌고, 그중 0.4%는 NPU 프레임을 실제 화면에 표시하도록 미러링하는 창을 DWM이 합성하는 데 쓰였다. 30Hz 창은 측정 자극이며 NPU가 합성하는 속도는 30Hz가 아니라 표시된 수치다.
프로젝트의 질문과 구현
프로젝트가 묻는 질문은 좁고 검증 가능하다. 새 노트북에는 NPU가 들어가지만, 데스크톱 합성과 브라우저 실행, 점점 늘어나는 로컬 모델 실행은 GPU가 맡는다. 애플리케이션이나 합성기에는 알리지 않은 채 NPU가 데스크톱 합성 전체를 대신할 수 있는지가 핵심이다.
지금까지의 답은 정확하게 대신할 수는 있지만 빠르지는 않다는 것이다. 이 장비에서는 30Hz 창을 계속 띄웠을 때 NPU 유무와 관계없이 합성기 자체가 GPU 3D 엔진에 주는 부하가 작았다. p99 사용률은 0.4% 미만이었으므로 이 작업량에서 ‘GPU 여유 확보’는 측정되지 않았다. 두 결과 모두 원시 근거와 함께 보고서에 공개돼 있다.
구현 개요는 다음과 같다.
flowchart LR
DWM["Desktop Window Manager<br/>Direct3D 10 draws"] --> UMD["npu-render user-mode driver<br/>records draws into frame batches"]
UMD -- "named pipe, per-process lease" --> Worker["Worker<br/>resident surfaces, texel-window planner"]
Worker -- "12 tiles per request" --> NPU["Intel NPU<br/>SHAVE kernel inside an OpenVINO blob"]
NPU --> Worker
Worker --> IDD["Indirect display driver"]
IDD --> Panel["Physical panel"]
Broker["Resident broker<br/>admits applications, renews leases"] -.-> UMD
Recovery["Scheduled recovery task<br/>restores the GPU desktop"] -.-> DWM
동작은 다섯 단계로 구성된다.
- 실행 대신 기록하는 드라이버. 윈도우는 등록된 디스플레이 어댑터의 Direct3D 10 사용자 모드 드라이버로 npu-render를 불러온다. 셰이더, 상수, 텍스처, 블렌드와 뷰포트가 모두 확정된 상태로 도착한 각 그리기·지우기 명령을 현재 프레임 배치에 추가한다. 배치는 Present, Flush, 스테이징 맵, 샘플링 리소스에 대한 CPU 쓰기처럼 윈도우가 이미 정한 순서 경계에서 전송한다. 드라이버는 모든 비공개 표면의 호스트 측 사본과 버전 카운터를 유지해 작업자에게 바뀐 부분만 보낸다.
- NPU 연산 안에 넣은 래스터라이저. OpenVINO는 NPU용 소형 ScatterElementsUpdate 모델을 컴파일한다. 컴파일된 블롭에는 해당 연산의 SHAVE 코드가 텍스트 영역에 들어 있다. npu-render는 SHAVE 도구로 자체 래스터라이저를 컴파일한다. 여기에는 정점 셰이딩, 스캔라인 영역 판정, 두 텍셀 창을 사용하는 쌍선형 샘플링, 합성기의 블렌드 모드가 포함된다. 그런 다음 ELF와 플러그인의 메타데이터 트레일러를 수정해 코드 창을 24KB에서 48KB로 늘리고 래스터라이저를 그 창에 넣는다. 모델의 입력·출력 텐서는 추론 한 번에 각각 258KB 크기의 12개 구간이 되며, 타일 하나씩 여섯 개 SHAVE 엔진에서 처리한다. NPU 드라이버와 펌웨어는 이를 다른 모델과 같은 방식으로 실행한다.
- 미리 컴파일하는 합성기 셰이더. DWM과 WinUI가 실제로 쓰는 셰이더 쌍 38개를 한 번 캡처한다. 여기에는 단색·텍스처 사각형, Mica·acrylic 배경, 블러, 정수 바이트 버퍼와 팔레트를 이용한 텍스트, 이중 소스 캡션 텍스트가 포함된다. 셰이더를 SM4 바이트코드에서 소형 중간 표현으로 낮춘 다음, 커널 안에서 실행할 C 행 함수로 만든다. 각 셰이더는 호스트의 SM4 기준 구현과 비트 단위로 비교한 뒤 장치에서도 테스트 픽스처별로 검사한다. 픽스처 결과가 다르면 해당 블롭은 작업자 시작 시 제외하고, 프로그램은 더 느린 그리기별 경로를 이용한다. 그 사실도 보고서에 공개하며 숨기지 않는다.
- 타일에 필요한 데이터 계획. 258KB 구간에 전체 텍스처를 넣을 수 없으므로 작업자는 픽셀 프로그램의 구간 산술을 이용해 각 타일의 텍셀 읽기 범위를 계산한다. 직접 샘플링에는 삼각형마다 평면을 맞추고, 글리프나 작업 표시줄 아이콘이 아틀라스 곳곳에 있는 경우에는 그 전체 범위를 한꺼번에 묶는 대신 몇 개의 작은 창으로 나눠 처리하도록 그리기 삼각형을 그룹화한다. 드라이버는 작업자가 데이터를 묶는 것과 같은 코드로 그리기 요청을 허용하므로 두 쪽의 판단이 어긋나지 않는다.
- 허용 절차, 임대와 복구. 프로세스별 임대에는 제어기·작업자·소비자 식별자, 기한과 논스가 포함되며 모든 드라이버 호출은 임대가 있어야 가능하다. 상주 브로커가 일반 프로세스를 자동으로 허용하고 임대를 갱신한다. 작업자가 종료되면 합성기의 임대를 유지한 채 1초 안에 새 작업자로 교체한다. 예약된 작업은 요청이 있거나 오류가 발생하면 장치, 패키지와 추적 자료를 해제하고 GPU 데스크톱을 복구한다.
시험 결과와 한계
측정 기준은 인수 계획에 따른다. 장비는 Delta(인텔 Panther Lake, Windows 11, NPU 드라이버 5540, OpenVINO 2026.4.1)다. 최신 결과는 trial 31과 애플리케이션 프로브 v115~v121이며, 프레임 배치 실시간 시험 보고서에 정리돼 있다.
- 라우팅: 등록, 허용, 표시와 복구가 end-to-end로 통과했다(trial 11·12). 드라이버와 작업자는 하나의 공유 선택 로직으로 각 대체 경로를 정했으며 불일치는 없었다.
- 연속 렌더링: trial 12에서 데스크톱을 NPU로 2,160초 렌더링했다. 프레임 배치 744개, 명령 9,363개를 처리했고 자체 테스트 불일치와 작업자 표준 오류는 모두 0이었다. 번들 v23부터 블러를 포함한 캡처 프로그램은 모두 커널에서 실행된다. 프로브 v121에서는 어떤 배치에서도 대체 경로를 쓰지 않았다.
- 실제 화면 표시: trial 12에서 실제 화면으로 제출한 프레임은 342개였다. 37분 동안 GPU 3D 엔진 사용률 p99는 0.37%였다. 30Hz 창 자극을 준 GPU 데스크톱 대조군에서도 p99가 같아 엔진 사용량 절감은 주장하지 않는다.
- 상호작용과 복구: 제어 입력, 정리와 복구 시험은 통과했다. 화면 보호기 실행과 작업자 손실에도 DWM은 살아남았다. 애플리케이션 창이 있을 때 합성기 장치가 반복 교체되는 현상은 거부된 그리기 원인 세 가지를 추적해 해결했으며, 프로브 v120부터 허용 한 건당 장치 하나만 사용한다. 오류 없이 유지된 최장 허용 시간은 40분이다. 아직 남은 문제도 있다. 애플리케이션 창을 연 허용 절차 뒤에 토폴로지와 합성기는 돌아왔지만 창 배치 복구는 프로브 v121에서 14개 중 7개만 복구했고 전경 창도 복원하지 못했다. 그래서 전환 명령의
status는 이 단계를 실패로 표시한다. 절전 후 다시 깨우는 동작도 미해결이다. - 응답성: 목표를 충족하지 못했다. 1024x768에서 30Hz·300회 갱신 자극에 대해 검증된 갱신은 초당 2.5회였다. 마우스 입력 전송부터 화면 표시까지 걸린 시간은 중앙값 94ms, p95 1.5초였다. 합성기 배치는 수십 밀리초가 걸리고 블러 프로그램이 포함되면 수초가 걸린다. SHAVE 하나에서 픽셀당 수십 마이크로초가 소요된다.
- 애플리케이션 지원 범위: 일반 프로세스는 자동으로 허용되며 요청 실패 없이 처리됐다. 대상에는 Explorer, 시작 메뉴, 메모장, 입력 호스트와 WinUI 앱이 포함된다. WPF와 Edge는 자체 표면을 이용해 합성되며 해당 어댑터를 열지 않는다. 드문 합성기 프로그램 두 개는 여전히 그리기별 경로를 이용하고, 캡처된 프로그램 하나는 장치 빌드에서 잘못 컴파일돼 제외돼 있다.
- GPU 부담 경감: 입증되지 않았다. 엔진 샘플은 합성이 GPU 3D 엔진에서 옮겨갔다는 점은 보여주지만, 다른 작업이 그만큼 이득을 얻었다는 점은 보여주지 않는다.
- 사용 가능한 전환: Delta에서
npu-render desktop install --prepare,enable,status,disable을 모두 실행했다. 고정 버전은 최신 적격 빌드를 가리킨다.
커널 경로의 정확성은 장치에서 검사한다. 번들 v23의 픽스처 234개를 포함해 각 블롭의 픽스처를 호스트 기준 구현과 픽셀 단위로 비교한다. 녹화된 데스크톱 캡처도 프레임 배치 경로로 재생해 기준 구현과 허용 오차 안에서 비교한다. CPU 검사나 그래프 호출 지연 시간만으로 NPU 실행이라고 보고하지 않는다.
사용 조건과 명령
사용 안내에 따르면 Windows 11과 OpenVINO NPU 플러그인이 지원하는 인텔 NPU, 테스트 서명 모드, 관리자 권한, 지정된 OpenVINO SDK와 네이티브 빌드용 WDK 헤더가 필요하다. 커널 번들을 만들려면 SHAVE 도구도 필요하며, 이 도구는 저장소에서 배포하지 않는다. 실행하면 디스플레이가 전환되고 복구 작업이 합성기를 다시 시작할 수 있다. 문제가 생기면 몇 분간 쓸 수 있는 데스크톱이 없을 수 있으므로 다른 경로로 접근할 수 있는 장비에서 실행해야 한다.
uv sync --frozen
npm ci && npm run hooks:install
uv run pytest && uv run ruff check . && uv run ruff format --check .
대상 장비에서는 빌드된 트리, 서명된 패키지와 적격 커널 번들이 필요하다. tools/delta/make_trial_chain.py가 버전이 붙은 스크립트를 생성하며, 각 단계는 시험 보고서에 기록된다.
npu-render desktop install --prepare # package, sign and register the pinned build
npu-render desktop enable # launch an admission under the resident broker
npu-render desktop status # what the NPU renders, since when, batches, fallbacks
npu-render desktop disable # stop the admission and run its recovery
저장소와 개발 절차
저장소 구성은 다음과 같다.
native/windows/registered_lab: 등록된 D3D10 사용자 모드 드라이버, NPU 작업자, 배치 계획기와 프로토콜, 호스트 기준 커널, 계약 테스트.native/windows/ptl_kernels: SHAVE 커널 소스.frame_core.h는 장치 커널과 호스트 기준 구현 양쪽에 쓰인다.native/: C ABI, OpenVINO 제공자, 앞선 합성기 작업에서 만든 제한형 Weston 어댑터.src/npu_render: Python 런타임과 CLI. 데스크톱 전환, 백엔드 선택, 진단, 캐리어 도구가 들어 있다.tools/와tools/delta/: 빌드, 적격성 평가, 재생과 시험 체인 생성 도구.tools/delta/trial-chain에는 현재 생성된 체인이 있다.docs/research와docs/validation: 보고서와 원시 근거.
개발 안내에서는 Python 도구에 uv를 사용하고, 체크아웃마다 한 번 npm run hooks:install로 커밋 훅을 설치하도록 안내한다. 모든 커밋은 Conventional Commits 형식을 따르며 CI는 우회 없이 전체 커밋 이력을 검사한다. 자세한 내용은 CONTRIBUTING.md에 있다.
네이티브 트리는 CMake를 사용한다. 다음 명령은 고정된 OpenVINO 휠을 이용해 build/native에 C ABI와 테스트를 빌드한다.
uv run --group native python tools/build_native.py
Windows 드라이버와 작업자는 native/windows/registered_lab에서 MSVC, 고정된 OpenVINO SDK와 WDK 헤더를 사용해 설정한다. 계약 테스트는 ctest에 등록된다. tools/build_registered_lab.py는 설치나 서명 없이 깨끗한 빌드와 테스트를 수행한다. 대상 장비에서는 tools/delta/build_native_tree.ps1가 같은 트리를 번호가 붙은 빌드로 만든다.
커널 번들은 tools/frame_blobs.py가 캡처 인벤토리에서 블롭별 헤더와 픽스처, 단일 파일 SHAVE 소스를 생성한다. 대상 장비에서 tools/build_ptl_kernel.py가 요구하는 고정 SHAVE 도구로 블롭을 컴파일한다. 캐리어에는 tools/delta/create_frame_carrier.py로 컴파일한 뒤 tools/delta/grow_frame_carrier.py로 코드 창을 두 배로 늘려 넣고, tools/delta/qualify_frame_kernel.py로 NPU에서 픽스처별 적격성 평가를 한다.
시험은 직접 편집하지 않고 생성한다. tools/delta/make_trial_chain.py가 빌드, 패키지, 버전과 커널 번들에 고정된 다음 번호의 체인을 만든다. 체인에는 패키지 서명, 등록 적격성 평가, 임대 갱신을 포함한 데스크톱 허용, 실시간 표시와 복구가 포함된다.
근거와 이력 보고서는 docs/research에 있다. 여기에는 인수 계획, 프레임 배치 시험, 전환 설계, 렌더러·커널 기록과 초기 원리 검토, 합성기·지원 범위 연구가 포함된다. 2026년 10월 20일까지의 시험 원시 근거는 docs/validation/<date>/<trial>에 있다. 프레임 배치 시험의 캡처, 로그와 엔진 샘플은 대상 장비에 보관하며, 시험 보고서가 각 실행을 가리킨다. 이전 측정은 당시 기록 그대로 보존하고 새 결과는 새 보고서에 추가한다.
제약과 라이선스
제약 사항은 다음과 같다.
- 모든 커밋은 Conventional Commits 1.0.0을 따르며 훅과 CI가 우회 없이 이를 적용한다. CONTRIBUTING.md와 AGENTS.md를 참고하면 된다.
- 모델 가중치, 컴파일된 장치 캐시와 캐리어, SHAVE 도구, 자격 증명, 비공개 장비 주소와 가상 환경은 커밋하지 않는다.
- CPU 검사와 그래프 호출 지연 시간은 NPU 실행, 화면 프레임 전달 또는 성능 개선의 증거로 제시하지 않는다.
- 장치 대체 경로를 숨기거나 지원하지 않는 작업을 이전했다고 주장하지 않는다. 대체 경로 실행에 실패하면 현재 렌더러를 유지한다.
- 가능한 경우 실제 하드웨어에서 장치 변경을 검증하며, 하드웨어를 사용할 수 없으면 그 사실을 명시한다.
- 보안 문제는 SECURITY.md를 통해 접수한다.
프로젝트는 Apache License 2.0을 따른다. 기반이 된 제3자 작업은 LICENSE와 NOTICE에서 확인할 수 있다.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요