Linux इनपुट लेटेंसी मापना: X11 बनाम Wayland, VRR, DXVK

 (marco-nett.de)
1 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 500Hz डिस्प्ले पर क्लिक से लेकर स्क्रीन की ब्राइटनेस बदलने तक मापने पर पाया गया कि X11·VRR·dxvk-low-latency तीनों लागू करने पर भी डिफ़ॉल्ट Wayland की तुलना में end-to-end latency median सिर्फ 0.72ms कम हुई
  • native Wayland, X11 से 0.14~0.22ms धीमा था, जबकि XWayland ने native Wayland के मुकाबले अधिकतम 3.13ms अतिरिक्त जोड़े, जिससे कहीं बड़ा अंतर बना
  • variable refresh rate (VRR) ने सभी तुलना में latency को 0.26~0.45ms घटाया, और p5~p95 distribution width को 2.6~3.0ms से 2.1~2.2ms तक संकरा किया
  • dxvk-low-latency ने frame limit होने पर 0.10~0.29ms और limit हटाने पर 0.84ms घटाया, लेकिन दूसरे मामले में GPU utilization को 100% के बजाय 95~97% पर रखते हुए FPS 715 से घटकर 670 हो गया
  • नतीजे स्थिर FPS और CPU bottleneck जैसी ideal conditions तथा खास hardware·software संयोजन पर आधारित हैं, इसलिए वास्तविक gameplay में VRR की jitter कमी और frame pacer की render queue suppression median से बड़ा अंतर ला सकती है

ऑप्टिमाइज़ेशन सलाह को सीधे सत्यापित करने की वजह

  • Linux gaming में Wayland की जगह X11 इस्तेमाल करना, compositing बंद करना, latency-optimized DXVK fork, gaming kernel scheduler, gamescope·gamemode·environment variable जैसे अनगिनत optimization सुझाव मौजूद हैं
  • competitive FPS में कम latency, consistent frame time और high FPS महत्वपूर्ण हैं, लेकिन यह पता लगाना मुश्किल होता है कि setting बदलने से वास्तव में सुधार हुआ या वह placebo या उलटा असर है
  • मापन डिवाइस का hardware, enclosure, firmware, analysis code और raw data click2photon GitHub repository में सार्वजनिक हैं

क्लिक से स्क्रीन बदलाव तक मापने वाला डिवाइस

  • डिवाइस को मॉनिटर पर लगाकर USB से mouse click generate किया गया, फिर photosensor के स्क्रीन बदलाव detect करने तक का समय मापकर end-to-end system latency निकाली गई
  • शुरुआती डिज़ाइन उस समय उपलब्ध OSLTT के circuit diagram पर आधारित था, और अंतिम निर्माण के दौरान m2p-latency तथा Open-Source-LDAT के ideas भी जोड़े गए
  • निर्माण के लिए microcontroller, soldering, Arduino firmware, integration time, transimpedance amplifier, KiCad और enclosure design की ज़रूरत पड़ी
  • Adafruit QT Py RP2040 1,000Hz polling USB HID mouse की तरह काम करता है और click generate करता है
    • click भेजने के तुरंत बाद से लगभग हर 24µs पर photodiode sample लिया जाता है
    • हर click पर 12,000 sample serial connection के ज़रिए host को भेजे जाते हैं और CSV में दर्ज किए जाते हैं
    • host tool हर click के लिए baseline निकालता है और baseline से एक तय स्तर से अधिक हटने वाला पहला sample ढूंढता है
    • 12,000 sample का collection time fixed होने से click transmission से screen brightness change तक का समय निकाला जा सकता है

तुलना की गई display·rendering configurations

  • X11 और native Wayland की तुलना करके यह देखा गया कि Wayland के महसूस होने वाले धीमेपन का दावा मापन से मेल खाता है या नहीं
  • G-Sync·FreeSync सहित variable refresh rate (VRR) के on/off की तुलना की गई
  • dxvk-low-latency और default DXVK के बीच अंतर मापा गया
    • इस fork का frame pacer आधिकारिक proton-cachyos package में integrated है और PROTON_DXVK_LOWLATENCY=1 से enable होता है
  • यह जांचने के लिए कि frame pacer frame time variation absorb करता है और render queue buildup रोकता है या नहीं, FPS limit हटाए गए 2 मामले भी जोड़े गए
    • static game scene में frame time variation नहीं था और test भी CPU bottleneck condition में था, इसलिए यह वास्तविक game session को पूरी तरह reflect नहीं करता
    • वास्तविक session में game के अंदर की स्थिति या दूसरे process के resource usage के अनुसार frame time बदल सकता है
  • Wayland test डिफ़ॉल्ट रूप से PROTON_ENABLE_WAYLAND=1 के साथ native Wayland पर चलाए गए, और तुलना के लिए VRR off वाले XWayland के 2 मामले भी मापे गए

