การวัดความหน่วงอินพุตบน Linux: X11 เทียบกับ Wayland, VRR, DXVK

 (marco-nett.de)
1 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • จากการวัดบนจอแสดงผล 500Hz ตั้งแต่การคลิกจนถึงการเปลี่ยนแปลงความสว่างบนหน้าจอ พบว่าแม้จะใช้ X11, VRR และ dxvk-low-latency ทั้งหมดร่วมกัน ก็ลด ค่ามัธยฐานความหน่วงแบบ end-to-end ได้ต่ำกว่า Wayland พื้นฐานเพียง 0.72ms
  • Native Wayland ช้ากว่า X11 0.14~0.22ms ขณะที่ XWayland เพิ่มความหน่วงได้สูงสุด 3.13ms เมื่อเทียบกับ Native Wayland ซึ่งเป็นความต่างที่ใหญ่กว่ามาก
  • Variable Refresh Rate (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 usage ถูกคงไว้ที่ 95~97% แทน 100% ทำให้ FPS ลดจาก 715 เหลือ 670
  • ผลลัพธ์นี้มาจาก เงื่อนไขที่เหมาะที่สุด คือ FPS เสถียรและมีคอขวดที่ CPU รวมถึงชุดฮาร์ดแวร์·ซอฟต์แวร์เฉพาะ ในการเล่นจริง การลด jitter ของ VRR และการยับยั้ง render queue ของ frame pacer อาจสร้างความแตกต่างได้มากกว่าค่ามัธยฐาน

เหตุผลที่ตรวจสอบคำแนะนำด้านการปรับแต่งด้วยตัวเอง

  • ในการเล่นเกมบน Linux มีคำแนะนำด้านการปรับแต่งจำนวนมาก เช่น ใช้ X11 แทน Wayland, ปิด compositing, ใช้ DXVK fork ที่ปรับแต่งความหน่วง, ใช้ kernel scheduler สำหรับเกม, ใช้ gamescope·gamemode·environment variables เป็นต้น
  • ในเกม FPS เชิงแข่งขัน ความหน่วงต่ำ, frame time ที่สม่ำเสมอ และ FPS สูงเป็นสิ่งสำคัญ แต่ยากที่จะตรวจสอบว่าการเปลี่ยนการตั้งค่านั้นช่วยจริงหรือเป็นเพียง placebo หรือให้ผลย้อนกลับ
  • ฮาร์ดแวร์ของอุปกรณ์วัด, enclosure, firmware, โค้ดวิเคราะห์ และข้อมูลดิบเผยแพร่ไว้ใน click2photon GitHub repository

อุปกรณ์ที่วัดตั้งแต่การคลิกจนถึงการเปลี่ยนภาพบนหน้าจอ

  • ติดอุปกรณ์เข้ากับจอภาพ แล้วสร้าง mouse click ผ่าน USB จากนั้นวัดเวลาจนกว่า optical sensor จะตรวจพบการเปลี่ยนแปลงของภาพ เพื่อวัด ความหน่วงของระบบแบบ end-to-end
  • การออกแบบช่วงแรกอ้างอิง schematic ของ OSLTT ที่ใช้งานได้ในเวลานั้น และระหว่างทำจนเสร็จยังผสานแนวคิดจาก m2p-latency และ Open-Source-LDAT
  • การสร้างต้องใช้ microcontroller, การบัดกรี, Arduino firmware, integration time, transimpedance amplifier, KiCad และการออกแบบ enclosure
  • Adafruit QT Py RP2040 ทำงานเป็นเมาส์ USB HID polling 1,000Hz เพื่อสร้างการคลิก
    • หลังส่งคลิกทันที จะเก็บตัวอย่างจาก photodiode ทุกประมาณ 24µs
    • สำหรับแต่ละคลิก ส่งตัวอย่าง 12,000 รายการกลับไปยัง host ผ่าน serial connection และบันทึกเป็น CSV
    • เครื่องมือฝั่ง host คำนวณ baseline ของแต่ละคลิก แล้วหาตัวอย่างแรกที่เบี่ยงเบนจาก baseline เกินระดับที่กำหนด
    • เนื่องจากเวลาที่ใช้เก็บตัวอย่าง 12,000 รายการคงที่ จึงคำนวณเวลาตั้งแต่ส่งคลิกจนถึงการเปลี่ยนความสว่างบนหน้าจอได้

ชุดการแสดงผลและการเรนเดอร์ที่เปรียบเทียบ

  • เปรียบเทียบ X11 กับ Native Wayland เพื่อเทียบความรู้สึกว่า Wayland ช้ากว่ากับผลการวัดจริง
  • เปรียบเทียบการเปิด/ปิด Variable Refresh Rate (VRR) ซึ่งรวม G-Sync·FreeSync
  • วัดความต่างระหว่าง dxvk-low-latency กับ DXVK พื้นฐาน
    • frame pacer ของ fork นี้ถูกรวมเข้าในแพ็กเกจทางการ proton-cachyos และเปิดใช้งานด้วย PROTON_DXVK_LOWLATENCY=1
  • เพิ่มกรณี ไม่จำกัด FPS 2 กรณี เพื่อตรวจสอบว่า frame pacer ช่วยดูดซับความผันผวนของ frame time และป้องกัน render queue สะสมหรือไม่
    • ในฉากเกมแบบคงที่ไม่มีความผันผวนของ frame time และการทดสอบก็อยู่ในเงื่อนไขคอขวดที่ CPU จึงไม่ได้สะท้อนเซสชันเกมจริงทั้งหมด
    • ในเซสชันจริง frame time อาจเปลี่ยนไปตามสถานการณ์ภายในเกมหรือการใช้ทรัพยากรของโปรเซสอื่น
  • การทดสอบ Wayland โดยพื้นฐานรันบน Native Wayland ด้วย PROTON_ENABLE_WAYLAND=1 และเพื่อเปรียบเทียบยังวัดกรณี XWayland ที่ปิด VRR 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
  • Software stack ประกอบด้วย 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
    • คง kernel scheduler พื้นฐานของ CachyOS ไว้

การตั้งค่าจอแสดงผลและ DXVK

  • ตั้งค่า refresh rate ของระบบเป็น 500Hz
  • บน X11 เปิด flip mode และ VRR ด้วย nvidia-settings และการเปลี่ยน VRR ต้อง reboot
  • บน Wayland เปิด VRR ผ่านการตั้งค่า KDE และไม่ต้อง reboot
  • ผู้ใช้ไม่ได้ตั้งค่า flip mode หรือ direct scanout ของ Wayland ด้วยตัวเอง แต่ compositor จะตัดสินใจในแต่ละเฟรม
    • เปิด showcompositing ในแท็บ Effects ของ KWin Debug Console
    • หากแสดงเฉพาะเกมแบบเต็มจอและอยู่ในสถานะ focus สมบูรณ์ โดยไม่มีกรอบสีแดงที่ขอบ จะถือว่าเป็น flip mode
  • ใช้ dxvk.conf ที่ปรับแต่งตามเงื่อนไขการเปรียบเทียบแต่ละแบบ
    • เมื่อปิด VRR: dxgi.maxFrameRate = 500
    • เมื่อเปิด VRR และปิด dxvk-low-latency: dxgi.maxFrameRate = 497
    • เมื่อเปิด VRR ร่วมกับ dxvk-low-latency ใช้ low-latency VRR frame pacing สำหรับ 500Hz ด้วยการตั้งค่าต่อไปนี้
dxgi.maxFrameRate = 480
dxvk.lowLatencyOffset = 70
dxvk.framePace = "low-latency-vrr-500"
dxvk.lowLatencyAllowCpuFramesOverlap = False
  • ใช้ d3d11.cachedDynamicResources = "c" กับทุก configuration

สภาพแวดล้อมเกมและขั้นตอนการวัดซ้ำ

  • เกมที่ใช้ทดสอบคือเกม DirectX 11 Diabotical ที่รันผ่าน Heroic และ Proton
  • ใช้ native resolution และ render scale 100% ปิด Vsync แล้วลดการตั้งค่าภาพอื่น ๆ ให้ต่ำที่สุดเท่าที่ทำได้
  • ผูกคำสั่งลับที่ซ่อน UI ชั่วคราวเข้ากับการคลิกซ้ายด้วย /bind mouse_left testlatency และจัด HUD ให้แสดงกล่องสีขาวขนาดใหญ่เพื่อเพิ่มความต่างของความสว่างเมื่อคลิก
  • การทดสอบแต่ละครั้งทำซ้ำภายใต้เงื่อนไขเดียวกัน
    • ปิดซอฟต์แวร์ที่ไม่จำเป็น และเริ่ม local server ในโหมดและแผนที่เดียวกัน
    • เล็งเมาส์ไปยังสัญลักษณ์ภูมิประเทศที่กำหนดจากตำแหน่งที่ระบุ
    • ทำกระบวนการ คลิก 100 ครั้ง เป็นเวลาประมาณ 2 นาที รวมทั้งหมด 3 รอบ
    • รักษาฉากให้คงที่ ไม่มี bot, ผู้เล่นอื่น, การเคลื่อนที่ หรือการเริ่มรอบใหม่
    • ไม่ให้มีโปรเซสอื่นที่มีนัยสำคัญทำงาน และตรึงตำแหน่งอุปกรณ์วัดไว้เหมือนกันในทุกการทดสอบ

ช่วงความหน่วงของ configuration ทั้งหมด

  • ทุกกรณีที่จำกัดเฟรมสามารถรักษา FPS เป้าหมายได้อย่างเสถียร และเกมอยู่ในสถานะ คอขวดที่ CPU ตลอดการทดสอบ
  • ทุกกรณีมีการกระจายรูปทรงระฆังโดยไม่มี outlier ขนาดใหญ่ และช่วงตั้งแต่ p5 ถึง p95 อยู่ที่ประมาณ 2~3ms
  • ค่ามัธยฐานของ 8 configuration หลักอยู่ที่ 4.21~4.93ms โดยความต่างรวมมีเพียง 0.72ms
  • XWayland มีค่ามัธยฐานสูงกว่า configuration Native Wayland ที่สอดคล้องกันสูงสุด 3.13ms โดยบันทึกได้ 8.06ms เทียบกับ 4.93ms
  • ในกรณีไม่จำกัด FPS dxvk-low-latency ลดความหน่วงได้ 0.84ms เมื่อเทียบกับ DXVK พื้นฐาน

ความต่างเล็กน้อยระหว่าง X11 กับ Native Wayland

  • X11 เร็วกว่าในทุก configuration แต่ความต่างมีเพียง 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
  • รูปแบบการกระจายความหน่วง ของ display server ทั้งสองก็คล้ายกันมาก

ผลของ VRR ต่อความหน่วงและการกระจาย

  • VRR มีผลมากที่สุดในบรรดารายการเปรียบเทียบ โดยเร็วขึ้น 0.26~0.45ms ในทุก combination
    • 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 อยู่ที่ 2.1~2.2ms เมื่อใช้ VRR และ 2.6~3.0ms เมื่อไม่ใช้ แสดงว่าการกระจายความหน่วงแคบลงด้วย
  • ใน VRR เฟรมจะ scan out ทันทีเมื่อพร้อม โดยไม่ต้องรอ scanout slot ถัดไป ดังนั้นผลการวัดจึงสอดคล้องกับวิธีการทำงาน

ผลและต้นทุนของ dxvk-low-latency

  • ในกรณีจำกัด FPS dxvk-low-latency ลดความหน่วงได้ในทุก combination โดยมีค่าเฉลี่ยการปรับปรุง 0.20ms ซึ่งใกล้เคียงกับความต่างเฉลี่ย 0.18ms ระหว่าง X11 กับ Wayland
    • 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 pacer แสดงผลชัดเจนขึ้นในการป้องกัน render queue สะสม และลด frame pacing ที่ไม่สม่ำเสมอ
    • ไม่ทำให้ GPU อิ่มตัวเต็มที่ และคงสถานะไว้ใกล้คอขวดที่ GPU
    • GPU usage อยู่ที่ 100% ใน DXVK พื้นฐาน และ 95~97% ใน dxvk-low-latency
    • ความหน่วงลดจาก 5.27ms เป็น 4.43ms หรือลดลง 0.84ms
    • FPS ลดลง 45FPS จาก 715 เหลือ 670

ความหน่วงขนาดใหญ่ที่ XWayland เพิ่มเข้ามา

  • หากปิด Enable Wine-Wayland (Experimental) ของ Heroic Launcher หรือ PROTON_ENABLE_WAYLAND=1 เกมจะรันผ่าน XWayland
  • XWayland เพิ่มความหน่วงมากกว่า Native Wayland
    • เปิด low-latency: เพิ่มจาก 4.83ms เป็น 5.95ms หรือเพิ่มขึ้น 1.12ms
    • DXVK พื้นฐาน: เพิ่มจาก 4.93ms เป็น 8.06ms หรือเพิ่มขึ้น 3.13ms
  • 3.13ms ที่เพิ่มขึ้นใน DXVK พื้นฐานนั้นมากกว่าผลของปัจจัยอื่นทั้งหมดที่วัดรวมกัน และไม่ใช่เพราะเฟรมแย่บางเฟรมดันค่าเฉลี่ยขึ้น แต่ทั้ง distribution ขยับไป
  • เมื่อเพิ่ม dxvk-low-latency บน XWayland ความหน่วงลดลง 2.11ms ซึ่งเป็นการปรับปรุงมากที่สุดในทุกกรณี

ขอบเขตการนำผลไปใช้และการตีความในการใช้งานจริง

  • ผลการวัดจำกัดอยู่ที่ เงื่อนไขที่เหมาะที่สุด คือ FPS ที่จำกัดไว้อย่างเสถียร, คอขวดที่ CPU, ฉากคงที่ และ hardware·software stack เฉพาะ
  • ในสภาพแวดล้อมอื่น ค่า absolute latency อาจแตกต่างไป แต่การเพิ่มลดที่เกิดขึ้นในแต่ละ configuration น่าจะถ่ายโอนแนวโน้มได้โดยทั่วไป
  • บนจอแสดงผลที่ refresh rate ต่ำกว่า VRR และ low-latency pacer อาจให้ผลปรับปรุงมากขึ้น
  • X11 เร็วกว่า Wayland 0.14~0.22ms แต่ความต่างอาจแคบลงจากงานปรับแต่ง KWin และยังมีความเป็นไปได้ว่า Wayland compositor อื่นอาจดีกว่าอยู่แล้ว
  • หากไม่นับ XWayland การใช้ X11·VRR·dxvk-low-latency ทั้งหมดร่วมกันทำให้ค่ามัธยฐานต่ำกว่า configuration Wayland พื้นฐาน 0.72ms
  • แม้ความต่างของค่ามัธยฐานจะเล็ก แต่ VRR ลด latency jitter และ dxvk-low-latency ช่วยบรรเทา frame time drop และสถานการณ์คอขวดที่ GPU ที่เกิดขึ้นในเกมจริง

โปรเจกต์วัด input latency ที่คล้ายกัน

  • m2p-latency ของ David Ramiro และ ผลเปรียบเทียบ X11·Wayland ได้ผลคล้ายกันคือ Native X11 กับ Wayland ใกล้เคียงกันที่ประมาณ 7ms และบน XWayland ความหน่วงเพิ่มเป็นประมาณ 2 เท่า
  • farnoy ทำการวัดอย่างกว้างขวางใน Linux latency measurements and compositor tuning โดยใช้ Open-Source-LDAT แล้วสรุปว่าควรหลีกเลี่ยง XWayland
  • การวัด input latency ด้วย VK_EXT_present_timing ของ Themaister ฉีดอินพุตผ่าน /dev/uinput โดยไม่ใช้ฮาร์ดแวร์ภายนอก และตรวจจับการเปลี่ยนภาพบน GPU
    • เนื่องจากตัดความหน่วงของ USB และจอแสดงผลออก จึงไม่ได้วัดความหน่วงระบบแบบ end-to-end แต่วัดเฉพาะ ความหน่วงภายใน PC
    • implementation เผยแพร่ไว้ที่ latency-measurement-layer ของ pyrofling

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 3 시간 전
ความคิดเห็นใน Hacker News

  • ข้อดีของ Linux คือไม่เพียงทำการวิเคราะห์แบบนี้ได้ แต่ยังนำไปสู่ การปรับปรุงระบบนิเวศ ได้จริง ผลลัพธ์จะถูกส่งต่อไปยังนักพัฒนาซอฟต์แวร์กราฟิกและผู้ดูแลแพ็กเกจของดิสโทร แต่ในฝั่ง Microsoft ดูเหมือนจะคาดหวังเส้นทางการปรับปรุงแบบนี้ได้ยาก
    หลังจากใช้ Windows มานาน เพิ่งย้ายมา Linux ไม่นานนี้ และชอบที่ KDE Plasma ให้ความรู้สึกตอบสนองไวกว่า Windows 11 อีกทั้งถ้ามีปัญหาก็ลงมือแก้และปรับปรุงเองได้ หากไม่ได้ลองใช้เดสก์ท็อป Linux มาสักพัก ขอแนะนำ Bazzite ซึ่งเป็น Fedora ที่ปรับแต่งมาสำหรับเล่นเกม และแม้จะไม่เล่นเกมก็สามารถจัดเดสก์ท็อปที่สมบูรณ์ได้อย่างรวดเร็ว

    • หวังว่าความหมายนั้นจะนำไปสู่การปรับปรุงจริง ๆ ผมใช้ Linux เป็นระบบปฏิบัติการหลักและชอบมัน แต่สภาพแวดล้อมเดสก์ท็อปกับส่วนประกอบรอบ ๆ ซับซ้อนขึ้นมาก ขณะที่แย่กว่าเดิม
      เมื่อก่อนสามารถปรับได้ตามต้องการด้วยไฟล์ตั้งค่าที่เข้าใจง่ายเพียงไฟล์เดียว แต่ตอนนี้แม้จะมีชั้น abstraction มากมายสำหรับธีม ไอคอน โหมดสว่าง โหมดมืด ก็ยังหาชุดที่ทำงานได้ถูกต้องได้ยาก ในโหมดสว่างมีตัวอักษรสีเทาบนพื้นเทาอ่อน ส่วนในโหมดมืดก็มีตัวอักษรสีดำบนพื้นหลังสีดำ และบางครั้งแม้แต่ PDF viewer ก็ยังเลือกสีตัวอักษรกับพื้นหลังให้ถูกต้องไม่ได้ ขึ้นอยู่กับธีมอย่าง Adwaita
      ไม่มีธีมไหนทำให้ scrollbar มองเห็นได้ชัดพอ และก็ไม่แยกหน้าต่างที่ active กับ inactive ด้วยสีที่ชัดเจน แม้แต่ Windows 3.11 ยังทำ scrollbar, การแสดงหน้าต่าง active และการปรับแต่งสีได้ดีกว่า เรียกได้ว่าก่อนจะออกแบบมากเกินไปกลับดีกว่าเสียอีก
    • Microsoft ก็น่าจะสามารถรวบรวม ข้อมูล telemetry จากอุปกรณ์หลายล้านเครื่องได้ด้วยการตั้งค่าเพียงอย่างเดียว แล้วส่งต่อให้ผู้พัฒนาซอฟต์แวร์กราฟิก
      Intel(https://www.techpowerup.com/312122/psa-intel-graphics-driver...) และ Nvidia(https://nateshoffner.com/blog/2017/05/disable-nvidia-telemet...) ก็รวบรวมข้อมูลลักษณะนี้จากผู้ใช้ที่ยินยอมเช่นกัน อย่างไรก็ตามทั้งสองเป็นแบบ opt-in ดังนั้นข้อมูลจากเกมเมอร์ตัวยงอาจมีไม่มาก
    • บางอย่างก็ปรับปรุงได้จริง แต่ก็มีบางด้านที่ต้องอาศัย ความร่วมมือขนาดใหญ่ ซึ่งผู้ใช้สาย hobbyist หรือบริษัทขนาดเล็กแบกรับไม่ไหว ตัวอย่างเช่นการใช้การปรับเทียบสีให้สอดคล้องกันกับทุกแอปพลิเคชัน หรือการรองรับฟีเจอร์ขั้นสูงของพรินเตอร์อย่างถูกต้อง
      แม้จะมีการเปลี่ยนแปลงแบบค่อยเป็นค่อยไปมากมาย แต่ก็มักติดอยู่ที่จุดเหมาะสมเฉพาะส่วนเป็นเวลาหลายปี ถึงอย่างนั้นการที่มองเข้าไปดูการทำงานภายในได้ค่อนข้างง่ายก็เป็นเรื่องดี และก็ไม่ค่อยเข้าใจว่าทำไม Windows กับ macOS จำเป็นต้องเป็นซอร์สปิดเสมอไป
    • บน Windows ก็ทำได้ตั้งแต่ patch การเรียก kernel API, แทนที่การสร้าง COM object, ติดตั้ง filter driver เพื่อดัก device request ไปจนถึงเปลี่ยน DLL ใน user space หากค้นหา API บางตัวก็ถึงขั้นเจอฟอรัม blackhat หรือวิธีเขียน exploit ได้เลย เป็น การแทรกแซงที่ทรงพลังและอันตราย จนบางครั้งก็สงสัยว่าทำไมถึงอนุญาตให้ทำได้
    • ที่ดียิ่งกว่านั้นคือเทคโนโลยีสแต็กส่วนใหญ่เป็น โอเพนซอร์ส จึงสามารถมีส่วนร่วมโดยตรงได้ด้วย

  • เมื่อไม่กี่เดือนก่อนผมเปลี่ยนระบบปฏิบัติการหลักและสภาพแวดล้อมสำหรับเล่นเกมมาเป็น Fedora แล้วรู้สึกว่าโดยรวมตอบสนองไวกว่า Windows และการวัดนี้ก็ช่วยตอบคำถามบางส่วนเกี่ยวกับ input latency ในเกมได้
    ช่วงหลังย้ายมาใช้ Hyprland บน Wayland จึงอยากรู้ว่าผลจะต่างไปอย่างไร และเนื่องจากมันได้รับความนิยมมากขึ้น ก็อยากให้ทดสอบซ้ำอีกครั้ง เคยพิจารณา Gamescope ด้วย แต่ได้ยินมาว่าทำงานบน Nvidia ได้ไม่ดีนัก และเพิ่งรู้ครั้งนี้เองว่ามีสิ่งที่เรียกว่า kernel สำหรับปรับแต่งเกม ในเกมต่อสู้แข่งขัน input latency สำคัญมาก จึงอยากฟังประสบการณ์ของคนที่เคยปรับแต่งแบบคล้ายกัน

    • ความต่างของ input latency ในการทดสอบทั้งหมด ยกเว้น XWayland นั้นเล็กจนมนุษย์แยกไม่ออก และแม้แต่ ความต่าง 3ms ของ XWayland ถ้ามีคนสังเกตได้ก็คงน่าทึ่ง บนจอที่ช้ากว่า ความต่างอาจใหญ่ขึ้นได้ แต่ความต่างของโปรโตคอล Wayland กับ X11 เองนั้นน้อยมาก และดูเหมือนข้อจำกัดจะอยู่ที่ implementation ของ XWayland
    • การเพิ่ม FPS จากการเปลี่ยน kernel โดยทั่วไปมีเพียงเล็กน้อย ดังนั้นคุ้มหรือไม่ก็ต้องตัดสินใจกันเอง ความต่างหลักอยู่ที่ scheduler ซึ่งให้ความสำคัญกับโปรเซสที่รันแบบสั้น ๆ แต่เข้มข้น แทนที่จะกระจายเวลา CPU ให้เท่า ๆ กัน
      สำหรับเกม ผมชอบ Hyprland และการตั้งค่ารายละเอียดอย่าง variable refresh rate กับ tearing ผ่าน Gamescope ก็ง่ายกว่าสมัยใช้ AwesomeWM บน X11 ส่วนการตั้งค่าด้วย Lua ก็รู้สึกคุ้นเคยในฐานะคนที่เคยใช้ AwesomeWM
    • การรัน Gamescope บน TTY แยก แล้วเปิด Steam หรือ Heroic Launcher โดยตรง เป็นการตั้งค่าที่ทำงานได้ดีมากอยู่แล้ว เพราะเล่นเกมแบบเต็มจอจึงไม่จำเป็นต้องมี window manager และปัญหา HDR ก็ถูกแก้ไปด้วย แต่ปุ่มปรับเสียงกับความสว่างกลับไม่ทำงาน
    • บน OpenSUSE ก็คล้ายกัน แต่จุดอ่อนของ Wayland คือ การสตรีมเกม Sunshine/Moonlight ใช้งานได้ก็จริง แต่ input latency กับความผิดปกติของภาพเห็นได้ชัด จึงสลับไปมาระหว่าง X11 ที่ดีกว่าสำหรับการสตรีมกับ Wayland อยู่ หวังว่าเมื่อเวลาผ่านไปจะได้ใช้ Wayland อย่างเดียว

  • การทดสอบนี้ใช้ จอ 500Hz จึงอาจบดบังปัญหาหลายอย่างที่จะเกิดบนจอ refresh rate ต่ำกว่า การที่ XWayland ช้ากว่า 3ms อาจหมายถึงตามหลังหนึ่งเฟรมที่ refresh rate นี้ก็ได้
    หากทดสอบที่ 120Hz หรือ 60Hz น่าจะแยกแยะความต่างเล็กน้อยของจังหวะการรัน กับผลกระทบขนาดใหญ่จากการช้ากว่าทั้งหนึ่งเฟรมได้ชัดเจนขึ้น

  • ตอนท้ายบทความ ผู้เขียนสงสัยว่าทำไม Wayland ถึงถูกมองว่าช้า แต่ ผลลัพธ์ของ XWayland อาจเป็นเหตุผลนั้นเอง เป็นไปได้ว่าผู้ใช้ที่รันเกม X11 บน Wayland รู้สึกถึงความหน่วงอย่างมีนัยสำคัญ คงจะดีถ้ามีการวัดจริงแบบนี้มากขึ้นในหลาย ๆ ด้าน

    • สิ่งที่ให้ผลแย่มีแค่ XWayland เท่านั้น และความต่างก็แค่ไม่กี่มิลลิวินาที จึงยากจะเชื่อว่ามนุษย์จะรู้สึกได้ ถ้าเป็น 10~20ms ก็พอเข้าใจได้ แต่แค่ไม่กี่มิลลิวินาทีนั้นน่าสงสัย
      ผู้เขียนกำจัดตัวแปรปะปนอื่น ๆ ได้ดี แต่ผู้ใช้ที่รู้สึกว่า Wayland ช้าอาจเริ่มจากสภาพแวดล้อมที่ไม่ได้ปรับแต่ง แล้วเมื่อเปลี่ยนไปใช้การตั้งค่าความหน่วงต่ำ ก็แก้การตั้งค่าที่เกี่ยวข้องไปพร้อมกันด้วย
    • เคยเข้าใจว่า Wayland จะมีความหน่วง หนึ่งเฟรม มากกว่า Xorg เสมอเพื่อป้องกันการฉีกของภาพ จึงสงสัยว่าตอนนี้เปลี่ยนไปแล้วหรือไม่ ถ้าเป็นเช่นนั้น อัตรารีเฟรชที่สูงมากก็คงทำให้ผลกระทบนั้นเล็กลง
    • ใช้ Linux มาตั้งแต่กลางทศวรรษ 1990 แต่แยกความต่างระหว่าง X11 กับ Wayland ไม่ออกเลย และไม่สนใจข้อถกเถียงนี้ด้วย ดูเหมือนเป็นการวนซ้ำของการถกเถียงแบบ Vim vs Emacs, GNOME vs KDE พอเห็นคำบ่นที่เกี่ยวข้องตอนนี้ก็ปิดหน้าเว็บไปเลย
    • ทดสอบคอมโพซิเตอร์ Wayland แค่ตัวเดียว แล้วจะพูดถึงประสิทธิภาพของคอมโพซิเตอร์ Wayland ทั้งหมดไม่ได้ โดยเฉพาะส่วนขยายของ Wayland ที่จำเป็นต่อการจัดการอุปกรณ์อินพุต(https://wayland.app/protocols/) นั้นต่างกันมากในแต่ละการใช้งาน
      ต่างจาก X11 ที่ Xorg ซึ่งเป็น implementation อ้างอิงมาตรฐานโดยพฤตินัยแทบทุกที่ทำงานคล้ายกัน ความแตกต่างระหว่าง implementation ของ Wayland นั้นมีมาก อาจมีคอมโพซิเตอร์ที่ช้ากว่า KDE Plasma ที่ใช้ทดสอบ และอาจมีตัวที่เร็วกว่าด้วย
    • หากจะตัดสินว่า Wayland เร็วหรือช้า จำเป็นต้องมี ข้อมูลสภาพแวดล้อมทั้งหมด เช่น เวอร์ชันเกม, display server และการตั้งค่า, การตั้งค่าเกม, ความสามารถของจอภาพและการ์ดจอ, เวอร์ชันไดรเวอร์ เป็นต้น

  • คำว่า ความหน่วงอินพุตของ Wayland เองก็เป็นการปนกันของคนละเลเยอร์ คล้ายกับ ความลื่นของแอนิเมชัน HTTP สิ่งที่บทความนี้วัดคือ Xorg, KWin และ XWayland ส่วน implementation อื่น ๆ ของ X11·Wayland อาจมีคุณลักษณะแตกต่างกัน
    อย่างไรก็ตาม ความหน่วงเพิ่มเติมของ XWayland นั้นมากจนน่าสงสัยเกินกว่าจะมองว่าเป็น overhead ธรรมดา

    • บทความอื่นสงสัยว่า ไดรเวอร์ Nvidia เป็นสาเหตุ: https://davidjusto.com/articles/m2p-latency/#results
    • ควรทดสอบซ้ำบน GNOME ด้วย แม้ไม่ได้ขุดลึก แต่คอมโพซิเตอร์ Wayland ของ GNOME ดูเหมือนจะเร็วกว่าและออกแบบอย่างละเอียดรอบคอบกว่า KWin
      โดยเฉพาะ Emacs ในโหมด pgtk ทำงานบน GNOME ได้ดีกว่ามาก แต่บน KWin จะใช้ CPU มากตอนเลื่อนหน้าจอ และบนความละเอียดสูงก็มีความหน่วงเล็กน้อยด้วย
    • ตรรกะรอบ Wayland บางครั้งก็น่ารำคาญ ก่อนอื่นบอกว่า X ถูกกำหนดให้เลิกใช้ไปนานแล้ว ให้ย้ายไป Wayland ซึ่งเป็นอนาคต แต่เมื่อผู้ใช้บอกว่ามันพังหรือแย่ลง ก็กลับตอบว่า Wayland เป็นแค่โปรโตคอล และเป็นความผิดของ implementation แต่ผู้ใช้ใช้งานได้ดีอยู่แล้วบน X

  • ถ้า เปรียบเทียบกับ Windows บนฮาร์ดแวร์เดียวกัน ผลจะออกมาอย่างไรก็น่าสนใจมากเช่นกัน

  • ที่ Breaka Club กำลังรับมือกับปัญหานี้โดยตรง โดยใช้ Overcooked 2! ที่ดัดแปลงแล้วสอนเด็ก ๆ เขียนโค้ด
    เนื่องจากติดตั้งม็อดบนอุปกรณ์ของโรงเรียนได้ยาก จึงสตรีม OC2 ที่มีม็อดผ่าน WebRTC และเด็ก ๆ เล่นด้วยเกมแพดบนหน้าจอใน Mobile Safari บน iPad อินสแตนซ์ของเกมรันในคอนเทนเนอร์ Docker บน Kubernetes/k3s บนฮาร์ดแวร์ Nvidia รุ่นเก่า และต้องผ่านอินเทอร์เน็ตกับเครือข่ายโรงเรียน จึงใช้ การส่งแบบไม่คัดลอกข้อมูล ของ NVEnc และ DMABuf เป็นต้น เพื่อลดความหน่วงรวม
    ตอนนี้กำลังเจอ overhead อินพุตของ XWayland แต่เนื่องจากอินพุตเป็นอุปกรณ์เสมือน ลักษณะอาจต่างออกไป การปรับแต่งแบบ end-to-end นั้นยาก และประสิทธิภาพปัจจุบันก็อยู่ในระดับที่ยอมรับได้ วิดีโอการเขียนโค้ด OC2: https://www.youtube.com/watch?v=ITWSL5lTLig
    ไลเซนส์ OC2 ซื้อไว้ในจำนวนจำกัด เมื่อ pod เริ่มทำงานจะได้รับการจัดสรรหนึ่งไลเซนส์ และถ้าใช้งานครบทั้งหมดแล้ว เด็ก ๆ ก็จะเล่นเกมอื่นแทน

  • เมื่อใช้การเรนเดอร์แบบ compositing บน X11 หากหน้าต่างเต็มจอส่ง hint สำหรับยกเลิกการ redirect ไปยังคอมโพซิเตอร์ ก็สามารถหยุด compositing ขณะที่ไม่มีองค์ประกอบอื่นวาดบนหน้าจอ และส่ง swapchain ของแอปพลิเคชันตรงไปยังหน้าจอได้ วิธีนี้ถือว่าเหมาะที่สุดในทางปฏิบัติ จึงปรับปรุงให้ดีกว่านี้ได้ยาก
    หากมีหน้าต่างอื่นปรากฏอยู่ด้านบน หรือคอมโพซิเตอร์ตัดสินว่าไม่สามารถส่งตรงได้ ก็จะเกิดขั้นตอนกลางที่ composite หน้าต่างของแอปพลิเคชันกับองค์ประกอบอื่นลงในบัฟเฟอร์ชั่วคราว หากการยกเลิก redirect พัง เช่น หน้าต่างถูกสร้างให้เตี้ยกว่าความสูงหน้าจอ 1 พิกเซล หรือใช้ XWayland ความหน่วงอาจเพิ่มขึ้นได้ และนี่เป็นข้อจำกัดพื้นฐาน จึงเกิดปัญหาคล้ายกันกับคอมโพซิเตอร์ของระบบปฏิบัติการอื่นด้วย
    Wayland ได้สำรวจ display planes ซึ่งเป็นการที่ฮาร์ดแวร์ GPU composite หลายเลเยอร์โดยตรงด้วย หากใช้สิ่งนี้ เกมจะเรนเดอร์ที่จำนวนเฟรมต่อวินาทีสูงสุด และหน้าต่างด้านบนจะถูกวาดบน plane แยกต่างหาก ทำให้ composite ได้โดยไม่มีผลข้างเคียง แต่ไม่ทราบว่ามีการใช้งานในสภาพแวดล้อมผลิตภัณฑ์จริงอยู่หรือไม่

  • คอนโซลมักมุ่งไปที่จำนวนเฟรมต่อวินาทีของเอาต์พุตที่คงที่และความละเอียดแบบไดนามิก ขณะที่ PC มีแนวโน้มจะล็อกความละเอียดไว้ แล้วปล่อยให้จำนวนเฟรมต่อวินาทีและช่วงเวลาเฟรมเป็นแบบไดนามิก จึงสงสัยว่าสิ่งนี้เกี่ยวข้องกับความหน่วงอย่างไร
    โดยเฉพาะในเกมแข่งขัน มักตั้งเป้าจำนวนเฟรมต่อวินาทีที่สูงกว่าอัตรารีเฟรชของจอมาก แต่ยังไม่แน่ใจว่านั่นเป็นประโยชน์จริงหรือเป็นเพียงความเข้าใจผิด

    • จากมุมมองของคนที่ทำงานด้านเรนเดอร์ จำนวนเฟรมต่อวินาทีที่สูง ช่วยได้ในแบบเฉพาะตัว ตำแหน่งเรนเดอร์ของวัตถุมักถูกกำหนดหลัก ๆ ณ เวลาที่เริ่มเรนเดอร์เฟรม ดังนั้นยิ่งสร้างเฟรมบ่อยเท่าไร วัตถุที่เห็นบนหน้าจอก็ยิ่งใกล้กับตำแหน่งจริงในปัจจุบันมากขึ้นเท่านั้น
      ประเด็นสำคัญไม่ใช่การได้เห็นเฟรมมากขึ้น แต่คือการได้เห็นข้อมูลที่ใหม่กว่า อาจเริ่มเรนเดอร์ให้ช้าลงเพื่อให้เสร็จก่อนหน้าจอรีเฟรชพอดีก็ได้ แต่ถ้าพลาดจังหวะไปเพียงเล็กน้อยก็จะเกิดอาการกระตุกอย่างหนัก และเวลาในการรันของ GPU กับเวลาที่ CPU ส่งงานก็ไม่ได้กำหนดตายตัว
    • จำนวนเฟรมต่อวินาทีที่เกินอัตรารีเฟรชไม่ได้ไร้ความหมายไปทั้งหมด แต่ก็มีการสิ้นเปลืองทรัพยากรอยู่ เพราะแต่ละเฟรมที่แสดงจะสะท้อนสถานะของเกมที่ใหม่กว่า
      ในอุดมคติคือไม่ต้องสร้างเฟรมที่ไม่จำเป็น และเริ่มเรนเดอร์ก่อนหน้าจอรีเฟรชพอดี แต่ถ้าพลาด เดดไลน์ ก็จะเกิดอาการกระตุกที่น่ารำคาญมาก
    • เกม PC หลายเกมก็รองรับความละเอียดแบบไดนามิกเช่นกัน เหตุที่คอนโซลมักตั้งเป้า 60fps ก็เพราะทีวีส่วนใหญ่มีอัตรารีเฟรชเท่านั้น และผู้ใช้ทุกคนใช้ฮาร์ดแวร์แบบเดียวกันหรือมีแค่ไม่กี่คอนฟิก
      เฟรมใหม่สามารถแทรกเข้ามากลางกระบวนการสแกนภาพของจอ ทำให้เกิด tearing แต่ใต้เส้นแบ่งนั้นจะแสดงพิกเซลที่ใหม่กว่า ดังนั้นในหนึ่งเฟรมของมอนิเตอร์อาจมีเฟรมที่เรนเดอร์หลายเฟรมผสมกันได้ และแม้จะไม่ดีเท่าจออัตรารีเฟรชแปรผันที่มีอัตรารีเฟรชสูง แต่ก็ ช่วยลดความหน่วง ได้ ในเกมที่การเคลื่อนไหวไม่สำคัญมาก มักใช้ VSync เพื่อปรับเฟรมให้ตรงกับอัตรารีเฟรชและกำจัด tearing
    • ถ้าเป็นความเข้าใจผิดจริง ก็คงเป็นความเข้าใจผิดที่ทรงพลังพอจะทำให้ผู้เล่นสายแข่งขันยอมเสียรายละเอียดและความละเอียดอย่างมากเพื่อไล่ตามจำนวนเฟรมต่อวินาทีมหาศาล ผมเองก็เห็นความแตกต่าง แต่เพราะผลตอบแทนที่ลดลงเรื่อย ๆ ปกติจึงเลือกความละเอียดสูงและกราฟิกที่ดีกว่า
      บางเกมปรับความละเอียดแบบเรียลไทม์เพื่อรักษาจำนวนเฟรมต่อวินาทีให้คงที่ บน PC แต่เดิมสามารถรันเกมได้แม้สเปกต่ำกว่าเป้าหมายเดิมมาก และจำนวนเฟรมต่อวินาทีต่ำก็เป็นสิ่งที่ยอมรับได้ทางวัฒนธรรมมากกว่า อีกทั้งถ้าไม่ชอบก็อัปเกรดได้ ส่วนคอนโซลไม่มีเส้นทางอัปเกรดและต้องปรับให้เหมาะกับคอนฟิกเดียว การ ลดความละเอียด ก่อนที่ประสิทธิภาพจะตกเกินไปจึงเหมาะสมกว่า
    • แกนหลักของเกมมีลูปขนาดใหญ่ที่รันทุกเฟรมอยู่ หากสร้างเฟรมได้เร็วกว่าอัตรารีเฟรชของจอ โอกาสที่การรีเฟรชหน้าจอครั้งถัดไปจะใช้เฟรมที่ใหม่กว่าก็สูงขึ้น ทำให้ ความหน่วงอินพุตลดลง
      ไม่ได้หมายความว่าเกมได้รับอีเวนต์อินพุตมากขึ้น แต่สามารถประมวลผลและสะท้อนอินพุตได้เร็วขึ้น ไม่ใช่ความเข้าใจผิด แต่ผลตอบแทนลดลงมาก และผลลัพธ์จะแตกต่างกันตามคิวเฟรม, VSync, อัตรารีเฟรชแปรผัน, คอขวด CPU หรือ GPU, รวมถึงโครงสร้างลูปของอินพุตและซิมูเลชัน

  • ผู้เขียนพยายามตัดความเข้าใจผิดออกตั้งแต่แรก แต่สุดท้ายความหน่วงก็ประเมินจากความรู้สึกและประสบการณ์ใช้งานไม่ใช่หรือ คิดว่าสุดท้ายแล้วสิ่งที่ตัวเองรู้สึกคือบททดสอบสุดท้าย และแม้ข้อมูลจะมีประโยชน์ในการวินิจฉัยและแก้ความหน่วงจริง ๆ แต่ใน UI/UX ส่วนใหญ่ การพึ่งพา รสนิยมและความรู้สึกที่รับรู้ได้ ก็น่าจะใช้ได้
    การใช้การประเมินที่ไม่เชิงเทคนิคมากนักควบคู่ไปด้วย เช่น การให้ดาว อาจช่วยไม่ให้การทดสอบและการเก็บข้อมูลจมอยู่กับวิธีวิทยามากเกินไปได้ด้วย ในการทดสอบที่ออกแบบอย่างละเอียด อาจพลาด เงื่อนไขที่ทำให้ประสิทธิภาพลดลง ซึ่งเกิดขึ้นบ่อยในการใช้งานประจำวันของสภาพแวดล้อมเฉพาะนั้น ๆ

    • ในฐานะคนที่เล่นเกมริทึมระดับประเทศ เห็นด้วยได้ยาก ITGmania วัดความแม่นยำเป็นหน่วย 0.1ms และถ้าความหน่วงของฮาร์ดแวร์แกว่งระหว่างเซสชันหรือระหว่างเล่น คะแนนก็พัง สภาพแวดล้อมที่ไม่สม่ำเสมอน่ารำคาญอย่างยิ่ง ไม่ควรมองความหน่วงเป็นเรื่องของความรู้สึกหรือบรรยากาศ
    • TFT TV เครื่องแรกมีความหน่วงอินพุต 2 วินาที จนเล่นเกมไม่ได้ และเรื่องนี้ไม่เกี่ยวกับความรู้สึกเลย แค่ความหน่วง 10ms ก็ส่งผลที่วัดได้แล้ว: https://www.youtube.com/watch?v=5qjSGEOEaXo
    • ในสถานการณ์ที่สำคัญที่สุด นี่ไม่ใช่ความเข้าใจผิด หากผู้เล่น FPS สองคนที่มีฝีมือเท่ากันดวลกัน โดยระบบของฝ่ายหนึ่งมีความหน่วง 4ms และอีกฝ่าย 5ms แม้ทั้งคู่จะไม่รู้สึกถึงความต่างระหว่างสองสภาพแวดล้อม แต่ ฝ่าย 4ms ได้เปรียบในเชิงสถิติ