Đo độ trễ đầu vào trên Linux: X11 so với Wayland, VRR, DXVK

 (marco-nett.de)
1 điểm bởi GN⁺ 3 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Kết quả đo từ lúc nhấp chuột đến khi độ sáng màn hình thay đổi trên màn hình 500Hz cho thấy, ngay cả khi áp dụng đồng thời X11, VRR và dxvk-low-latency, độ trễ end-to-end trung vị cũng chỉ thấp hơn 0,72ms so với Wayland mặc định
  • Wayland native chậm hơn X11 0,14~0,22ms, trong khi XWayland thêm tối đa 3,13ms so với Wayland native, tạo ra khác biệt lớn hơn nhiều
  • Tần số quét biến thiên (VRR) giảm độ trễ 0,26~0,45ms trong mọi phép so sánh, đồng thời thu hẹp độ rộng phân bố p5~p95 từ 2,6~3,0ms xuống 2,1~2,2ms
  • dxvk-low-latency giảm 0,10~0,29ms khi khóa khung hình, và giảm 0,84ms khi bỏ giới hạn, nhưng ở trường hợp sau FPS giảm từ 715 xuống 670 trong khi mức sử dụng GPU được giữ ở 95~97% thay vì 100%
  • Kết quả này được tạo ra trong điều kiện tối ưu gồm FPS ổn định và nghẽn cổ chai ở CPU, cùng một tổ hợp phần cứng/phần mềm cụ thể; trong chơi thực tế, việc VRR giảm jitter và frame pacer kìm hãm hàng đợi render có thể tạo ra khác biệt lớn hơn cả mức trung vị

Vì sao phải tự kiểm chứng các lời khuyên tối ưu hóa

  • Trong chơi game trên Linux có vô số lời khuyên tối ưu như dùng X11 thay vì Wayland, tắt compositing, dùng fork DXVK tối ưu độ trễ, kernel scheduler cho game, áp dụng gamescope·gamemode·biến môi trường, v.v.
  • Với FPS cạnh tranh, độ trễ thấp, thời gian khung hình ổn định và FPS cao là rất quan trọng, nhưng khó xác định việc đổi cấu hình có thật sự cải thiện hay chỉ là hiệu ứng giả dược hoặc phản tác dụng
  • Phần cứng của thiết bị đo, vỏ, firmware, mã phân tích và dữ liệu thô đều được công khai trong kho GitHub click2photon

Thiết bị đo từ lúc nhấp chuột đến thay đổi trên màn hình

  • Thiết bị được gắn lên màn hình, phát sinh cú nhấp chuột qua USB rồi đo thời gian đến khi cảm biến quang phát hiện thay đổi trên màn hình để đo độ trễ hệ thống end-to-end
  • Thiết kế ban đầu tham khảo sơ đồ mạch của OSLTT khi đó còn dùng được, và trong quá trình hoàn thiện cũng tích hợp ý tưởng từ m2p-latency và Open-Source-LDAT
  • Quá trình chế tạo cần tới vi điều khiển, hàn, firmware Arduino, thời gian tích phân, bộ khuếch đại transimpedance, KiCad và thiết kế vỏ
  • Adafruit QT Py RP2040 hoạt động như một chuột USB HID polling 1.000Hz và tạo ra cú nhấp chuột
    • Ngay sau khi gửi tín hiệu nhấp, thiết bị lấy mẫu photodiode khoảng mỗi 24µs
    • Với mỗi cú nhấp, 12.000 mẫu được gửi nối tiếp về máy chủ và ghi thành CSV
    • Công cụ phía máy chủ tính baseline cho từng cú nhấp và tìm mẫu đầu tiên lệch khỏi baseline quá một ngưỡng nhất định
    • Vì thời gian thu thập 12.000 mẫu là cố định, có thể tính được thời gian từ lúc gửi cú nhấp đến khi độ sáng màn hình thay đổi