test hardware और software

  • test के दौरान सिर्फ एक display जुड़ा था और hardware configuration यह थी
    • AMD Ryzen 7 5800X3D
    • NVIDIA GeForce RTX 4070 SUPER
    • DDR4 3,200MHz 8GB modules 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 इस्तेमाल किया गया
    • CachyOS का default kernel scheduler ही रखा गया

display और DXVK settings

  • system refresh rate को 500Hz पर सेट किया गया
  • X11 में nvidia-settings से flip mode और VRR enable किए गए, और VRR बदलने के लिए reboot ज़रूरी था
  • Wayland में KDE settings से VRR enable किया गया और reboot की ज़रूरत नहीं थी
  • Wayland का flip mode या direct scanout user सीधे सेट नहीं करता, compositor हर frame पर इसका फैसला करता है
    • KWin Debug Console के Effects tab में showcompositing enable किया गया
    • जब सिर्फ game fullscreen में दिखे, पूरा focus उसी पर हो, और किनारों पर लाल border न हो, तो उसे flip mode माना गया
  • हर comparison condition के लिए optimized dxvk.conf इस्तेमाल किया गया
    • VRR disabled होने पर dxgi.maxFrameRate = 500
    • VRR enabled और dxvk-low-latency disabled होने पर dxgi.maxFrameRate = 497
    • VRR और dxvk-low-latency दोनों enabled होने पर 500Hz के लिए low-latency VRR frame pacing के लिए ये settings इस्तेमाल हुईं
dxgi.maxFrameRate = 480
dxvk.lowLatencyOffset = 70
dxvk.framePace = "low-latency-vrr-500"
dxvk.lowLatencyAllowCpuFramesOverlap = False
  • सभी configurations पर d3d11.cachedDynamicResources = "c" लागू किया गया

game environment और repeat measurement procedure

  • test game Heroic और Proton के साथ चलाया गया DirectX 11 game Diabotical था
  • native resolution और 100% render scale के साथ Vsync off रखा गया, और बाकी video settings को जितना संभव हो उतना कम किया गया
  • UI को थोड़ी देर छिपाने वाले hidden command को /bind mouse_left testlatency से left click पर bind किया गया, और click पर brightness difference बढ़ाने के लिए बड़ा सफेद box दिखाने वाला HUD बनाया गया
  • हर test को एक जैसे conditions में दोहराया गया
    • गैर-ज़रूरी software बंद करके वही mode और map वाला local server शुरू किया गया
    • तय स्थान पर mouse को खास terrain marker पर align किया गया
    • लगभग 2 मिनट में 100 clicks की प्रक्रिया कुल 3 बार दोहराई गई
    • bots, दूसरे players, movement, round restart के बिना static scene बनाए रखा गया
    • यह सुनिश्चित किया गया कि कोई और meaningful process न चल रहा हो, और मापन डिवाइस की position भी हर test में स्थिर रखी गई

पूरी configuration की latency range

  • frame limit लगाए गए सभी मामलों में target FPS स्थिर रहा, और game पूरे test के दौरान CPU bottleneck में था
  • सभी मामलों में बड़े outlier के बिना bell-shaped distribution दिखी, और p5 से p95 तक की चौड़ाई लगभग 2~3ms थी
  • मुख्य 8 configurations का median 4.21~4.93ms था, यानी कुल अंतर सिर्फ 0.72ms था
  • XWayland, उसके corresponding native Wayland configuration से median में अधिकतम 3.13ms ज्यादा था; क्रमशः 8.06ms और 4.93ms रिकॉर्ड हुए
  • FPS limit हटाए गए मामलों में dxvk-low-latency ने default DXVK की तुलना में latency 0.84ms घटाई

X11 और native Wayland के बीच छोटा अंतर

  • X11 हर configuration में तेज़ था, लेकिन अंतर सिर्फ 0.14~0.22ms था, जो यह समझाने के लिए काफ़ी नहीं कि Wayland बहुत ज़्यादा धीमा महसूस होता है
    • low-latency और VRR enabled: X11 4.21ms, Wayland 4.38ms, अंतर +0.17ms
    • सिर्फ low-latency enabled: X11 4.64ms, Wayland 4.83ms, अंतर +0.19ms
    • सिर्फ VRR enabled: X11 4.45ms, Wayland 4.67ms, अंतर +0.22ms
    • दोनों disabled: X11 4.79ms, Wayland 4.93ms, अंतर +0.14ms
  • दोनों display servers की latency distribution shape भी बहुत मिलती-जुलती थी

