- Dari hasil pengukuran pada display 500Hz, mulai dari klik hingga perubahan kecerahan layar, penerapan X11, VRR, dan dxvk-low-latency sekaligus hanya menurunkan median latensi end-to-end sebesar 0,72ms dibanding Wayland bawaan
- Wayland native 0,14~0,22ms lebih lambat daripada X11, sedangkan XWayland menambahkan hingga 3,13ms dibanding Wayland native, menghasilkan selisih yang jauh lebih besar
- Variable Refresh Rate (VRR) mengurangi latensi 0,26~0,45ms di semua perbandingan, dan mempersempit rentang distribusi p5~p95 dari 2,6~3,0ms menjadi 2,1~2,2ms
- dxvk-low-latency mengurangi latensi 0,10~0,29ms saat frame rate dibatasi, dan 0,84ms saat batas dilepas; tetapi pada kondisi terakhir, FPS turun dari 715 menjadi 670 sambil menjaga utilisasi GPU di 95~97%, bukan 100%
- Hasil ini diperoleh dalam kondisi optimal berupa FPS stabil dan bottleneck CPU, serta kombinasi hardware dan software tertentu; dalam permainan nyata, pengurangan jitter oleh VRR dan penekanan render queue oleh frame pacer dapat membuat perbedaan yang melampaui nilai median
Alasan memverifikasi langsung saran optimasi
- Untuk gaming Linux ada banyak saran optimasi, seperti memakai X11 alih-alih Wayland, menonaktifkan compositing, memakai fork DXVK yang dioptimalkan untuk latensi, scheduler kernel untuk gaming, serta menerapkan gamescope, gamemode, dan variabel lingkungan
- Pada FPS kompetitif, latensi rendah, frame time yang konsisten, dan FPS tinggi sangat penting, tetapi sulit memastikan apakah perubahan konfigurasi benar-benar memberi perbaikan atau hanya plasebo atau malah berdampak negatif
- Hardware perangkat pengukur, enclosure, firmware, kode analisis, dan data mentah dipublikasikan di repositori GitHub click2photon
Perangkat untuk mengukur dari klik hingga perubahan layar
- Dengan memasang perangkat ke monitor dan memicu klik mouse via USB, perangkat mengukur latensi sistem end-to-end dengan menghitung waktu hingga sensor cahaya mendeteksi perubahan layar
- Desain awal mengacu pada skematik OSLTT yang tersedia saat itu, dan selama proses penyelesaian juga mengintegrasikan ide dari m2p-latency dan Open-Source-LDAT
- Pembuatannya memerlukan mikrokontroler, penyolderan, firmware Arduino, integration time, transimpedance amplifier, KiCad, dan desain enclosure
- Adafruit QT Py RP2040 beroperasi sebagai mouse USB HID polling 1.000Hz dan menghasilkan klik
- Segera setelah klik dikirim, sampel fotodioda dikumpulkan kira-kira setiap 24µs
- Untuk tiap klik, 12.000 sampel dikirim ke host melalui koneksi serial dan dicatat sebagai CSV
- Tool host menghitung baseline per klik dan mencari sampel pertama yang menyimpang dari baseline lebih dari ambang tertentu
- Karena waktu pengumpulan 12.000 sampel bersifat tetap, waktu dari pengiriman klik hingga perubahan kecerahan layar dapat dihitung
Konfigurasi display dan rendering yang dibandingkan
- X11 dan Wayland native dibandingkan untuk mencocokkan penilaian bahwa Wayland terasa lambat dengan hasil pengukuran
- Perbandingan dilakukan antara Variable Refresh Rate (VRR), termasuk G-Sync dan FreeSync, aktif dan tidak aktif
- Perbedaan antara dxvk-low-latency dan DXVK bawaan diukur
- Frame pacer dari fork ini telah diintegrasikan ke paket resmi
proton-cachyos, dan diaktifkan dengan PROTON_DXVK_LOWLATENCY=1
- Dua kasus tanpa batas FPS ditambahkan untuk memeriksa apakah frame pacer menyerap variasi frame time dan mencegah penumpukan render queue
- Pada adegan game statis, tidak ada variasi frame time, dan pengujian juga berada dalam kondisi bottleneck CPU, sehingga tidak sepenuhnya mencerminkan sesi game nyata
- Dalam sesi nyata, frame time dapat berubah sesuai situasi di dalam game atau penggunaan resource oleh proses lain
- Pengujian Wayland pada dasarnya dijalankan di Wayland native menggunakan
PROTON_ENABLE_WAYLAND=1, dan untuk perbandingan juga diukur 2 kasus XWayland dengan VRR dimatikan
Hardware dan software pengujian
- Selama pengujian, hanya satu display yang tersambung, dengan konfigurasi hardware sebagai berikut
- AMD Ryzen 7 5800X3D
- NVIDIA GeForce RTX 4070 SUPER
- 2 modul DDR4 3.200MHz 8GB
- MSI MAG 272QP QD-OLED X50, 2560×1440, 500Hz
- MSI B450 GAMING PRO CARBON AC
- Software stack terdiri dari CachyOS, Kernel 7.1.3-2-cachyos, NVIDIA driver 610.43.03-1, KDE Plasma 6.7.2-1.1, dan xorg-server 21.1.24-1.1
- Menggunakan
proton-cachyos-native 1:11.0.20260602-3 dan dxvk 3.0
- Scheduler kernel bawaan CachyOS dipertahankan
Pengaturan display dan DXVK
- Refresh rate sistem diatur ke 500Hz
- Di X11, flip mode dan VRR diaktifkan dengan
nvidia-settings, dan perubahan VRR memerlukan reboot
- Di Wayland, VRR diaktifkan lewat pengaturan KDE dan tidak memerlukan reboot
- Flip mode atau direct scanout di Wayland tidak diatur langsung oleh pengguna, melainkan diputuskan compositor per frame
showcompositing diaktifkan pada tab Effects di KWin Debug Console- Jika hanya game yang tampil full-screen, fokus sepenuhnya, dan tidak ada bingkai merah di tepi, kondisi itu dianggap sebagai flip mode
dxvk.conf yang dioptimalkan untuk tiap kondisi perbandingan digunakan
- Saat VRR nonaktif:
dxgi.maxFrameRate = 500
- Saat VRR aktif dan dxvk-low-latency nonaktif:
dxgi.maxFrameRate = 497
- Saat VRR dan dxvk-low-latency aktif bersama, pengaturan berikut digunakan untuk frame pacing VRR latensi rendah pada 500Hz
dxgi.maxFrameRate = 480
dxvk.lowLatencyOffset = 70
dxvk.framePace = "low-latency-vrr-500"
dxvk.lowLatencyAllowCpuFramesOverlap = False
d3d11.cachedDynamicResources = "c" diterapkan ke semua konfigurasi
Lingkungan game dan prosedur pengukuran berulang
- Game pengujian adalah game DirectX 11 Diabotical, dijalankan dengan Heroic dan Proton
- Resolusi native dan render scale 100% digunakan, Vsync dimatikan, lalu pengaturan grafis lainnya diturunkan serendah mungkin
- Perintah tersembunyi yang menyembunyikan UI sebentar diikat ke klik kiri dengan
/bind mouse_left testlatency, dan HUD yang menampilkan kotak putih besar dikonfigurasi untuk memperbesar selisih kecerahan saat klik
- Setiap pengujian diulang dalam kondisi yang sama
- Menutup software yang tidak diperlukan dan memulai server lokal dengan mode dan map yang sama
- Mengarahkan mouse ke penanda terrain tertentu dari posisi yang ditentukan
- Melakukan 100 klik selama sekitar 2 menit, diulang total 3 kali
- Menjaga adegan tetap statis tanpa bot, pemain lain, pergerakan, atau restart ronde
- Memastikan tidak ada proses lain yang signifikan berjalan, dan posisi perangkat pengukur juga dijaga tetap sama di semua pengujian
Rentang latensi seluruh konfigurasi
- Semua kasus dengan batas frame rate mempertahankan FPS target secara stabil, dan game berada dalam kondisi bottleneck CPU sepanjang pengujian
- Semua kasus menunjukkan distribusi berbentuk lonceng tanpa outlier besar, dengan rentang dari p5 hingga p95 sekitar 2~3ms
- Median dari 8 konfigurasi utama adalah 4,21~4,93ms, sehingga selisih totalnya hanya 0,72ms
- XWayland memiliki median hingga 3,13ms lebih tinggi daripada konfigurasi Wayland native yang sepadan, masing-masing mencatat 8,06ms dan 4,93ms
- Pada kasus tanpa batas FPS, dxvk-low-latency mengurangi latensi 0,84ms dibanding DXVK bawaan
Selisih kecil antara X11 dan Wayland native
- X11 lebih cepat di semua konfigurasi, tetapi selisihnya kecil, 0,14~0,22ms, sehingga tidak cukup untuk menjelaskan penilaian bahwa Wayland terasa jauh lebih lambat
- low-latency dan VRR aktif: X11 4,21ms, Wayland 4,38ms, selisih +0,17ms
- hanya low-latency aktif: X11 4,64ms, Wayland 4,83ms, selisih +0,19ms
- hanya VRR aktif: X11 4,45ms, Wayland 4,67ms, selisih +0,22ms
- keduanya nonaktif: X11 4,79ms, Wayland 4,93ms, selisih +0,14ms
- Bentuk distribusi latensi kedua display server juga sangat mirip
Dampak VRR terhadap latensi dan distribusi
- VRR menunjukkan dampak terbesar di antara item yang dibandingkan, dan lebih cepat 0,26~0,45ms pada semua kombinasi
- X11 dengan low-latency: turun 0,43ms dari 4,64ms menjadi 4,21ms
- X11 dengan DXVK bawaan: turun 0,34ms dari 4,79ms menjadi 4,45ms
- Wayland dengan low-latency: turun 0,45ms dari 4,83ms menjadi 4,38ms
- Wayland dengan DXVK bawaan: turun 0,26ms dari 4,93ms menjadi 4,67ms
- Rentang antara p95 dan p5 adalah 2,1~2,2ms saat VRR digunakan, dan 2,6~3,0ms saat tidak digunakan, sehingga distribusi latensi juga menyempit
- Pada VRR, frame di-scan out segera setelah siap tanpa menunggu slot scanout berikutnya, sehingga hasil pengukuran sesuai dengan cara kerjanya
Efek dan biaya dxvk-low-latency
- Pada kasus dengan batas FPS, dxvk-low-latency mengurangi latensi di semua kombinasi, dengan rata-rata perbaikan 0,20ms, mirip dengan selisih rata-rata 0,18ms antara X11 dan Wayland
- X11 dengan VRR: turun 0,24ms dari 4,45ms menjadi 4,21ms
- X11 dengan VRR nonaktif: turun 0,15ms dari 4,79ms menjadi 4,64ms
- Wayland dengan VRR: turun 0,29ms dari 4,67ms menjadi 4,38ms
- Wayland dengan VRR nonaktif: turun 0,10ms dari 4,93ms menjadi 4,83ms
- Dalam kondisi tanpa batas FPS, pacer menunjukkan efek lebih besar dalam mencegah penumpukan render queue dan meredam frame pacing yang tidak merata
- GPU tidak dibuat jenuh sepenuhnya dan dijaga dalam kondisi mendekati bottleneck GPU
- Utilisasi GPU adalah 100% pada DXVK bawaan dan 95~97% pada dxvk-low-latency
- Latensi turun 0,84ms dari 5,27ms menjadi 4,43ms
- FPS berkurang 45FPS dari 715 menjadi 670
Latensi besar yang ditambahkan XWayland
- Jika
Enable Wine-Wayland (Experimental) di Heroic Launcher atau PROTON_ENABLE_WAYLAND=1 dimatikan, game berjalan melalui XWayland
- XWayland menambahkan latensi besar dibanding Wayland native
- low-latency aktif: naik 1,12ms dari 4,83ms menjadi 5,95ms
- DXVK bawaan: naik 3,13ms dari 4,93ms menjadi 8,06ms
- Tambahan 3,13ms pada DXVK bawaan lebih besar daripada gabungan semua efek lain yang diukur, dan bukan karena beberapa frame buruk menaikkan rata-rata, melainkan karena seluruh distribusi bergeser
- Menambahkan dxvk-low-latency pada XWayland mengurangi latensi 2,11ms, menjadi perbaikan terbesar di antara semua kasus
Cakupan penerapan hasil dan interpretasi praktis
- Hasil pengukuran terbatas pada kondisi optimal berupa FPS terbatas yang stabil, bottleneck CPU, dan adegan statis, serta software stack dan hardware tertentu
- Di lingkungan lain, nilai latensi absolut dapat berbeda, tetapi peningkatan atau penurunan yang terjadi pada tiap konfigurasi dianggap umumnya dapat terbawa
- Pada display dengan refresh rate lebih rendah, kemungkinan dampak perbaikan dari VRR dan pacer latensi rendah akan lebih besar
- X11 lebih cepat 0,14~0,22ms daripada Wayland, tetapi selisih ini dapat menyempit berkat pekerjaan optimasi KWin, dan ada kemungkinan compositor Wayland lain sudah lebih baik
- Jika mengecualikan XWayland, penerapan X11, VRR, dan dxvk-low-latency sekaligus menghasilkan median 0,72ms lebih rendah daripada konfigurasi Wayland bawaan
- Selisih median kecil, tetapi VRR mengurangi jitter latensi, dan dxvk-low-latency meredam penurunan frame time serta situasi bottleneck GPU yang terjadi dalam game nyata
Proyek pengukuran latensi input serupa
1 komentar
Pendapat Hacker News
Hal bagus dari Linux adalah analisis seperti ini bukan hanya bisa dilakukan, tetapi juga benar-benar mengarah pada perbaikan ekosistem. Hasilnya disampaikan kepada pengembang perangkat lunak grafis dan pengelola paket distribusi, tetapi di Microsoft jalur perbaikan seperti ini tampaknya sulit diharapkan
Setelah lama memakai Windows, saya baru-baru ini pindah ke Linux, dan saya suka bahwa KDE Plasma terasa lebih responsif daripada Windows 11, serta ketika ada masalah saya bisa memperbaikinya sendiri. Jika sudah lama tidak mencoba desktop Linux, saya merekomendasikan Bazzite, Fedora yang disesuaikan untuk gaming; bahkan jika tidak bermain game, ini memungkinkan Anda menyiapkan desktop yang matang dengan cepat
Dulu kita bisa mengubah apa pun sesuai keinginan dengan satu berkas konfigurasi yang intuitif, tetapi sekarang, meski ada banyak lapisan abstraksi untuk tema, ikon, mode terang, dan mode gelap, sulit menemukan kombinasi yang benar-benar bekerja. Di mode terang muncul teks abu-abu di atas abu-abu terang, di mode gelap muncul teks hitam di atas latar hitam, dan tergantung tema seperti Adwaita, bahkan penampil PDF kadang tidak bisa menentukan warna teks dan latar dengan benar
Tidak ada tema yang membuat scrollbar cukup terlihat, dan tidak ada yang membedakan jendela aktif dan tidak aktif dengan warna yang jelas. Bahkan Windows 3.11 menangani scrollbar, penanda jendela aktif, dan kustomisasi warna dengan lebih baik; jadi sebelum semuanya dirancang secara berlebihan, hasilnya justru lebih baik
Intel(https://www.techpowerup.com/312122/psa-intel-graphics-driver...) dan Nvidia(https://nateshoffner.com/blog/2017/05/disable-nvidia-telemet...) juga mengumpulkan data semacam ini dari pengguna yang menyetujuinya. Namun keduanya berbasis opt-in, jadi mungkin tidak banyak data dari gamer yang sangat antusias
Ada banyak perubahan bertahap, tetapi sering kali selama bertahun-tahun terjebak di optimum lokal. Meski begitu, bagus bahwa cara kerja internalnya relatif mudah dilihat, dan saya tidak begitu paham mengapa Windows dan macOS harus selalu bersifat closed source
Beberapa bulan lalu saya mengganti sistem operasi utama sekaligus lingkungan gaming saya ke Fedora, dan secara umum terasa lebih responsif daripada Windows; pengukuran ini menjawab sebagian rasa penasaran saya tentang latensi input dalam game
Baru-baru ini saya pindah ke Hyprland berbasis Wayland, jadi saya penasaran bagaimana hasilnya akan berbeda, dan karena popularitasnya sudah meningkat, saya berharap ini diuji lagi. Saya juga sempat mempertimbangkan Gamescope, tetapi ada kabar bahwa itu tidak bekerja baik di Nvidia, dan baru kali ini saya tahu ada yang disebut kernel yang dioptimalkan untuk game. Dalam game fighting kompetitif, latensi input sangat penting, jadi saya ingin mendengar cerita dari orang yang pernah melakukan optimasi serupa
Untuk game, saya menyukai Hyprland, dan pengaturan detail seperti variable refresh rate serta tearing melalui Gamescope lebih mudah dibanding saat memakai AwesomeWM di X11. Konfigurasi Lua juga terasa familier bagi saya yang dulu memakai AwesomeWM
Karena pengujian dilakukan dengan layar 500Hz, banyak masalah yang muncul pada layar dengan refresh rate rendah mungkin tertutupi. Fakta bahwa XWayland 3ms lebih lambat bisa berarti pada refresh rate ini ia tertinggal satu frame
Jika diuji pada 120Hz atau 60Hz, perbedaan kecil pada timing eksekusi dan efek besar berupa keterlambatan satu frame penuh mungkin bisa dibedakan dengan lebih jelas
Di bagian akhir tulisan, penulis heran mengapa Wayland dianggap lambat, tetapi hasil XWayland bisa jadi justru alasannya. Ada kemungkinan pengguna yang menjalankan game X11 di Wayland merasakan latensi yang bermakna. Akan bagus jika ada lebih banyak pengukuran nyata seperti ini di berbagai bidang
Penulis sudah menyingkirkan variabel campuran lain dengan baik, tetapi pengguna yang merasa Wayland lambat mungkin awalnya memakai lingkungan yang tidak dioptimalkan, lalu saat beralih ke konfigurasi latensi rendah, pengaturan terkait ikut dibenahi
Berbeda dengan X11, di mana Xorg yang praktis menjadi implementasi referensi standar di mana-mana berperilaku mirip, perbedaan antarimplementasi Wayland itu besar. Bisa saja ada kompositor yang lebih lambat daripada KDE Plasma yang dipakai dalam pengujian, dan bisa juga ada yang lebih cepat
Istilah latensi input Wayland itu sendiri mencampuradukkan lapisan yang berbeda, seperti
kelancaran animasi HTTP. Yang diukur tulisan ini adalah Xorg, KWin, dan XWayland, sedangkan implementasi X11 dan Wayland lain bisa memiliki karakteristik berbedaNamun latensi tambahan XWayland tampak cukup besar sehingga mencurigakan jika dianggap sekadar biaya tambahan biasa
Khususnya Emacs dalam mode pgtk berjalan jauh lebih baik di GNOME, tetapi di KWin ia memakai banyak CPU saat menggulir dan kadang sedikit tertunda pada resolusi tinggi
Akan sangat menarik juga melihat hasilnya jika dibandingkan dengan Windows pada perangkat keras yang sama
Di Breaka Club, mereka menangani masalah ini langsung saat mengajar coding kepada anak-anak dengan Overcooked 2! yang dimodifikasi
Karena sulit memasang mod di perangkat sekolah, mereka men-streaming OC2 yang sudah menyertakan mod melalui WebRTC, dan anak-anak bermain dari Mobile Safari di iPad dengan gamepad di layar. Instance game berjalan dalam container Docker di Kubernetes/k3s di atas perangkat keras Nvidia lama, melewati internet dan jaringan sekolah, sehingga mereka mengurangi latensi total dengan transfer tanpa salin seperti NVEnc dan DMABuf
Saat ini mereka mengalami biaya tambahan input XWayland, tetapi karena inputnya berupa perangkat virtual, polanya bisa berbeda. Optimasi end-to-end sulit, dan performa saat ini sudah pada tingkat yang dapat diterima. Video coding OC2: https://www.youtube.com/watch?v=ITWSL5lTLig
Lisensi OC2 dibeli dalam jumlah terbatas dan dialokasikan satu saat pod dimulai; jika semuanya sedang dipakai, anak-anak memainkan game lain
Saat memakai rendering komposit di X11, jika jendela layar penuh mengirim hint pembatalan redirect ke kompositor, komposit dapat dihentikan selama tidak ada elemen lain yang digambar di layar, dan swapchain aplikasi dapat diteruskan langsung ke layar. Ini pada dasarnya cara yang optimal, sehingga sulit diperbaiki lebih jauh
Jika jendela lain muncul di atasnya atau kompositor menilai tidak bisa meneruskan langsung, muncul tahap perantara yang mengomposit jendela aplikasi dan elemen lain ke buffer sementara. Jika pembatalan redirect rusak, misalnya jendela dibuat 1 piksel lebih kecil daripada tinggi layar, atau jika memakai XWayland, latensi bisa meningkat; ini adalah keterbatasan mendasar, sehingga masalah serupa juga terjadi pada kompositor sistem operasi lain
Wayland juga telah mengeksplorasi display planes tempat perangkat keras GPU mengomposit beberapa lapisan secara langsung. Dengan ini, game dapat merender pada frame rate maksimum, sementara jendela di atasnya digambar pada plane terpisah dan dikomposit tanpa efek samping, tetapi saya tidak tahu apakah ini digunakan di lingkungan produk nyata
Konsol cenderung menargetkan jumlah frame per detik keluaran yang tetap dan resolusi dinamis, sedangkan PC cenderung mengunci resolusi dan membiarkan jumlah frame per detik serta interval waktu frame bersifat dinamis. Saya penasaran apa hubungannya dengan latensi
Khususnya dalam game kompetitif, orang menargetkan jumlah frame per detik yang jauh melampaui refresh rate display, tetapi saya tidak yakin apakah itu benar-benar bermanfaat atau hanya ilusi
Intinya bukan melihat lebih banyak frame, melainkan melihat informasi yang lebih baru. Rendering juga bisa mulai ditunda agar selesai tepat sebelum refresh layar, tetapi jika timing-nya meleset sedikit saja akan terjadi stutter parah, dan waktu eksekusi GPU serta waktu CPU mengirim pekerjaan tidak deterministik
Idealnya, tanpa membuat frame yang tidak perlu, rendering dimulai tepat sebelum refresh layar, tetapi jika deadline terlewat, akan muncul stutter yang sangat mengganggu
Frame baru bisa masuk di tengah proses scan layar sehingga menimbulkan tearing, tetapi di bawah garis batasnya akan ditampilkan piksel yang lebih baru. Jadi dalam satu frame monitor, beberapa frame render bisa tercampur, dan meski tidak sebagus display variable refresh rate dengan refresh rate tinggi, ini tetap mengurangi latensi. Pada game yang gerakan bukan faktor penting, VSync sering dipakai untuk menyelaraskan frame dengan refresh rate dan menghilangkan tearing
Beberapa game menyesuaikan resolusi secara real-time untuk menjaga jumlah frame per detik yang stabil. Di PC, sejak awal game bisa dijalankan pada spesifikasi yang jauh lebih rendah dari target aslinya, jumlah frame per detik yang rendah lebih diterima secara budaya, dan jika tidak suka orang bisa melakukan upgrade. Konsol tidak punya jalur upgrade dan harus dioptimalkan untuk satu konfigurasi, sehingga sebelum performa turun terlalu jauh, menurunkan resolusi adalah pendekatan yang lebih cocok
Ini bukan berarti game menerima lebih banyak event input, tetapi input bisa diproses dan direfleksikan lebih cepat. Ini bukan ilusi, tetapi diminishing returns-nya besar, dan efeknya bergantung pada frame queue, VSync, variable refresh rate, bottleneck CPU atau GPU, serta struktur loop input dan simulasi
Penulis tampaknya sejak awal ingin menyingkirkan kemungkinan ilusi, tetapi bukankah latensi pada akhirnya dinilai dari rasa dan pengalaman penggunaan? Menurut saya pribadi, bagaimana rasanya bagi pengguna adalah ujian akhir; meski data berguna untuk mendiagnosis dan memperbaiki latensi aktual, dalam kebanyakan UI/UX tidak masalah mengandalkan preferensi dan persepsi subjektif
Menyertakan penilaian yang kurang teknis seperti rating bintang juga bisa mencegah pengujian dan pengumpulan data terlalu terjebak dalam metodologi. Dalam pengujian yang dirancang sangat presisi, ada kemungkinan kondisi penurunan performa yang sering muncul dalam penggunaan sehari-hari pada lingkungan tertentu justru terlewat