Cấu hình hiển thị và render được so sánh

  • So sánh X11 và Wayland native để đối chiếu nhận định rằng Wayland cho cảm giác chậm hơn với kết quả đo thực tế
  • So sánh việc bật/tắt tần số quét biến thiên (VRR), bao gồm G-Sync và FreeSync
  • Đo khác biệt giữa dxvk-low-latency và DXVK mặc định
    • Frame pacer của fork này đã được tích hợp vào gói chính thức proton-cachyos, và bật bằng PROTON_DXVK_LOWLATENCY=1
  • Thêm 2 trường hợp bỏ giới hạn FPS để kiểm tra xem frame pacer có hấp thụ dao động thời gian khung hình và ngăn hàng đợi render tích tụ hay không
    • Trong cảnh game tĩnh, không có dao động thời gian khung hình và bài test cũng ở điều kiện nghẽn CPU, nên không phản ánh đầy đủ một phiên chơi thực tế
    • Trong phiên thực tế, thời gian khung hình có thể thay đổi theo tình huống trong game hoặc mức dùng tài nguyên của các tiến trình khác
  • Các bài test Wayland mặc định chạy trên Wayland native với PROTON_ENABLE_WAYLAND=1, đồng thời đo thêm 2 trường hợp XWayland tắt VRR để so sánh

Phần cứng và phần mềm thử nghiệm

  • Trong lúc thử nghiệm chỉ kết nối một màn hình, với cấu hình phần cứng như sau
    • AMD Ryzen 7 5800X3D
    • NVIDIA GeForce RTX 4070 SUPER
    • 2 mô-đun DDR4 3,200MHz 8GB
    • MSI MAG 272QP QD-OLED X50, 2560×1440, 500Hz
    • MSI B450 GAMING PRO CARBON AC
  • Ngăn xếp phần mềm gồm 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
    • Sử dụng proton-cachyos-native 1:11.0.20260602-3 và dxvk 3.0
    • Giữ nguyên kernel scheduler mặc định của CachyOS

Thiết lập màn hình và DXVK

  • Tần số quét hệ thống được đặt ở 500Hz
  • Trên X11, dùng nvidia-settings để bật flip mode và VRR; việc thay đổi VRR cần khởi động lại
  • Trên Wayland, bật VRR trong phần cài đặt KDE và không cần khởi động lại
  • Flip mode hoặc direct scanout trên Wayland không do người dùng đặt thủ công mà do compositor quyết định theo từng khung hình
    • Bật showcompositing trong tab Effects của KWin Debug Console
    • Nếu chỉ game hiển thị toàn màn hình, được focus hoàn toàn và không có viền đỏ ở mép, thì được xem là đang ở flip mode
  • Dùng dxvk.conf được tối ưu theo từng điều kiện so sánh
    • Khi tắt VRR: dxgi.maxFrameRate = 500
    • Khi bật VRR và tắt dxvk-low-latency: dxgi.maxFrameRate = 497
    • Khi bật đồng thời VRR và dxvk-low-latency, dùng cấu hình sau cho low-latency VRR frame pacing ở 500Hz
dxgi.maxFrameRate = 480
dxvk.lowLatencyOffset = 70
dxvk.framePace = "low-latency-vrr-500"
dxvk.lowLatencyAllowCpuFramesOverlap = False
  • Mọi cấu hình đều áp dụng d3d11.cachedDynamicResources = "c"

Môi trường game và quy trình đo lặp lại

  • Game dùng để thử nghiệm là Diabotical, một game DirectX 11 chạy bằng Heroic và Proton
  • Dùng độ phân giải native và tỷ lệ render 100%, tắt Vsync, còn lại hạ thiết lập đồ họa xuống mức thấp nhất có thể
  • Một lệnh ẩn để tạm ẩn UI được gán vào chuột trái bằng /bind mouse_left testlatency, đồng thời cấu hình HUD hiển thị một ô trắng lớn để tăng chênh lệch độ sáng khi nhấp
  • Mỗi bài test được lặp lại trong cùng điều kiện
    • Đóng phần mềm không cần thiết và khởi chạy máy chủ cục bộ ở cùng chế độ và bản đồ
    • Đặt chuột vào một mốc địa hình cụ thể từ vị trí đã chỉ định
    • Lặp lại tổng cộng 3 lần, mỗi lần 100 cú nhấp trong khoảng 2 phút
    • Giữ cảnh tĩnh, không bot, không người chơi khác, không di chuyển, không restart round
    • Đảm bảo không có tiến trình đáng kể nào khác chạy và vị trí thiết bị đo cũng được giữ cố định cho mọi bài test

Phạm vi độ trễ của toàn bộ các cấu hình

  • Tất cả các trường hợp có khóa khung hình đều giữ mục tiêu FPS ổn định, và game ở trạng thái nghẽn CPU suốt bài test
  • Mọi trường hợp đều cho phân bố hình chuông, không có ngoại lệ lớn, với độ rộng từ p5 đến p95 khoảng 2~3ms
  • Trung vị của 8 cấu hình chính nằm trong 4,21~4,93ms, tức toàn bộ chênh lệch chỉ là 0,72ms
  • XWayland có trung vị cao hơn tối đa 3,13ms so với cấu hình Wayland native tương ứng, ghi nhận lần lượt 8,06ms và 4,93ms
  • Trong các trường hợp bỏ giới hạn FPS, dxvk-low-latency giảm độ trễ 0,84ms so với DXVK mặc định