VRR का latency और distribution पर असर

  • VRR ने तुलना की गई चीज़ों में सबसे बड़ा असर दिखाया और हर combination में 0.26~0.45ms की तेजी दी
    • X11 और low-latency: 4.64ms से 4.21ms, यानी 0.43ms की कमी
    • X11 default DXVK: 4.79ms से 4.45ms, यानी 0.34ms की कमी
    • Wayland और low-latency: 4.83ms से 4.38ms, यानी 0.45ms की कमी
    • Wayland default DXVK: 4.93ms से 4.67ms, यानी 0.26ms की कमी
  • p95 और p5 के बीच चौड़ाई VRR के साथ 2.1~2.2ms और बिना VRR के 2.6~3.0ms रही, यानी latency distribution भी संकरी हुई
  • VRR में frame अगला scanout slot इंतज़ार किए बिना तैयार होते ही scanout हो जाता है, इसलिए मापन परिणाम इसके काम करने के तरीके से मेल खाते हैं

dxvk-low-latency का असर और लागत

  • FPS-limited मामलों में dxvk-low-latency ने हर combination की latency घटाई, और औसत सुधार 0.20ms रहा, जो X11 और Wayland के औसत अंतर 0.18ms के करीब है
    • X11 और VRR: 4.45ms से 4.21ms, यानी 0.24ms की कमी
    • X11 और VRR disabled: 4.79ms से 4.64ms, यानी 0.15ms की कमी
    • Wayland और VRR: 4.67ms से 4.38ms, यानी 0.29ms की कमी
    • Wayland और VRR disabled: 4.93ms से 4.83ms, यानी 0.10ms की कमी
  • FPS limit हटाने पर pacer का render queue buildup रोकने और uneven frame pacing कम करने का असर अधिक बड़ा दिखा
    • GPU को पूरी तरह saturate किए बिना उसे GPU bottleneck के करीब रखा गया
    • GPU utilization default DXVK में 100% और dxvk-low-latency में 95~97% था
    • latency 5.27ms से 4.43ms हुई, यानी 0.84ms की कमी
    • FPS 715 से घटकर 670 हुआ, यानी 45FPS कम

XWayland द्वारा जोड़ी गई बड़ी latency

  • Heroic Launcher में Enable Wine-Wayland (Experimental) या PROTON_ENABLE_WAYLAND=1 बंद करने पर game XWayland के ज़रिए चलता है
  • XWayland ने native Wayland की तुलना में बड़ी latency जोड़ी
    • low-latency enabled: 4.83ms से 5.95ms, यानी 1.12ms की वृद्धि
    • default DXVK: 4.93ms से 8.06ms, यानी 3.13ms की वृद्धि
  • default DXVK में जोड़ी गई 3.13ms बाकी सभी मापे गए प्रभावों के कुल योग से भी बड़ी थी, और यह कुछ खराब frames की वजह से average बढ़ना नहीं था, बल्कि पूरी distribution खिसक गई थी
  • XWayland में dxvk-low-latency जोड़ने पर latency 2.11ms घटी, जो सभी मामलों में सबसे बड़ा सुधार था

नतीजों की लागू सीमा और व्यावहारिक अर्थ

  • मापन के नतीजे स्थिर limited FPS, CPU bottleneck और static scene जैसी ideal conditions तथा खास hardware·software stack तक सीमित हैं
  • दूसरे environment में absolute latency values बदल सकती हैं, लेकिन हर configuration में दिखी बढ़ोतरी-कमी मोटे तौर पर transfer हो सकती है
  • कम refresh rate वाले displays पर VRR और low-latency pacer का सुधार अधिक बड़ा हो सकता है
  • X11, Wayland से 0.14~0.22ms तेज़ था, लेकिन KWin optimization work से यह अंतर कम हो सकता है, और दूसरे Wayland compositors पहले से बेहतर भी हो सकते हैं
  • XWayland को छोड़कर X11·VRR·dxvk-low-latency तीनों लागू करने पर default Wayland configuration की तुलना में median 0.72ms कम हुई
  • median का अंतर छोटा है, लेकिन VRR latency jitter घटाता है, और dxvk-low-latency वास्तविक gameplay में होने वाले frame time drop तथा GPU bottleneck स्थितियों को कम करता है

