# Linux 입력 지연 측정: X11 대 Wayland, VRR, DXVK > Clean Markdown view of GeekNews topic #31465. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=31465](https://news.hada.io/topic?id=31465) - GeekNews Markdown: [https://news.hada.io/topic/31465.md](https://news.hada.io/topic/31465.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-07-16T00:36:08+09:00 - Updated: 2026-07-16T00:36:08+09:00 - Original source: [marco-nett.de](https://marco-nett.de/blog/measuring-input-latency-on-linux-x11-vs-wayland-vrr-dxvk/) - Points: 1 - Comments: 1 ## Topic Body - 500Hz 디스플레이에서 클릭부터 화면 밝기 변화까지 측정한 결과, X11·VRR·dxvk-low-latency를 모두 적용해도 기본 Wayland보다 **종단 간 지연 중앙값**이 0.72ms 낮아지는 데 그침 - 네이티브 Wayland는 X11보다 **0.14~0.22ms** 느린 반면, XWayland는 네이티브 Wayland 대비 최대 **3.13ms**를 추가해 훨씬 큰 차이를 만듦 - **가변 주사율(VRR)** 은 모든 비교에서 지연을 0.26~0.45ms 줄였고, p5~p95 분포 폭도 2.6~3.0ms에서 2.1~2.2ms로 좁힘 - **dxvk-low-latency**는 프레임 제한 시 0.10~0.29ms, 제한 해제 시 0.84ms를 줄였지만, 후자에서는 GPU 사용률을 100% 대신 95~97%로 유지하면서 FPS가 715에서 670으로 감소함 - 결과는 안정적인 FPS와 CPU 병목이라는 **최적 조건** 및 특정 하드웨어·소프트웨어 조합에서 나온 것으로, 실제 플레이에서는 VRR의 지터 감소와 프레임 페이서의 렌더 큐 억제가 중앙값 이상의 차이를 만들 수 있음 --- ### 최적화 조언을 직접 검증한 이유 - Linux 게이밍에는 Wayland 대신 X11 사용, 합성 비활성화, 지연 최적화 DXVK 포크, 게임용 커널 스케줄러, gamescope·gamemode·환경변수 적용 등 수많은 최적화 조언이 존재함 - 경쟁형 FPS에서는 낮은 지연, 일관된 프레임 시간, 높은 FPS가 중요하지만, 설정 변경이 실제 개선인지 **플라세보 또는 역효과**인지 확인하기 어려움 - 측정 장치의 하드웨어, 인클로저, 펌웨어, 분석 코드와 원시 데이터는 [click2photon GitHub 저장소](https://github.com/marconett/click2photon)에 공개돼 있음 ### 클릭부터 화면 변화까지 재는 장치 - 모니터에 장치를 부착하고 USB로 마우스 클릭을 발생시킨 뒤, 광센서가 화면 변화를 감지할 때까지 시간을 재서 **종단 간 시스템 지연**을 측정함 - 초기 설계는 당시 이용할 수 있던 [OSLTT](https://github.com/OSRTT/OSLTT)의 회로도를 참고했으며, 완성 과정에서 [m2p-latency](https://github.com/davidramiro/m2p-latency)와 [Open-Source-LDAT](https://github.com/S4N-T0S/Open-Source-LDAT)의 아이디어도 통합함 - 제작에는 마이크로컨트롤러, 납땜, Arduino 펌웨어, 적분 시간, 트랜스임피던스 증폭기, KiCad와 인클로저 설계가 필요했음 - **Adafruit QT Py RP2040**이 1,000Hz 폴링 USB HID 마우스로 동작하며 클릭을 발생시킴 - 클릭 전송 직후부터 약 24µs마다 광다이오드 표본을 수집함 - 클릭마다 12,000개 표본을 직렬 연결로 호스트에 보내 CSV로 기록함 - 호스트 도구는 클릭별 기준선을 계산하고, 기준선에서 일정 수준 이상 벗어난 첫 표본을 찾음 - 12,000개 표본의 수집 시간이 고정돼 있어 클릭 전송부터 화면 밝기 변화까지 걸린 시간을 계산할 수 있음 ### 비교한 화면·렌더링 구성 - **X11과 네이티브 Wayland**를 비교해 Wayland가 체감상 느리다는 평가를 계측 결과와 대조함 - G-Sync·FreeSync를 포함하는 **가변 주사율(VRR)** 의 활성화 여부를 비교함 - [dxvk-low-latency](https://github.com/netborg-afps/dxvk-low-latency)와 기본 DXVK의 차이를 측정함 - 이 포크의 프레임 페이서는 공식 `proton-cachyos` 패키지에 통합됐으며, `PROTON_DXVK_LOWLATENCY=1`로 활성화함 - 프레임 페이서가 프레임 시간 변동을 흡수하고 렌더 큐 누적을 막는지 확인하기 위해 **FPS 제한 해제** 사례 2개를 추가함 - 정적인 게임 장면에서는 프레임 시간 변동이 없었고 테스트도 CPU 병목 조건이어서 실제 게임 세션을 완전히 반영하지 않음 - 실제 세션에서는 게임 내부 상황이나 다른 프로세스의 자원 사용에 따라 프레임 시간이 달라질 수 있음 - Wayland 테스트는 기본적으로 `PROTON_ENABLE_WAYLAND=1`을 사용한 네이티브 Wayland에서 실행했으며, 비교를 위해 VRR을 끈 **XWayland** 사례 2개도 측정함 ### 테스트 하드웨어와 소프트웨어 - 테스트 중에는 디스플레이 한 대만 연결했으며 하드웨어 구성은 다음과 같음 - AMD Ryzen 7 5800X3D - NVIDIA GeForce RTX 4070 SUPER - DDR4 3,200MHz 8GB 모듈 2개 - MSI MAG 272QP QD-OLED X50, 2560×1440, 500Hz - MSI B450 GAMING PRO CARBON AC - **소프트웨어 스택**은 CachyOS, Kernel 7.1.3-2-cachyos, NVIDIA driver 610.43.03-1, KDE Plasma 6.7.2-1.1, xorg-server 21.1.24-1.1로 구성함 - `proton-cachyos-native` 1:11.0.20260602-3와 `dxvk` 3.0을 사용함 - CachyOS 기본 커널 스케줄러를 유지함 ### 디스플레이와 DXVK 설정 - 시스템 주사율은 **500Hz**로 설정함 - X11에서는 `nvidia-settings`로 플립 모드와 VRR을 활성화했으며, VRR 변경에는 재부팅이 필요함 - Wayland에서는 KDE 설정으로 VRR을 활성화하며 재부팅은 필요하지 않음 - Wayland의 플립 모드 또는 **직접 스캔아웃**은 사용자가 직접 설정하지 않고 컴포지터가 프레임마다 결정함 - KWin Debug Console의 Effects 탭에서 `showcompositing`을 활성화함 - 게임만 전체 화면에 표시하고 완전히 포커스된 상태에서 가장자리에 빨간 테두리가 없으면 플립 모드로 판별함 - 비교 조건별로 최적화한 `dxvk.conf`를 사용함 - VRR 비활성화 시 `dxgi.maxFrameRate = 500` - VRR 활성화 및 dxvk-low-latency 비활성화 시 `dxgi.maxFrameRate = 497` - VRR과 dxvk-low-latency를 함께 활성화할 때는 다음 설정으로 500Hz용 저지연 VRR 프레임 페이싱을 사용함 ```ini dxgi.maxFrameRate = 480 dxvk.lowLatencyOffset = 70 dxvk.framePace = "low-latency-vrr-500" dxvk.lowLatencyAllowCpuFramesOverlap = False ``` - 모든 구성에 `d3d11.cachedDynamicResources = "c"`를 적용함 ### 게임 환경과 반복 측정 절차 - 테스트 게임은 Heroic과 Proton으로 실행한 **DirectX 11** 게임 [Diabotical](https://store.epicgames.com/en-US/p/diabotical)임 - 네이티브 해상도와 100% 렌더 배율을 사용하고 Vsync를 끈 뒤, 나머지 영상 설정은 가능한 한 낮춤 - UI를 잠시 숨기는 숨겨진 명령을 `/bind mouse_left testlatency`로 왼쪽 클릭에 연결하고, 큰 흰색 상자를 표시하는 HUD를 구성해 클릭 시 밝기 차이를 키움 - 각 테스트는 동일한 조건으로 반복함 - 불필요한 소프트웨어를 닫고 같은 모드와 맵의 로컬 서버를 시작함 - 지정된 위치에서 마우스를 특정 지형 표식에 맞춤 - 약 2분 동안 **100회 클릭**하는 과정을 총 3회 반복함 - 봇, 다른 플레이어, 이동, 라운드 재시작 없이 정적인 장면을 유지함 - 유의미한 다른 프로세스가 실행되지 않도록 하고 측정 장치의 위치도 모든 테스트에서 고정함 ### 전체 구성의 지연 범위 - 프레임 제한을 적용한 모든 사례가 목표 FPS를 안정적으로 유지했고, 게임은 테스트 내내 **CPU 병목** 상태였음 - 모든 사례는 큰 이상치 없이 종 모양 분포를 보였으며, p5에서 p95까지의 폭은 약 2~3ms였음 - 주요 8개 구성의 중앙값은 **4.21~4.93ms**로, 전체 격차가 0.72ms에 불과했음 - XWayland는 대응하는 네이티브 Wayland 구성보다 중앙값이 최대 **3.13ms** 높았으며, 각각 8.06ms와 4.93ms를 기록함 - FPS 제한 해제 사례에서는 dxvk-low-latency가 기본 DXVK보다 지연을 0.84ms 줄임 ### X11과 네이티브 Wayland의 작은 차이 - X11이 모든 구성에서 빨랐지만 차이는 **0.14~0.22ms**로 작아, Wayland가 훨씬 느리게 느껴진다는 평가를 설명하기에는 부족함 - low-latency와 VRR 활성화: X11 4.21ms, Wayland 4.38ms, 차이 +0.17ms - low-latency만 활성화: X11 4.64ms, Wayland 4.83ms, 차이 +0.19ms - VRR만 활성화: X11 4.45ms, Wayland 4.67ms, 차이 +0.22ms - 둘 다 비활성화: X11 4.79ms, Wayland 4.93ms, 차이 +0.14ms - 두 디스플레이 서버의 **지연 분포 형태**도 매우 비슷했음 ### VRR이 지연과 분포에 미친 효과 - VRR은 비교 항목 가운데 가장 큰 영향을 보였으며, 모든 조합에서 **0.26~0.45ms** 빨랐음 - X11과 low-latency: 4.64ms에서 4.21ms로 0.43ms 감소함 - X11 기본 DXVK: 4.79ms에서 4.45ms로 0.34ms 줄어듦 - Wayland와 low-latency: 4.83ms에서 4.38ms로 0.45ms 감소함 - Wayland 기본 DXVK: 4.93ms에서 4.67ms로 0.26ms 줄어듦 - p95와 p5 사이의 폭은 VRR 사용 시 **2.1~2.2ms**, 미사용 시 2.6~3.0ms로 나타나 지연 분포도 좁아짐 - VRR에서는 프레임이 다음 스캔아웃 슬롯을 기다리지 않고 준비되는 즉시 스캔아웃되므로, 측정 결과가 동작 방식과 일치함 ### dxvk-low-latency의 효과와 비용 - FPS 제한 사례에서 dxvk-low-latency는 모든 조합의 지연을 줄였으며, 평균 개선 폭은 **0.20ms**로 X11과 Wayland의 평균 차이 0.18ms와 비슷함 - X11과 VRR: 4.45ms에서 4.21ms로 0.24ms 감소함 - X11과 VRR 비활성화: 4.79ms에서 4.64ms로 0.15ms 줄어듦 - Wayland와 VRR: 4.67ms에서 4.38ms로 0.29ms 감소함 - Wayland와 VRR 비활성화: 4.93ms에서 4.83ms로 0.10ms 줄어듦 - FPS 제한 해제 조건에서는 페이서가 **렌더 큐 누적**을 막고 불균일한 프레임 페이싱을 완화하는 효과가 더 크게 나타남 - GPU를 완전히 포화시키지 않고 GPU 병목에 가까운 상태로 유지함 - GPU 사용률은 기본 DXVK에서 100%, dxvk-low-latency에서 95~97%였음 - 지연은 5.27ms에서 4.43ms로 0.84ms 감소함 - FPS는 715에서 670으로 45FPS 줄어듦 ### XWayland가 추가한 큰 지연 - Heroic Launcher의 `Enable Wine-Wayland (Experimental)` 또는 `PROTON_ENABLE_WAYLAND=1`을 끄면 게임이 **XWayland**를 통해 실행됨 - XWayland는 네이티브 Wayland보다 큰 지연을 추가함 - low-latency 활성화: 4.83ms에서 5.95ms로 1.12ms 증가함 - 기본 DXVK: 4.93ms에서 8.06ms로 3.13ms 늘어남 - 기본 DXVK에서 추가된 **3.13ms**는 측정한 다른 모든 효과를 합친 것보다 컸으며, 일부 나쁜 프레임이 평균을 높인 것이 아니라 전체 분포가 이동함 - XWayland에서 dxvk-low-latency를 추가하면 지연이 **2.11ms** 감소해 모든 사례 중 가장 큰 개선을 기록함 ### 결과의 적용 범위와 실전 해석 - 측정 결과는 안정적인 제한 FPS, CPU 병목, 정적인 장면이라는 **최적 조건**과 특정 하드웨어·소프트웨어 스택에 한정됨 - 다른 환경에서는 절대 지연 값이 달라질 수 있지만, 각 구성에서 발생한 증감은 대체로 이전될 수 있다고 봄 - 주사율이 더 낮은 디스플레이에서는 VRR과 저지연 페이서의 개선 폭이 더 커질 가능성이 있음 - X11은 Wayland보다 0.14~0.22ms 빨랐지만 KWin 최적화 작업으로 차이가 좁혀질 수 있으며, 다른 Wayland 컴포지터는 이미 더 나을 가능성도 열려 있음 - XWayland를 제외하고 X11·VRR·dxvk-low-latency를 모두 적용하면 기본 Wayland 구성보다 중앙값이 **0.72ms** 낮아짐 - 중앙값 차이는 작지만 VRR은 지연 지터를 줄이고, dxvk-low-latency는 실제 게임에서 발생하는 프레임 시간 저하와 GPU 병목 상황을 완화함 ### 유사한 입력 지연 측정 프로젝트 - David Ramiro의 [m2p-latency](https://davidjusto.com/articles/m2p-latency/)와 [X11·Wayland 비교 결과](https://davidjusto.com/articles/m2p-latency/#results)는 네이티브 X11과 Wayland가 약 7ms로 비슷하고, XWayland에서는 지연이 약 2배로 늘어나는 유사한 결과를 얻음 - farnoy는 [Open-Source-LDAT](https://github.com/S4N-T0S/Open-Source-LDAT)를 이용한 [Linux latency measurements and compositor tuning](https://farnoy.dev/posts/linux-latency)에서 광범위하게 측정한 뒤 XWayland를 피해야 한다고 결론 내림 - Themaister의 [VK_EXT_present_timing 기반 입력 지연 측정](https://themaister.net/blog/2026/07/02/my-side-quest-measuring-input-latency-with-vk_ext_present_timing/)은 외부 하드웨어 없이 `/dev/uinput`으로 입력을 주입하고 GPU에서 이미지 변화를 감지함 - USB와 디스플레이 지연을 제외하므로 종단 간 시스템 지연이 아니라 **PC 내부 지연**만 측정함 - 구현은 [pyrofling의 latency-measurement-layer](https://github.com/Themaister/pyrofling/tree/master/latency-measurement-layer)에 공개돼 있음 ## Comments ### Comment 61875 - Author: neo - Created: 2026-07-16T00:36:09+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48909424) - Linux의 좋은 점은 이런 분석이 가능할 뿐 아니라 실제로 **생태계 개선**으로 이어진다는 것임. 결과가 그래픽 소프트웨어 개발자와 배포판 패키지 관리자에게 전달되지만, Microsoft에서는 이런 개선 경로를 기대하기 어려워 보임 오랫동안 Windows를 쓰다 최근 Linux로 옮겼는데, KDE Plasma가 Windows 11보다 빠릿하고 문제가 생겨도 직접 손봐서 개선할 수 있다는 점이 좋았음. 한동안 Linux 데스크톱을 써보지 않았다면 게임용으로 조정된 Fedora인 **Bazzite**를 권하며, 게임을 하지 않아도 완성도 높은 데스크톱을 빠르게 구성할 수 있음 - 그 의미가 실제 개선으로 이어졌으면 좋겠음. Linux를 주 운영체제로 쓰고 좋아하지만, 데스크톱 환경과 주변 구성은 훨씬 복잡해진 반면 예전보다 나빠졌음 과거에는 직관적인 설정 파일 하나로 원하는 대로 바꿀 수 있었지만, 지금은 테마·아이콘·밝은 모드·어두운 모드에 수많은 추상화 계층이 생겼어도 제대로 작동하는 조합을 찾기 어려움. 밝은 모드에서는 밝은 회색 위에 회색 글씨가, 어두운 모드에서는 검은 배경에 검은 글씨가 나타나며, Adwaita 같은 테마에 따라 PDF 뷰어조차 글자와 배경색을 제대로 정하지 못할 때가 있음 어떤 테마도 **스크롤바**를 충분히 잘 보이게 하지 않고, 활성 창과 비활성 창을 명확한 색으로 구분하지도 않음. Windows 3.11도 스크롤바, 활성 창 표시, 색상 사용자화를 더 잘했는데, 과도하게 설계하기 전보다 오히려 나았던 셈임 - Microsoft도 설정 하나로 수백만 대의 기기에서 **원격 측정 데이터**를 수집해 그래픽 소프트웨어 개발자에게 전달할 수 있을 것 같음 Intel([https://www.techpowerup.com/312122/psa-intel-graphics-driver...]())과 Nvidia([https://nateshoffner.com/blog/2017/05/disable-nvidia-telemet...]())도 동의한 사용자에게서 이런 데이터를 수집함. 다만 둘 다 선택적 참여 방식이라 열성 게이머의 데이터는 많지 않을 수 있음 - 일부는 실제로 개선되지만, 애호가나 소규모 회사가 감당할 수 없는 **대규모 협업**이 필요한 분야도 있음. 모든 애플리케이션에 일관된 색상 보정을 적용하거나 고급 프린터 기능을 제대로 지원하는 일이 대표적임 점진적인 변화는 많아도 수년간 국소 최적점에 갇히곤 함. 그래도 내부 동작을 비교적 쉽게 들여다볼 수 있는 점은 좋으며, Windows와 macOS가 반드시 폐쇄형 소스여야 하는 이유는 잘 모르겠음 - Windows에서도 커널 API 호출 패치, COM 객체 생성 대체, 장치 요청을 가로채는 필터 드라이버 설치, 사용자 공간 DLL 교체까지 가능함. 특정 API를 검색하면 블랙햇 포럼이나 익스플로잇 작성법이 나올 정도로 **강력하고 위험한 개입**이 가능해, 왜 허용하는지 의문이 들 때도 있었음 - 더 좋은 점은 기술 스택 대부분이 **오픈 소스**라 직접 기여할 수도 있다는 것임 - 몇 달 전 주 운영체제이자 게임용 환경을 **Fedora**로 바꿨는데 Windows보다 전반적으로 빠릿하게 느껴졌고, 이 측정이 게임 입력 지연에 관한 궁금증을 일부 풀어줬음 최근 Wayland 기반 Hyprland로 옮겨 결과가 어떻게 달라질지 궁금하며, 인기가 높아진 만큼 다시 시험해 주면 좋겠음. Gamescope도 고려했지만 Nvidia에서 잘 작동하지 않는다는 얘기가 있고, 게임 최적화 커널이라는 것도 이번에 처음 알게 됨. 경쟁 격투 게임에서는 **입력 지연**이 매우 중요하므로 비슷한 최적화를 해본 이야기를 듣고 싶음 - XWayland를 제외한 모든 시험의 입력 지연 차이는 사람이 구분할 수 없을 만큼 작으며, XWayland의 **3ms 차이**조차 알아챈다면 놀라울 것 같음. 느린 모니터에서는 차이가 더 커질 수 있지만 Wayland와 X11 프로토콜 자체의 차이는 미미하고, XWayland 구현에 제약이 있어 보임 - 커널을 바꿔 얻는 초당 프레임 수 향상은 대체로 미미하므로 노력할 가치가 있는지는 각자 판단해야 함. 주된 차이는 CPU 시간을 고르게 배분하는 대신 짧게 집중적으로 실행되는 프로세스를 우선하는 **스케줄러**에 있음 게임에서는 Hyprland가 마음에 들었고, X11의 AwesomeWM을 쓸 때보다 Gamescope를 통한 가변 주사율·테어링 같은 세부 설정이 쉬웠음. Lua 설정도 AwesomeWM을 쓰던 입장에서는 익숙하게 느껴짐 - 별도 TTY에서 **Gamescope**를 실행해 Steam이나 Heroic Launcher를 바로 시작하는 구성이 매우 잘 작동함. 어차피 전체 화면으로 게임하므로 창 관리자가 필요 없고 HDR 문제도 해결됐지만, 음량과 밝기 키가 작동하지 않게 됨 - OpenSUSE에서도 비슷했지만 Wayland의 약점은 **게임 스트리밍**이었음. Sunshine/Moonlight가 작동하긴 해도 입력 지연과 화면 결함이 눈에 띄어, 스트리밍에는 더 나은 X11과 Wayland를 오가고 있음. 시간이 지나면 Wayland만 쓰게 될 것으로 기대함 - **500Hz 디스플레이**를 사용한 시험이라 저주사율 화면에서 나타날 문제가 많이 가려졌을 수 있음. XWayland가 3ms 느렸다는 것은 이 주사율에서는 한 프레임 뒤처졌을 가능성도 있음 120Hz나 60Hz로 시험하면 미세한 실행 시점 차이와 한 프레임 전체가 늦어지는 큰 효과를 더 명확히 구분할 수 있을 것임 - 글 끝에서 Wayland가 느리다고 여겨지는 이유를 의아해하지만, **XWayland 결과**가 바로 그 이유일 수 있음. Wayland에서 X11 게임을 실행한 사용자가 유의미한 지연을 느꼈을 가능성이 있음. 여러 분야에서 이런 식의 실제 측정이 더 많아지면 좋겠음 - 결과가 나빴던 것은 XWayland뿐이고 차이도 몇 밀리초에 불과해 사람이 체감했다고 믿기는 어려움. **10~20ms**라면 납득하겠지만 몇 밀리초는 의심스러움 글쓴이는 다른 혼재 변수를 잘 제거했지만, Wayland가 느리다고 느낀 사용자들은 최적화되지 않은 환경에서 출발했다가 저지연 구성으로 바꾸면서 관련 설정도 함께 바로잡았을 수 있음 - Wayland는 테어링을 막기 위해 Xorg보다 항상 **한 프레임 지연**되는 것으로 알았는데 지금은 달라졌는지 궁금함. 그렇다면 매우 높은 주사율이 그 효과를 축소했을 것임 - 1990년대 중반부터 Linux를 써왔지만 X11과 Wayland의 차이를 전혀 구분하지 못하며 논쟁에도 관심이 없음. Vim 대 Emacs, GNOME 대 KDE 논쟁의 반복처럼 보여 이제 관련 불평을 보면 페이지를 닫게 됨 - Wayland 컴포지터 하나만 시험하고 모든 Wayland 컴포지터의 성능을 말할 수는 없음. 특히 입력 장치 처리에 필요한 Wayland 확장([https://wayland.app/protocols/]())은 구현마다 크게 다름 어디서나 사실상 표준 참조 구현인 Xorg가 비슷하게 동작하는 X11과 달리, **Wayland 구현별 차이**는 큼. 시험에 사용한 KDE Plasma보다 느린 컴포지터도, 더 빠른 컴포지터도 있을 수 있음 - Wayland가 빠르거나 느리다고 판단하려면 게임 버전, 디스플레이 서버와 그 설정, 게임 설정, 모니터와 그래픽 카드의 기능, 드라이버 버전 등 **전체 환경 정보**가 필요함 - **Wayland 입력 지연**이라는 표현 자체가 `HTTP 애니메이션 부드러움`처럼 서로 다른 층위를 뒤섞은 말임. 이 글이 측정한 것은 Xorg와 KWin, 그리고 XWayland이며 다른 X11·Wayland 구현은 특성이 다를 수 있음 다만 XWayland의 추가 지연은 단순한 부가 비용으로 넘기기엔 의심스러울 만큼 큼 - 다른 글에서는 **Nvidia 드라이버**를 원인으로 의심함: [https://davidjusto.com/articles/m2p-latency/#results]() - GNOME에서도 다시 시험할 필요가 있음. 깊이 파본 것은 아니지만 GNOME의 Wayland 컴포지터가 KWin보다 빠르고 더 세심하게 설계된 듯함 특히 pgtk 모드의 Emacs는 GNOME에서 훨씬 잘 동작하지만, KWin에서는 스크롤할 때 CPU를 많이 사용하고 고해상도에서는 약간 지연되기도 함 - Wayland를 둘러싼 논리는 성가실 때가 있음. 먼저 X는 오래전에 폐기 예정이니 미래인 Wayland로 바꾸라고 해놓고, 사용자가 고장 나거나 더 나빠졌다고 하면 **Wayland는 프로토콜일 뿐**이고 구현 탓이라고 답함. 하지만 사용자는 X에서 이미 잘 작동하고 있었음 - 같은 하드웨어에서 **Windows와 비교**하면 어떻게 나올지도 매우 흥미로울 것임 - Breaka Club에서는 개조한 Overcooked 2!로 아이들에게 코딩을 가르치며 이 문제를 직접 다루고 있음 학교 기기에 모드를 설치하기 어렵기 때문에 모드가 포함된 OC2를 WebRTC로 스트리밍하고, 아이들은 iPad의 Mobile Safari에서 화면상 게임패드로 플레이함. 게임 인스턴스는 오래된 Nvidia 하드웨어 위 Kubernetes/k3s의 Docker 컨테이너에서 실행되며, 인터넷과 학교 네트워크를 거치므로 NVEnc와 DMABuf의 **무복사 전송** 등을 이용해 전체 지연을 줄이고 있음 현재 XWayland의 입력 부가 비용을 겪고 있지만 입력이 가상 장치라 양상이 다를 수 있음. 종단 간 최적화는 어렵고 현재 성능은 받아들일 만한 수준임. OC2 코딩 영상: [https://www.youtube.com/watch?v=ITWSL5lTLig]() OC2 라이선스는 제한된 수만큼 구매해 파드가 시작할 때 하나를 할당받으며, 모두 사용 중이면 아이들은 다른 게임을 플레이함 - X11에서 합성 렌더링을 사용할 때 전체 화면 창이 컴포지터에 **리디렉션 해제 힌트**를 보내면, 다른 요소가 화면에 그려지지 않는 동안 합성을 중단하고 애플리케이션의 스왑체인을 화면으로 직접 전달할 수 있음. 사실상 최적의 방식이라 더 개선하기 어려움 다른 창이 위에 나타나거나 컴포지터가 직접 전달할 수 없다고 판단하면 애플리케이션 창과 다른 요소를 임시 버퍼에 합성하는 중간 단계가 생김. 창이 화면 높이보다 1픽셀 작게 생성되는 식으로 리디렉션 해제가 깨지거나 XWayland를 사용하면 지연이 커질 수 있으며, 이는 근본적인 제약이라 다른 운영체제의 컴포지터에서도 비슷한 문제가 생김 Wayland는 GPU 하드웨어가 여러 계층을 직접 합성하는 **디스플레이 평면(display planes)** 도 탐색해 왔음. 이를 쓰면 게임은 최대 초당 프레임 수로 렌더링하고 위의 창은 별도 평면에 그려 부작용 없이 합성할 수 있지만, 실제 제품 환경에서 사용 중인지는 모르겠음 - 콘솔은 고정된 출력 초당 프레임 수와 동적 해상도를 지향하는 반면, PC는 해상도를 고정하고 초당 프레임 수와 프레임 시간 간격을 동적으로 두는 경향이 있음. 이것이 지연과 어떤 관계인지 궁금함 특히 경쟁 게임에서는 디스플레이 주사율을 훨씬 넘는 초당 프레임 수를 목표로 하는데, 실제 이점인지 착각인지 확신이 서지 않음 - 렌더링 분야에서 일하는 입장에서 보면 **높은 초당 프레임 수**는 독특한 방식으로 도움이 됨. 물체의 렌더링 위치는 주로 프레임 렌더링 시작 시점에 결정되므로, 프레임을 더 자주 만들수록 화면에 보이는 물체가 현재의 실제 위치에 가까워짐 핵심은 더 많은 프레임을 보는 것이 아니라 더 최신 정보를 보는 데 있음. 화면 갱신 직전에 끝나도록 렌더링을 늦춰 시작할 수도 있지만, 시점을 조금만 놓쳐도 심한 끊김이 생기며 GPU 실행 시간과 CPU의 작업 제출 시간은 결정적이지 않음 - 주사율을 넘는 초당 프레임 수가 완전히 무의미한 것은 아니지만 자원 낭비는 있음. 표시되는 각 프레임이 게임 상태를 더 최신에 가깝게 반영하기 때문임 이상적으로는 불필요한 프레임을 만들지 않고 화면 갱신 직전에 렌더링을 시작하면 되지만, **마감 시점**을 놓치면 매우 거슬리는 끊김이 발생함 - PC 게임도 동적 해상도를 지원하는 경우가 많음. 콘솔이 보통 60fps를 목표로 하는 것은 대다수 TV의 주사율이 그렇고 모든 사용자가 동일하거나 몇 가지뿐인 하드웨어 구성을 쓰기 때문임 새 프레임은 화면 주사 과정 중간에 끼어들 수 있어 테어링이 생기지만, 경계선 아래에는 더 최신 픽셀이 표시됨. 따라서 모니터의 한 프레임에 여러 렌더링 프레임이 섞일 수 있고, 높은 주사율의 가변 주사율 디스플레이만큼 좋지는 않아도 **지연을 줄여줌**. 동작이 덜 중요한 게임에서는 VSync로 프레임을 주사율에 맞춰 테어링을 없애는 경우가 흔함 - 착각이라면 경쟁 플레이어들이 세부 묘사와 해상도를 크게 희생하면서까지 엄청난 초당 프레임 수를 추구할 만큼 강력한 착각일 것임. 나도 차이는 보이지만 수익 체감 때문에 보통은 높은 해상도와 더 나은 그래픽을 택함 일부 게임은 일정한 초당 프레임 수를 위해 해상도를 실시간으로 조절함. PC에서는 원래 목표보다 훨씬 낮은 사양에서도 게임을 실행할 수 있었고 낮은 초당 프레임 수가 문화적으로 더 용인됐으며, 싫으면 업그레이드할 수도 있었음. 콘솔은 업그레이드 경로가 없고 단일 구성에 최적화해야 해서 성능이 너무 떨어지기 전에 **해상도를 낮추는 방식**이 더 적합했음 - 게임의 핵심에는 프레임마다 실행되는 큰 반복문이 있음. 디스플레이 주사율보다 빠르게 프레임을 생성하면 다음 화면 갱신이 더 최근 프레임을 사용할 가능성이 높아져 **입력 지연이 감소**함 게임이 입력 이벤트를 더 많이 받는다는 뜻은 아니지만 입력을 더 빨리 처리하고 반영할 수 있음. 착각은 아니나 수익 체감이 크고, 프레임 대기열·VSync·가변 주사율·CPU 또는 GPU 병목·입력 및 시뮬레이션 반복 구조에 따라 효과가 달라짐 - 글쓴이는 처음부터 착각을 배제하려 하지만 지연은 결국 느낌과 사용감으로 평가하는 것 아닌가 싶음. 개인적으로 어떻게 느끼는지가 최종 시험이며, 실제 지연을 진단하고 고치는 데 데이터가 유용하더라도 대부분의 UI/UX에서는 **취향과 체감**에 의존해도 괜찮다고 봄 별점처럼 덜 기술적인 평가를 병행하면 시험과 데이터 수집이 지나치게 방법론에 매몰되는 것도 막을 수 있음. 정밀하게 구성한 시험에서는 특정 환경의 일상적 사용 중 자주 나타나는 **성능 저하 조건**이 빠질 가능성이 있음 - 전국 수준으로 리듬 게임을 하는 입장에서 동의하기 어려움. ITGmania는 정확도를 **0.1ms 단위**로 측정하며, 하드웨어 지연이 세션 사이 또는 도중에 흔들리면 점수가 망가지고 일관성 없는 환경은 극도로 성가심. 지연을 감각이나 분위기로 다뤄서는 안 됨 - 첫 TFT TV는 입력 지연이 **2초**라 게임을 할 수 없었고, 이는 느낌과 무관함. 10ms 지연만으로도 측정 가능한 영향이 생김: [https://www.youtube.com/watch?v=5qjSGEOEaXo]() - 가장 중요한 상황에서는 착각이 아님. 실력이 같은 두 FPS 플레이어가 맞붙을 때 한쪽 시스템의 지연이 4ms이고 다른 쪽이 5ms라면, 각자가 두 환경의 차이를 체감하지 못하더라도 **4ms 쪽이 통계적으로 유리함**