Khác biệt nhỏ giữa X11 và Wayland native

  • X11 nhanh hơn trong mọi cấu hình, nhưng chênh lệch chỉ 0,14~0,22ms, không đủ để giải thích nhận định rằng Wayland cho cảm giác chậm hơn rất nhiều
    • Bật low-latency và VRR: X11 4,21ms, Wayland 4,38ms, chênh +0,17ms
    • Chỉ bật low-latency: X11 4,64ms, Wayland 4,83ms, chênh +0,19ms
    • Chỉ bật VRR: X11 4,45ms, Wayland 4,67ms, chênh +0,22ms
    • Cả hai đều tắt: X11 4,79ms, Wayland 4,93ms, chênh +0,14ms
  • Hình dạng phân bố độ trễ của hai display server cũng rất giống nhau

Tác động của VRR lên độ trễ và phân bố

  • VRR cho thấy tác động lớn nhất trong các yếu tố được so sánh, nhanh hơn 0,26~0,45ms trong mọi tổ hợp
    • X11 và low-latency: giảm từ 4,64ms xuống 4,21ms, tức 0,43ms
    • X11 với DXVK mặc định: giảm từ 4,79ms xuống 4,45ms, tức 0,34ms
    • Wayland và low-latency: giảm từ 4,83ms xuống 4,38ms, tức 0,45ms
    • Wayland với DXVK mặc định: giảm từ 4,93ms xuống 4,67ms, tức 0,26ms
  • Độ rộng giữa p95 và p5 là 2,1~2,2ms khi dùng VRR, và 2,6~3,0ms khi không dùng, cho thấy phân bố độ trễ cũng hẹp hơn
  • Với VRR, khung hình được scanout ngay khi sẵn sàng thay vì phải chờ slot scanout tiếp theo, nên kết quả đo phù hợp với cơ chế hoạt động này

Hiệu quả và chi phí của dxvk-low-latency

  • Trong các trường hợp có khóa FPS, dxvk-low-latency giảm độ trễ ở mọi tổ hợp, với mức cải thiện trung bình 0,20ms, gần tương đương chênh lệch trung bình 0,18ms giữa X11 và Wayland
    • X11 và VRR: giảm từ 4,45ms xuống 4,21ms, tức 0,24ms
    • X11 và tắt VRR: giảm từ 4,79ms xuống 4,64ms, tức 0,15ms
    • Wayland và VRR: giảm từ 4,67ms xuống 4,38ms, tức 0,29ms
    • Wayland và tắt VRR: giảm từ 4,93ms xuống 4,83ms, tức 0,10ms
  • Trong điều kiện bỏ giới hạn FPS, hiệu quả của pacer trong việc ngăn hàng đợi render tích tụ và giảm frame pacing không đều thể hiện rõ hơn
    • Giữ GPU không bị bão hòa hoàn toàn mà ở trạng thái gần nghẽn GPU
    • Mức sử dụng GPU là 100% với DXVK mặc định, và 95~97% với dxvk-low-latency
    • Độ trễ giảm từ 5,27ms xuống 4,43ms, tức 0,84ms
    • FPS giảm 45, từ 715 xuống 670

Độ trễ lớn do XWayland bổ sung

  • Nếu tắt Enable Wine-Wayland (Experimental) trong Heroic Launcher hoặc tắt PROTON_ENABLE_WAYLAND=1, game sẽ chạy qua XWayland
  • XWayland làm tăng độ trễ đáng kể so với Wayland native
    • Bật low-latency: tăng từ 4,83ms lên 5,95ms, tức 1,12ms
    • DXVK mặc định: tăng từ 4,93ms lên 8,06ms, tức 3,13ms
  • Mức tăng 3,13ms ở DXVK mặc định lớn hơn tổng mọi hiệu ứng khác được đo, và không phải do vài khung hình xấu làm tăng trung bình mà là cả phân bố đã dịch chuyển
  • Khi thêm dxvk-low-latency trên XWayland, độ trễ giảm 2,11ms, là mức cải thiện lớn nhất trong mọi trường hợp