समान input latency measurement projects

  • David Ramiro के m2p-latency और X11·Wayland comparison results में भी native X11 और Wayland लगभग 7ms पर समान मिले, जबकि XWayland में latency लगभग दोगुनी हो गई
  • farnoy ने Open-Source-LDAT के साथ Linux latency measurements and compositor tuning में व्यापक माप के बाद निष्कर्ष निकाला कि XWayland से बचना चाहिए
  • Themaister का VK_EXT_present_timing आधारित input latency measurement बाहरी hardware के बिना /dev/uinput से input inject करता है और GPU पर image change detect करता है
    • इसमें USB और display latency शामिल नहीं होती, इसलिए यह end-to-end system latency नहीं बल्कि सिर्फ PC internal latency मापता है
    • इसका implementation pyrofling की latency-measurement-layer में सार्वजनिक है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 3 시간 전
Hacker News की राय

  • Linux की अच्छी बात यह है कि इस तरह का विश्लेषण न सिर्फ संभव है बल्कि वास्तव में ecosystem में सुधार तक ले जाता है। नतीजे graphics software developers और distro package maintainers तक पहुँचते हैं, लेकिन Microsoft में ऐसे सुधार के रास्ते की उम्मीद करना मुश्किल लगता है
    मैंने लंबे समय तक Windows इस्तेमाल किया और हाल में Linux पर आया हूँ; KDE Plasma, Windows 11 से ज़्यादा फुर्तीला लगा, और समस्या होने पर उसे खुद ठीक करके बेहतर बनाया जा सकता है, यह बात अच्छी लगी। अगर आपने कुछ समय से Linux desktop नहीं आज़माया है, तो gaming के लिए tuned Fedora, Bazzite की सिफारिश करूँगा; gaming न भी करें तब भी इससे जल्दी एक polished desktop सेटअप किया जा सकता है

    • अच्छा होगा अगर इसका मतलब सचमुच सुधार में बदले। मैं Linux को primary OS की तरह इस्तेमाल करता हूँ और पसंद भी करता हूँ, लेकिन desktop environment और आसपास की configuration पहले से कहीं ज़्यादा जटिल हो गई है, जबकि अनुभव कई मामलों में पहले से खराब हुआ है
      पहले एक सहज config file से चीज़ें मनचाहे तरीके से बदली जा सकती थीं, लेकिन अब theme·icon·light mode·dark mode के लिए अनगिनत abstraction layers बन गई हैं, फिर भी ठीक से काम करने वाला combination ढूँढना मुश्किल है। light mode में हल्के gray पर gray text दिखता है, dark mode में काले background पर काला text, और Adwaita जैसी themes में कभी-कभी PDF viewer भी text और background color सही से तय नहीं कर पाता
      कोई भी theme scrollbar को पर्याप्त स्पष्ट नहीं बनाती, और न ही active window और inactive window को साफ रंगों से अलग दिखाती है। Windows 3.11 भी scrollbar, active window indication और color customization को इससे बेहतर करता था; यानी ज़रूरत से ज़्यादा design करने से पहले हालात उलटे बेहतर थे
    • Microsoft भी शायद एक setting के जरिए करोड़ों devices से telemetry data इकट्ठा करके graphics software developers तक पहुँचा सकता है
      Intel(https://www.techpowerup.com/312122/psa-intel-graphics-driver...) और Nvidia(https://nateshoffner.com/blog/2017/05/disable-nvidia-telemet...) भी opt-in करने वाले users से ऐसा data इकट्ठा करते हैं। हालांकि दोनों ही optional participation model पर हैं, इसलिए संभव है कि hardcore gamers का data बहुत अधिक न हो
    • कुछ चीज़ें वाकई सुधरती हैं, लेकिन कुछ क्षेत्र ऐसे भी हैं जहाँ बड़े पैमाने के सहयोग की ज़रूरत होती है, जिसे hobbyists या छोटी कंपनियाँ संभाल नहीं सकतीं। हर application पर consistent color correction लागू करना या advanced printer features को सही तरह support करना इसके अच्छे उदाहरण हैं
      incremental changes बहुत होते हैं, लेकिन कई बार सालों तक local optimum में फँसे रहते हैं। फिर भी यह अच्छी बात है कि अंदरूनी कामकाज को तुलनात्मक रूप से आसानी से देखा-समझा जा सकता है, और यह साफ नहीं कि Windows और macOS का closed source होना क्यों ज़रूरी है
    • Windows में भी kernel API calls को patch करना, COM object creation को replace करना, device requests को intercept करने वाले filter drivers install करना, और user-space DLLs को बदलना संभव है। किसी खास API को खोजें तो black-hat forums या exploit लिखने के तरीके तक मिल जाते हैं; यानी बहुत शक्तिशाली और जोखिमभरा हस्तक्षेप संभव है, और कभी-कभी हैरानी होती थी कि यह अनुमति क्यों है
    • इससे भी अच्छी बात यह है कि तकनीकी stack का बड़ा हिस्सा open source है, इसलिए आप सीधे योगदान भी कर सकते हैं

  • कुछ महीने पहले मैंने अपना primary OS और gaming environment Fedora में बदला, और यह कुल मिलाकर Windows से ज़्यादा responsive लगा; इस measurement ने game input latency को लेकर मेरी कुछ जिज्ञासाएँ भी दूर कीं
    हाल में मैं Wayland-आधारित Hyprland पर गया हूँ, इसलिए जानना चाहता हूँ कि वहाँ नतीजे कैसे बदलेंगे; इसकी बढ़ती लोकप्रियता को देखते हुए अच्छा होगा अगर इसका फिर से test किया जाए। मैंने Gamescope पर भी विचार किया था, लेकिन सुना है कि यह Nvidia पर अच्छी तरह काम नहीं करता, और gaming-optimized kernel जैसी चीज़ के बारे में भी मुझे पहली बार पता चला। competitive fighting games में input latency बहुत अहम होती है, इसलिए ऐसी optimization आज़माने वाले लोगों के अनुभव सुनना चाहूँगा

    • XWayland को छोड़कर बाकी सभी tests में input latency का अंतर इतना छोटा है कि इंसान शायद उसे महसूस ही न कर पाए, और XWayland का 3ms का अंतर भी अगर कोई पहचान ले तो हैरानी होगी। धीमे monitor पर फर्क बड़ा हो सकता है, लेकिन Wayland और X11 protocols के बीच का मूल अंतर बहुत मामूली है, और XWayland implementation में कुछ सीमाएँ दिखती हैं
    • kernel बदलने से मिलने वाला FPS boost आम तौर पर बहुत मामूली होता है, इसलिए यह मेहनत करना worthwhile है या नहीं, यह हर किसी को खुद तय करना होगा। मुख्य अंतर scheduler में होता है, जो CPU time को बराबर बाँटने के बजाय कम समय के लिए तेज़ी से चलने वाली processes को प्राथमिकता देता है
      gaming के लिए मुझे Hyprland पसंद आया, और X11 पर AwesomeWM इस्तेमाल करने की तुलना में Gamescope के जरिए variable refresh rate और tearing जैसी बारीक settings करना आसान था। Lua configuration भी AwesomeWM का पुराना उपयोगकर्ता होने के नाते परिचित लगी
    • अलग TTY में Gamescope चलाकर सीधे Steam या Heroic Launcher शुरू करने वाला setup बहुत अच्छी तरह काम करता है। चूँकि वैसे भी game full screen में चलाना होता है, इसलिए window manager की ज़रूरत नहीं पड़ती, और HDR की समस्या भी हल हो गई, लेकिन volume और brightness keys ने काम करना बंद कर दिया
    • OpenSUSE में भी अनुभव कुछ ऐसा ही था, लेकिन Wayland की कमजोरी game streaming रही। Sunshine/Moonlight काम तो करते हैं, पर input latency और display artifacts साफ नज़र आते हैं, इसलिए streaming के लिए मैं बेहतर X11 और Wayland के बीच आता-जाता रहता हूँ। उम्मीद है कि समय के साथ केवल Wayland ही पर्याप्त होगा

  • यह test 500Hz display पर किया गया था, इसलिए low-refresh-rate screens पर दिखने वाली कई समस्याएँ शायद छिप गई हों। XWayland का 3ms धीमा होना इस refresh rate पर शायद एक पूरे frame पीछे रह जाने के बराबर भी हो सकता है
    अगर 120Hz या 60Hz पर test किया जाए, तो execution timing के छोटे फर्क और पूरे एक frame की देरी जैसे बड़े असर को अधिक साफ़ तौर पर अलग किया जा सकेगा

  • लेख के अंत में यह समझना कठिन लगता है कि Wayland को धीमा क्यों माना जाता है, लेकिन XWayland के नतीजे ही शायद उसका कारण हो सकते हैं। संभव है कि Wayland पर X11 गेम चलाने वाले उपयोगकर्ताओं ने अर्थपूर्ण latency महसूस की हो। अच्छा होगा अगर अलग-अलग क्षेत्रों में इस तरह के वास्तविक मापन और अधिक हों

    • खराब नतीजे सिर्फ XWayland में थे, और अंतर भी केवल कुछ मिलीसेकंड का था, इसलिए यह मानना कठिन है कि इंसान ने उसे सच में महसूस किया होगा। 10~20ms होता तो बात समझ में आती, लेकिन कुछ मिलीसेकंड पर संदेह होता है।
      लेखक ने दूसरे mixed variables को काफी अच्छी तरह हटाया है, लेकिन जिन उपयोगकर्ताओं ने Wayland को धीमा महसूस किया, वे शायद किसी unoptimized environment से शुरू हुए हों और low-latency setup पर जाते समय उससे जुड़े settings भी साथ में ठीक कर लिए हों
    • मेरा समझना था कि tearing रोकने के लिए Wayland, Xorg की तुलना में हमेशा एक frame की latency बढ़ाता है, लेकिन अब क्या यह बदल गया है, यह जानना चाहूँगा। अगर ऐसा है, तो बहुत ऊँचा refresh rate उस प्रभाव को कम कर देता
    • मैं 1990 के दशक के मध्य से Linux इस्तेमाल कर रहा हूँ, लेकिन X11 और Wayland के बीच कोई फर्क बिल्कुल महसूस नहीं कर पाता, और इस बहस में मेरी कोई दिलचस्पी नहीं है। यह Vim बनाम Emacs, GNOME बनाम KDE जैसी बहसों की पुनरावृत्ति लगती है, इसलिए अब इससे जुड़ी शिकायतें दिखते ही पेज बंद कर देता हूँ
    • सिर्फ एक Wayland compositor को टेस्ट करके सभी Wayland compositors की performance पर बात नहीं की जा सकती। खासकर input device handling के लिए ज़रूरी Wayland extensions(https://wayland.app/protocols/) हर implementation में काफी अलग हैं
      हर जगह लगभग standard reference implementation की तरह काम करने वाले Xorg के कारण X11 आम तौर पर मिलता-जुलता व्यवहार दिखाता है, लेकिन Wayland implementations के बीच का अंतर बड़ा है। टेस्ट में इस्तेमाल किए गए KDE Plasma से धीमे compositor भी हो सकते हैं, और उससे तेज compositor भी
    • Wayland तेज है या धीमा, यह तय करने के लिए game version, display server और उसकी settings, game settings, monitor और graphics card की capabilities, driver version आदि जैसी पूरी environment information चाहिए

  • Wayland input latency जैसी अभिव्यक्ति अपने-आप में HTTP 애니메이션 부드러움 की तरह अलग-अलग layers को मिलाकर बनाई गई बात है। इस लेख ने जो मापा है वह Xorg, KWin और XWayland है; दूसरे X11·Wayland implementations की विशेषताएँ अलग हो सकती हैं
    फिर भी XWayland की अतिरिक्त latency इतनी बड़ी लगती है कि उसे सिर्फ साधारण overhead कहकर टालना संदिग्ध है

    • एक दूसरी पोस्ट में Nvidia driver को कारण होने के रूप में संदेह किया गया है: https://davidjusto.com/articles/m2p-latency/#results
    • GNOME पर भी फिर से टेस्ट करने की जरूरत है। मैंने बहुत गहराई से नहीं देखा, लेकिन GNOME का Wayland compositor, KWin की तुलना में तेज और अधिक सावधानी से डिज़ाइन किया हुआ लगता है
      खासकर pgtk mode वाला Emacs, GNOME पर कहीं बेहतर चलता है, जबकि KWin में scroll करते समय CPU का उपयोग अधिक करता है और high resolution पर थोड़ा lag भी करता है
    • Wayland को लेकर दी जाने वाली दलीलें कभी-कभी परेशान करती हैं। पहले कहा जाता है कि X तो बहुत पहले deprecate हो चुका है, इसलिए भविष्य के Wayland पर जाओ; फिर जब उपयोगकर्ता कहता है कि चीज़ें टूट गईं या बदतर हो गईं, तो जवाब मिलता है कि Wayland तो सिर्फ एक protocol है, गलती implementation की है। लेकिन उपयोगकर्ता के लिए X पर चीज़ें पहले से ठीक चल रही थीं

  • इसी hardware पर Windows से तुलना करने पर क्या नतीजे आएँगे, यह भी बहुत दिलचस्प होगा

  • Breaka Club में modified Overcooked 2! के ज़रिए बच्चों को coding सिखाते हुए इस समस्या से सीधे निपटा जा रहा है
    क्योंकि school devices पर mod install करना मुश्किल है, इसलिए mod शामिल OC2 को WebRTC से stream किया जाता है, और बच्चे iPad के Mobile Safari में on-screen gamepad से खेलते हैं। Game instances पुराने Nvidia hardware पर Kubernetes/k3s के Docker containers में चलते हैं, और internet व school network से होकर गुजरते हैं, इसलिए NVEnc और DMABuf की zero-copy transfer जैसी तकनीकों से end-to-end latency घटाई जा रही है
    फिलहाल XWayland के input overhead का असर है, लेकिन input virtual device होने के कारण पैटर्न अलग हो सकता है। End-to-end optimization कठिन है, और अभी की performance स्वीकार्य स्तर पर है। OC2 coding video: https://www.youtube.com/watch?v=ITWSL5lTLig
    OC2 licenses सीमित संख्या में खरीदे गए हैं; pod शुरू होते समय उसे एक license मिलता है, और अगर सभी उपयोग में हों तो बच्चे कोई दूसरा game खेलते हैं

  • X11 में composited rendering का उपयोग करते समय, अगर fullscreen window compositor को unredirect hint भेजती है, तो जब तक स्क्रीन पर कोई दूसरा तत्व नहीं बन रहा हो, compositing रोकी जा सकती है और application की swapchain सीधे स्क्रीन पर भेजी जा सकती है। यह लगभग आदर्श तरीका है, इसलिए इसे और बेहतर बनाना कठिन है
    अगर ऊपर कोई दूसरी window आ जाए या compositor तय करे कि direct handoff संभव नहीं है, तो application window और दूसरे तत्वों को temporary buffer में composite करने का एक intermediate stage आ जाता है। अगर window स्क्रीन की ऊँचाई से 1 pixel छोटी बन जाए और unredirect टूट जाए, या XWayland उपयोग हो, तो latency बढ़ सकती है; यह एक मूलभूत सीमा है, इसलिए दूसरे operating systems के compositors में भी ऐसी समस्या हो सकती है
    Wayland ने ऐसे display planes भी explore किए हैं जहाँ GPU hardware कई layers को सीधे composite करता है। इससे game अधिकतम frame rate पर render कर सकता है और ऊपर की window अलग plane पर draw की जा सकती है, बिना side effects के compositing के साथ; लेकिन मुझे नहीं पता कि असली product environments में इसका उपयोग हो रहा है या नहीं

  • कंसोल आमतौर पर निश्चित frames per second आउटपुट और dynamic resolution को प्राथमिकता देते हैं, जबकि PC में resolution को स्थिर रखकर frames per second और frame time interval को dynamic रखने की प्रवृत्ति होती है। इसका latency से क्या संबंध है, यह जानने की जिज्ञासा है
    खासकर competitive games में display refresh rate से कहीं अधिक frames per second का लक्ष्य रखा जाता है, लेकिन यह सचमुच लाभ है या भ्रम, इस पर पूरी तरह भरोसा नहीं होता

    • rendering क्षेत्र में काम करने के नज़रिए से देखें तो उच्च frames per second एक अनोखे तरीके से मदद करते हैं। किसी object की rendering position आमतौर पर frame rendering शुरू होने के समय तय होती है, इसलिए जितनी बार frame बनेगा, स्क्रीन पर दिखने वाला object अपनी मौजूदा वास्तविक स्थिति के उतना ही करीब होगा
      मुख्य बात अधिक frames देखना नहीं, बल्कि अधिक ताज़ा जानकारी देखना है। rendering को इतना देर से शुरू किया जा सकता है कि वह screen refresh से ठीक पहले समाप्त हो, लेकिन समय थोड़ा भी चूकने पर भारी stutter होता है, और GPU execution time व CPU के work submission time deterministic नहीं होते
    • refresh rate से अधिक frames per second पूरी तरह निरर्थक नहीं हैं, लेकिन इसमें resource waste ज़रूर है। वजह यह है कि जो भी frame display होता है, वह game state को अधिक हाल का रूप देता है
      आदर्श रूप से, अनावश्यक frames बनाए बिना screen refresh से ठीक पहले rendering शुरू करनी चाहिए, लेकिन अगर deadline छूट जाए तो बहुत खटकने वाला stutter होता है
    • कई PC games भी dynamic resolution support करते हैं। कंसोल आमतौर पर 60fps को लक्ष्य बनाते हैं क्योंकि अधिकांश TV का refresh rate यही होता है और सभी उपयोगकर्ता एक जैसे या कुछ ही hardware configurations का उपयोग करते हैं
      नया frame screen scan के बीच में आ सकता है, जिससे tearing होती है, लेकिन boundary line के नीचे अधिक ताज़ा pixels दिखते हैं। इसलिए monitor के एक frame में कई rendered frames मिल सकते हैं, और भले ही यह high refresh rate वाले variable refresh rate display जितना अच्छा न हो, फिर भी latency कम करता है। जिन games में responsiveness कम महत्वपूर्ण होती है, उनमें tearing हटाने के लिए अक्सर VSync से frame को refresh rate के साथ sync किया जाता है
    • अगर यह भ्रम है, तो competitive players इतने बड़े भ्रम में होंगे कि वे detail और resolution में भारी कटौती करके भी बहुत ऊँचे frames per second का पीछा करते हैं। मुझे भी अंतर दिखता है, लेकिन diminishing returns की वजह से मैं आमतौर पर higher resolution और बेहतर graphics चुनता हूँ
      कुछ games स्थिर frames per second बनाए रखने के लिए real time में resolution समायोजित करते हैं। PC पर मूल लक्ष्य से काफी कम spec पर भी game चलाना संभव था, कम frames per second को सांस्कृतिक रूप से अधिक स्वीकार किया जाता था, और नापसंद हो तो upgrade भी किया जा सकता था। कंसोल में upgrade path नहीं होता और एक ही configuration के लिए optimize करना पड़ता है, इसलिए performance बहुत गिरने से पहले resolution कम करने का तरीका अधिक उपयुक्त था
    • game के मूल में एक बड़ा loop होता है जो हर frame पर चलता है। अगर display refresh rate से तेज़ frames बनाए जाएँ, तो अगली screen refresh के अधिक recent frame उपयोग करने की संभावना बढ़ती है, जिससे input latency घटती है
      इसका मतलब यह नहीं कि game को अधिक input events मिलते हैं, बल्कि यह कि वह input को जल्दी process और reflect कर सकता है। यह भ्रम नहीं है, लेकिन diminishing returns बहुत हैं, और प्रभाव frame queue, VSync, variable refresh rate, CPU या GPU bottleneck, input तथा simulation loop structure के अनुसार बदलता है

  • लेखक शुरुआत से ही भ्रम की संभावना को हटाना चाहते हैं, लेकिन लगता है कि latency का मूल्यांकन आखिरकार एहसास और उपयोग के अनुभव से ही होता है। मेरे हिसाब से व्यक्ति को कैसा महसूस होता है, यही अंतिम परीक्षा है; वास्तविक latency का diagnosis और समाधान करने में data उपयोगी है, फिर भी अधिकांश UI/UX में पसंद और अनुभव पर निर्भर रहना ठीक है
    star rating जैसे कम तकनीकी आकलन साथ में रखने से यह भी रोका जा सकता है कि testing और data collection methodology में ज़रूरत से ज़्यादा फँस जाए। बहुत सटीक रूप से तैयार किए गए test में किसी खास environment के रोज़मर्रा के उपयोग के दौरान बार-बार आने वाली performance degradation conditions छूट सकती हैं

    • राष्ट्रीय स्तर पर rhythm game खेलने वाले के रूप में इससे सहमत होना मुश्किल है। ITGmania accuracy को 0.1ms इकाई में मापता है, और अगर hardware latency session के बीच या दौरान डगमगाए, तो score खराब हो जाता है और असंगत environment बेहद परेशान करने वाला होता है। latency को सिर्फ संवेदना या माहौल के आधार पर नहीं देखना चाहिए
    • शुरुआती TFT TV में input latency 2 सेकंड थी, इसलिए उन पर game खेलना संभव नहीं था, और इसका एहसास से कोई लेना-देना नहीं। केवल 10ms latency से भी मापने योग्य प्रभाव पैदा होता है: https://www.youtube.com/watch?v=5qjSGEOEaXo
    • सबसे महत्वपूर्ण परिस्थितियों में यह भ्रम नहीं है। जब समान कौशल वाले दो FPS players आमने-सामने हों और एक system की latency 4ms हो जबकि दूसरे की 5ms, तब भले ही वे दोनों वातावरणों का अंतर महसूस न कर पाएँ, 4ms वाला पक्ष सांख्यिकीय रूप से लाभ में होगा