Phạm vi áp dụng của kết quả và cách diễn giải thực chiến

  • Kết quả đo chỉ giới hạn trong điều kiện tối ưu gồm FPS cố định ổn định, nghẽn CPU và cảnh tĩnh, cũng như một ngăn xếp phần cứng/phần mềm cụ thể
  • Ở môi trường khác, giá trị độ trễ tuyệt đối có thể thay đổi, nhưng mức tăng giảm giữa các cấu hình nhìn chung có thể được chuyển giao
  • Trên màn hình có tần số quét thấp hơn, mức cải thiện từ VRR và low-latency pacer có thể còn lớn hơn
  • X11 nhanh hơn Wayland 0,14~0,22ms, nhưng khác biệt này có thể thu hẹp nhờ các tối ưu đang được thực hiện cho KWin; các compositor Wayland khác thậm chí có thể đã tốt hơn
  • Nếu bỏ qua XWayland, việc áp dụng đồng thời X11·VRR·dxvk-low-latency giúp trung vị thấp hơn 0,72ms so với cấu hình Wayland mặc định
  • Dù chênh lệch trung vị là nhỏ, VRR giúp giảm jitter độ trễ, còn dxvk-low-latency giúp giảm các tình huống tụt frame time và nghẽn GPU trong chơi thực tế

Các dự án đo độ trễ đầu vào tương tự

Bài viết liên quan

1 bình luận

 
GN⁺ 3 giờ trước
Ý kiến trên Hacker News

  • Điểm hay của Linux là không chỉ có thể thực hiện những phân tích như thế này mà còn thực sự dẫn tới cải thiện hệ sinh thái. Kết quả được chuyển tới các nhà phát triển phần mềm đồ họa và quản lý gói của bản phân phối, trong khi ở Microsoft có vẻ khó trông đợi một lộ trình cải thiện như vậy
    Tôi dùng Windows trong thời gian dài rồi gần đây chuyển sang Linux, và điều tôi thích là KDE Plasma phản hồi nhanh hơn Windows 11, hơn nữa khi có vấn đề thì có thể tự tay chỉnh sửa để cải thiện. Nếu đã lâu bạn chưa dùng desktop Linux, tôi khuyên dùng Bazzite, một Fedora được tinh chỉnh cho chơi game; kể cả không chơi game, bạn vẫn có thể nhanh chóng dựng được một desktop hoàn thiện tốt

    • Mong là điều đó thực sự dẫn tới cải thiện. Tôi dùng Linux làm hệ điều hành chính và rất thích nó, nhưng môi trường desktop và các thành phần xung quanh đã trở nên phức tạp hơn nhiều, trong khi lại tệ hơn trước
      Trước đây chỉ với một tệp cấu hình trực quan là có thể chỉnh theo ý muốn, còn bây giờ dù đã có vô số lớp trừu tượng cho theme, icon, chế độ sáng và chế độ tối, vẫn rất khó tìm ra tổ hợp thực sự hoạt động tốt. Ở chế độ sáng thì có chữ xám trên nền xám nhạt, ở chế độ tối thì có chữ đen trên nền đen, và tùy theme như Adwaita mà ngay cả trình xem PDF đôi khi cũng không đặt đúng màu chữ và màu nền
      Không theme nào làm thanh cuộn đủ dễ nhìn, cũng không phân biệt rõ cửa sổ đang hoạt động và cửa sổ không hoạt động bằng màu sắc rõ ràng. Ngay cả Windows 3.11 cũng làm tốt hơn về thanh cuộn, chỉ báo cửa sổ hoạt động và tùy biến màu sắc; tức là trước khi bị thiết kế quá đà thì mọi thứ còn tốt hơn
    • Microsoft cũng có thể thu thập dữ liệu telemetry từ hàng triệu thiết bị chỉ với một thiết lập rồi chuyển cho các nhà phát triển phần mềm đồ họa
      Intel(https://www.techpowerup.com/312122/psa-intel-graphics-driver...) và Nvidia(https://nateshoffner.com/blog/2017/05/disable-nvidia-telemet...) cũng thu thập loại dữ liệu này từ những người dùng đã đồng ý. Tuy nhiên cả hai đều theo hình thức tự nguyện tham gia, nên có thể không có nhiều dữ liệu từ các game thủ nhiệt thành
    • Một phần thực sự có cải thiện, nhưng cũng có những lĩnh vực cần hợp tác quy mô lớn mà người đam mê hay công ty nhỏ không thể kham nổi. Việc áp dụng hiệu chỉnh màu nhất quán cho mọi ứng dụng, hoặc hỗ trợ đúng các tính năng máy in nâng cao, là những ví dụ điển hình
      Có rất nhiều thay đổi dần dần, nhưng trong nhiều năm người ta thường bị mắc kẹt ở cực trị cục bộ. Dù vậy, khả năng quan sát hoạt động bên trong tương đối dễ dàng vẫn là một điểm tốt, và tôi không rõ vì sao Windows và macOS nhất thiết phải là mã nguồn đóng
    • Trên Windows cũng có thể vá lời gọi kernel API, thay thế việc tạo đối tượng COM, cài driver lọc để chặn yêu cầu thiết bị, thậm chí thay DLL ở không gian người dùng. Mức độ can thiệp mạnh và nguy hiểm này khả thi đến mức chỉ cần tìm một API cụ thể là sẽ ra diễn đàn blackhat hay hướng dẫn viết exploit, nên đôi khi tôi cũng tự hỏi vì sao họ cho phép điều đó
    • Điều còn tốt hơn nữa là phần lớn ngăn xếp công nghệ đều là mã nguồn mở, nên bạn còn có thể trực tiếp đóng góp vào đó

  • Vài tháng trước tôi đã chuyển hệ điều hành chính kiêm môi trường chơi game sang Fedora, và cảm giác chung là nó phản hồi nhanh hơn Windows; các phép đo này cũng phần nào giải đáp thắc mắc của tôi về độ trễ đầu vào khi chơi game
    Gần đây tôi chuyển sang Hyprland dựa trên Wayland nên tò mò không biết kết quả sẽ khác thế nào, và vì nó ngày càng phổ biến nên sẽ rất hay nếu được thử nghiệm lại. Tôi cũng đã cân nhắc Gamescope, nhưng nghe nói nó không hoạt động tốt trên Nvidia, và đây cũng là lần đầu tôi biết tới kernel tối ưu cho game. Trong game đối kháng cạnh tranh, độ trễ đầu vào là cực kỳ quan trọng, nên tôi muốn nghe trải nghiệm của những người đã thử các tối ưu tương tự

    • Ngoại trừ XWayland, chênh lệch độ trễ đầu vào trong mọi thử nghiệm đều nhỏ tới mức con người không thể phân biệt được, và ngay cả chênh lệch 3ms của XWayland nếu ai nhận ra được thì cũng khá đáng kinh ngạc. Trên màn hình chậm hơn, khác biệt có thể lớn hơn, nhưng khác biệt của chính giao thức Wayland và X11 là không đáng kể, còn việc triển khai XWayland dường như có giới hạn nào đó
    • Mức tăng khung hình mỗi giây nhờ đổi kernel nhìn chung là rất nhỏ, nên có đáng bỏ công hay không thì tùy mỗi người tự quyết. Khác biệt chính nằm ở scheduler, vốn ưu tiên các tiến trình chạy ngắn nhưng dồn dập thay vì phân bổ thời gian CPU thật đồng đều
      Với chơi game thì tôi thích Hyprland, và so với khi dùng AwesomeWM trên X11, việc tinh chỉnh các chi tiết như tần số quét biến thiên và tearing thông qua Gamescope dễ hơn. Cấu hình Lua cũng cho cảm giác quen thuộc nếu trước đây từng dùng AwesomeWM
    • Thiết lập chạy Gamescope trên một TTY riêng rồi khởi động thẳng Steam hoặc Heroic Launcher hoạt động rất tốt. Đằng nào tôi cũng chơi game toàn màn hình nên không cần trình quản lý cửa sổ, và nó còn giải quyết được vấn đề HDR, nhưng các phím âm lượng và độ sáng thì không còn hoạt động
    • Tôi cũng từng thấy điều tương tự trên OpenSUSE, nhưng điểm yếu của Wayland là streaming game. Sunshine/Moonlight vẫn chạy được, nhưng độ trễ đầu vào và lỗi hình ảnh khá dễ nhận thấy, nên tôi đang qua lại giữa X11 và Wayland, dùng X11 tốt hơn cho streaming. Tôi hy vọng rồi sẽ đến lúc chỉ cần dùng Wayland

  • Vì thử nghiệm dùng màn hình 500Hz, nên có thể nhiều vấn đề xuất hiện trên màn hình tần số quét thấp đã bị che khuất. Việc XWayland chậm hơn 3ms có thể cũng đồng nghĩa là ở mức tần số quét này nó đã trễ đúng một khung hình
    Nếu thử ở 120Hz hoặc 60Hz, có lẽ sẽ phân biệt rõ hơn giữa chênh lệch nhỏ về thời điểm thực thi và hiệu ứng lớn hơn là bị trễ trọn vẹn một khung hình

  • Ở cuối bài, tác giả thắc mắc vì sao Wayland lại bị cho là chậm, nhưng kết quả của XWayland có thể chính là lý do đó. Có thể những người chạy game X11 trên Wayland đã cảm nhận được độ trễ đủ rõ. Sẽ rất tốt nếu có thêm nhiều phép đo thực tế kiểu này ở nhiều lĩnh vực khác nhau

    • Chỉ có XWayland cho kết quả kém, và chênh lệch cũng chỉ vài mili giây nên khó tin rằng con người thực sự cảm nhận được. Nếu là 10~20ms thì còn hợp lý, nhưng vài mili giây thì khá đáng ngờ.
      Tác giả đã loại bỏ khá tốt các biến gây nhiễu khác, nhưng những người thấy Wayland chậm có thể đã bắt đầu từ một môi trường chưa được tối ưu, rồi khi chuyển sang cấu hình độ trễ thấp thì cũng đồng thời chỉnh lại các thiết lập liên quan
    • Tôi cứ nghĩ Wayland luôn trễ hơn một khung hình so với Xorg để ngăn tearing, nên tò mò không biết giờ có khác không. Nếu vậy thì tần số quét rất cao hẳn đã làm giảm tác động đó
    • Tôi dùng Linux từ giữa những năm 1990 nhưng hoàn toàn không phân biệt nổi khác biệt giữa X11 và Wayland, cũng không hứng thú với cuộc tranh luận này. Nó giống như lặp lại các cuộc chiến Vim với Emacs, GNOME với KDE, đến mức giờ cứ thấy than phiền kiểu này là tôi đóng trang luôn
    • Không thể chỉ thử một compositor Wayland rồi kết luận về hiệu năng của mọi compositor Wayland. Đặc biệt, các phần mở rộng Wayland cần cho xử lý thiết bị nhập liệu (https://wayland.app/protocols/) khác nhau rất nhiều giữa các bản triển khai.
      Khác với X11, nơi Xorg gần như là bản triển khai tham chiếu tiêu chuẩn trên thực tế và hoạt động tương đối giống nhau ở mọi nơi, sự khác biệt giữa các triển khai Wayland là rất lớn. Có thể có compositor chậm hơn KDE Plasma được dùng trong thử nghiệm, và cũng có thể có compositor nhanh hơn
    • Muốn kết luận Wayland nhanh hay chậm thì cần toàn bộ thông tin môi trường như phiên bản game, display server và cấu hình của nó, thiết lập game, khả năng của màn hình và card đồ họa, phiên bản driver, v.v.

  • Cách nói độ trễ nhập liệu của Wayland tự nó đã là một cách diễn đạt trộn lẫn các tầng khác nhau, kiểu như HTTP animation smoothness. Thứ bài này đo là Xorg, KWin và XWayland; các triển khai X11·Wayland khác có thể có đặc tính khác.
    Tuy vậy, độ trễ bổ sung của XWayland lớn đến mức khó có thể xem đơn giản là chi phí phụ thêm

    • Một bài khác nghi ngờ driver Nvidia là nguyên nhân: https://davidjusto.com/articles/m2p-latency/#results
    • Cũng cần thử lại trên GNOME. Tôi chưa đào sâu lắm, nhưng có vẻ compositor Wayland của GNOME nhanh hơn KWin và được thiết kế cẩn thận hơn.
      Đặc biệt, Emacs ở chế độ pgtk chạy tốt hơn nhiều trên GNOME, còn trên KWin thì dùng nhiều CPU khi cuộn và ở độ phân giải cao đôi khi còn hơi trễ
    • Lập luận xoay quanh Wayland đôi khi rất khó chịu. Ban đầu người ta bảo X đã bị lên lịch loại bỏ từ lâu nên hãy chuyển sang Wayland vì đó là tương lai; nhưng khi người dùng nói mọi thứ hỏng hoặc tệ hơn thì lại trả lời rằng Wayland chỉ là giao thức, lỗi là do bản triển khai. Nhưng với người dùng thì trên X trước đó mọi thứ đã chạy ổn rồi

  • Cũng sẽ rất thú vị nếu so sánh với Windows trên cùng phần cứng thì kết quả ra sao

  • Tại Breaka Club, họ đang trực tiếp xử lý vấn đề này khi dạy trẻ em lập trình bằng một bản Overcooked 2! đã được chỉnh sửa.
    Vì khó cài mod lên thiết bị của trường, họ stream OC2 đã tích hợp mod qua WebRTC, còn bọn trẻ chơi bằng tay cầm ảo trên màn hình trong Mobile Safari trên iPad. Phiên bản game chạy trong container Docker trên Kubernetes/k3s trên phần cứng Nvidia cũ, và vì phải đi qua Internet lẫn mạng trường học nên họ đang giảm độ trễ tổng thể bằng những thứ như truyền zero-copy với NVEnc và DMABuf.
    Hiện họ đang gặp chi phí phụ thêm về nhập liệu của XWayland, nhưng vì đầu vào là thiết bị ảo nên có thể đặc tính sẽ khác. Tối ưu hóa end-to-end là việc khó, và hiệu năng hiện tại ở mức có thể chấp nhận được. Video lập trình với OC2: https://www.youtube.com/watch?v=ITWSL5lTLig
    Giấy phép OC2 được mua với số lượng giới hạn, mỗi pod khi khởi động sẽ được gán một bản; nếu dùng hết thì bọn trẻ sẽ chơi game khác

  • Khi dùng composited rendering trên X11, nếu một cửa sổ toàn màn hình gửi cho compositor gợi ý bỏ redirect, thì compositor có thể dừng compositing và chuyển trực tiếp swapchain của ứng dụng ra màn hình miễn là không có thành phần nào khác được vẽ lên đó. Đây gần như là cách tối ưu nhất nên rất khó cải thiện thêm.
    Nếu một cửa sổ khác xuất hiện đè lên, hoặc compositor cho rằng không thể chuyển trực tiếp, thì sẽ xuất hiện bước trung gian là compositing cửa sổ ứng dụng cùng các thành phần khác vào một buffer tạm. Nếu việc bỏ redirect bị hỏng, chẳng hạn cửa sổ được tạo nhỏ hơn chiều cao màn hình 1 pixel, hoặc khi dùng XWayland, thì độ trễ có thể tăng lên; đây là một giới hạn mang tính nền tảng nên compositor trên các hệ điều hành khác cũng gặp vấn đề tương tự.
    Wayland cũng đã tìm cách tận dụng display planes nơi phần cứng GPU trực tiếp compositing nhiều lớp. Nếu dùng được, game có thể render ở tốc độ khung hình tối đa còn cửa sổ phía trên được vẽ ở một plane riêng để compositing mà không có tác dụng phụ, nhưng tôi không biết trong môi trường sản phẩm thực tế điều này có đang được dùng hay không

  • Trong khi console hướng đến số khung hình/giây đầu ra cố định và độ phân giải động, PC lại có xu hướng cố định độ phân giải và để số khung hình/giây cùng khoảng thời gian giữa các khung hình thay đổi linh hoạt. Tôi thắc mắc điều này liên quan thế nào đến độ trễ
    Đặc biệt trong các game cạnh tranh, người ta thường nhắm đến số khung hình/giây cao hơn rất nhiều so với tần số quét của màn hình, nhưng tôi không chắc đó là lợi ích thực sự hay chỉ là ảo giác

    • Từ góc độ người làm trong lĩnh vực kết xuất, fps cao giúp theo một cách khá đặc biệt. Vị trí kết xuất của vật thể chủ yếu được quyết định tại thời điểm bắt đầu kết xuất khung hình, nên tạo khung hình thường xuyên hơn sẽ khiến vật thể hiển thị trên màn hình gần hơn với vị trí thực tế hiện tại
      Điểm cốt lõi không phải là nhìn thấy nhiều khung hình hơn mà là nhìn thấy thông tin mới hơn. Có thể trì hoãn thời điểm bắt đầu kết xuất để nó vừa kịp kết thúc ngay trước lúc màn hình làm mới, nhưng chỉ cần lỡ nhịp một chút là sẽ bị giật rất nặng, còn thời gian thực thi của GPU và thời gian CPU gửi công việc thì không mang tính quyết định
    • Số khung hình/giây vượt quá tần số quét không phải hoàn toàn vô nghĩa, nhưng có sự lãng phí tài nguyên. Lý do là mỗi khung hình được hiển thị phản ánh trạng thái game gần với thời điểm hiện tại hơn
      Lý tưởng nhất là không tạo ra các khung hình không cần thiết và chỉ bắt đầu kết xuất ngay trước lúc màn hình làm mới, nhưng nếu lỡ thời hạn chót thì sẽ xảy ra hiện tượng giật cực kỳ khó chịu
    • Nhiều game PC cũng hỗ trợ độ phân giải động. Console thường nhắm tới 60fps vì phần lớn TV có tần số quét như vậy và mọi người dùng cùng một hoặc chỉ vài cấu hình phần cứng giống nhau
      Khung hình mới có thể chen vào giữa quá trình quét màn hình nên gây tearing, nhưng phía dưới đường ranh sẽ hiển thị các pixel mới hơn. Vì vậy trong một khung quét của màn hình có thể trộn nhiều khung kết xuất, và dù không tốt bằng màn hình VRR tần số quét cao thì nó vẫn giảm độ trễ. Với những game mà phản ứng tức thời kém quan trọng hơn, việc dùng VSync để đồng bộ khung hình với tần số quét nhằm loại bỏ tearing là chuyện phổ biến
    • Nếu là ảo giác thì đó hẳn là một ảo giác đủ mạnh để các tuyển thủ cạnh tranh theo đuổi mức fps cực cao, thậm chí hy sinh đáng kể chi tiết và độ phân giải. Tôi cũng thấy có khác biệt, nhưng vì hiệu quả giảm dần nên thường vẫn chọn độ phân giải cao hơn và đồ họa đẹp hơn
      Một số game điều chỉnh độ phân giải theo thời gian thực để giữ fps ổn định. Trên PC, từ trước đến nay người ta vẫn có thể chạy game trên cấu hình thấp hơn nhiều so với mục tiêu ban đầu, và mức fps thấp được chấp nhận hơn về mặt văn hóa; nếu không thích thì có thể nâng cấp. Console thì không có đường nâng cấp và phải tối ưu cho một cấu hình duy nhất, nên trước khi hiệu năng tụt quá mạnh, cách giảm độ phân giải sẽ phù hợp hơn
    • Cốt lõi của game là một vòng lặp lớn chạy ở mỗi khung hình. Nếu tạo khung hình nhanh hơn tần số quét của màn hình, khả năng lần làm mới kế tiếp dùng được khung hình mới hơn sẽ cao hơn, từ đó giảm độ trễ đầu vào
      Điều đó không có nghĩa game nhận được nhiều sự kiện đầu vào hơn, nhưng nó có thể xử lý và phản ánh đầu vào nhanh hơn. Đây không phải ảo giác, nhưng hiệu quả giảm dần rất lớn, và tác động sẽ khác nhau tùy hàng đợi khung hình, VSync, VRR, điểm nghẽn CPU hoặc GPU, cũng như cấu trúc vòng lặp đầu vào và mô phỏng

  • Tác giả muốn loại trừ ảo giác ngay từ đầu, nhưng tôi nghĩ độ trễ rốt cuộc vẫn được đánh giá bằng cảm giác và trải nghiệm sử dụng. Với cá nhân tôi, cảm nhận thực tế của mỗi người mới là bài kiểm tra cuối cùng; dữ liệu có ích cho việc chẩn đoán và sửa độ trễ thật, nhưng trong phần lớn UI/UX thì dựa vào sở thích và cảm nhận cũng không sao
    Việc kết hợp thêm các đánh giá bớt kỹ thuật hơn như chấm sao cũng có thể ngăn việc thử nghiệm và thu thập dữ liệu bị sa quá sâu vào phương pháp luận. Trong những bài kiểm tra được thiết kế quá chặt chẽ, các điều kiện suy giảm hiệu năng thường xuyên xuất hiện trong sử dụng hằng ngày ở một môi trường cụ thể có thể bị bỏ sót

    • Với tư cách người chơi rhythm game ở cấp độ toàn quốc, tôi khó mà đồng ý. ITGmania đo độ chính xác ở đơn vị 0.1ms, và nếu độ trễ phần cứng dao động giữa các buổi chơi hoặc ngay trong lúc chơi thì điểm số sẽ hỏng bét; một môi trường thiếu nhất quán là điều cực kỳ khó chịu. Không thể xử lý độ trễ chỉ bằng cảm giác hay bầu không khí
    • TV TFT đời đầu có độ trễ đầu vào tới 2 giây nên không thể chơi game, chuyện này không liên quan gì đến cảm giác cả. Chỉ với 10ms độ trễ cũng đã có ảnh hưởng đo được: https://www.youtube.com/watch?v=5qjSGEOEaXo
    • Trong những tình huống quan trọng nhất thì đây không phải ảo giác. Khi hai người chơi FPS có trình độ ngang nhau đối đầu, nếu một bên có hệ thống trễ 4ms còn bên kia là 5ms, thì ngay cả khi cả hai không cảm nhận được sự khác biệt giữa hai môi trường, bên 4ms vẫn có lợi thế thống kê