- Trong môi trường Fedora Workstation 41·GNOME 47, tác giả quay độ trễ đầu vào của con trỏ bằng chế độ quay chậm 240 FPS để so sánh Wayland và X11
- Bằng cách đếm từ khung hình mà chuột bắt đầu di chuyển đến khung hình con trỏ xuất hiện ở vị trí mới, tác giả ghi lại độ trễ theo khung hình của 16 lần trên Wayland và 16 lần trên X11
- GNOME X11 được đo trung bình 4 khung hình·16,7ms·2,4 lần làm mới màn hình; GNOME Wayland trung bình 5,5625 khung hình·23,2ms·3,3 lần làm mới màn hình
- Trên hệ thống này, Wayland cho thấy độ trễ con trỏ trung bình cao hơn X11 khoảng 6,5ms, và chênh lệch gần tương đương 1 lần làm mới màn hình
- Kết quả chỉ cho thấy chênh lệch độ trễ con trỏ trong tổ hợp GNOME/AMD, không phải bằng chứng rằng độ trễ đầu vào của Wayland cao hơn trong game hay các ứng dụng đồ họa thông thường
Vì sao đo
- Một người dùng Linux, nhân bài viết Wayland Cursor Lag: Just give me a break already... về phàn nàn độ trễ đầu vào trên Wayland, đã tiến hành thử nghiệm để có con số cụ thể thay vì cảm nhận chủ quan
- Dù nhìn chung vẫn hài lòng khi dùng Wayland, ấn tượng rằng Wayland có độ trễ con trỏ cao hơn X11 là điểm khởi đầu của thử nghiệm
- Tác giả cho rằng camera điện thoại 90 FPS trong bài viết trước không đủ để đánh giá chênh lệch ở mức một lần làm mới màn hình, nên dùng chế độ quay 240 FPS
Cách đo
- Dùng camera điện thoại quay đồng thời màn hình, mặt bàn, con trỏ chuột, chuột và bàn tay, trong khi dùng ngón tay búng chuột lặp lại nhiều lần
- Sau khi quay 16 lần trong phiên GNOME Wayland, tác giả đăng nhập vào phiên GNOME X11 và quay 16 lần theo cùng cách
- Video đã quay được chuyển thành khung hình JPEG bằng lệnh
ffmpeg -i <input file> %04d.jpg - Độ trễ theo khung hình được đếm theo các tiêu chí sau
- Bắt đầu tính từ khung hình đầu tiên thấy chuột di chuyển
- Tính đến khung hình đầu tiên thấy rõ con trỏ đã di chuyển đến vị trí mới
- Bao gồm cả khung hình bắt đầu và khung hình kết thúc
- Ví dụ, nếu chuột di chuyển ở khung hình 1045 và con trỏ di chuyển ở khung hình 1047 thì ghi nhận là độ trễ 3 khung hình
Môi trường kiểm thử
- Phần cứng và phần mềm thử nghiệm như sau
- Bản phân phối: Fedora Workstation 41
- Phiên bản GNOME: 47
- CPU: AMD Ryzen 9 5950X
- GPU: AMD Radeon RX 7900XT
- Màn hình: Gigabyte M32U, 4K IPS, 144,99Hz, không dùng DPI scaling
- Chuột: Logitech G502 Lightspeed
- Camera: iPhone 15 Pro, quay chậm 240 FPS
Hạn chế trong phép đo
- Ngay cả 240 FPS cũng tạo ra dao động ngẫu nhiên trên màn hình 144Hz, vì mỗi lần làm mới màn hình có chưa đến 2 khung hình camera
- Do pixel không chuyển đổi tức thời, có những khung hình mơ hồ khi con trỏ bắt đầu hiện rất mờ ở vị trí mới
- Ngay cả khi con trỏ chưa sáng hoàn toàn, nếu thấy rõ ở vị trí mới thì được tính là con trỏ đã di chuyển
- Video iPhone có chứa một số khung hình trùng lặp, không rõ nguyên nhân
- Khung hình trùng lặp được xem là đã trôi qua thời gian tương ứng một khung hình và được tính như khung hình bình thường
- Những yếu tố này tạo ra bất định trong kết quả, nhưng tác giả cho rằng chúng tác động như nhau lên Wayland và X11, và sẽ được trung bình hóa nếu có đủ dữ liệu
- Các compositor Wayland ngoài GNOME và driver GPU ngoài AMD chưa được kiểm thử, nên kết quả có thể khác ở các tổ hợp khác
Kết quả đo
- 16 giá trị đo của GNOME X11 là
5, 4, 3, 4, 5, 4, 6, 5, 1, 4, 4, 4, 3, 4, 4, 4khung hình- Trung bình: 4 khung hình
- Thời gian trễ: 16,7ms
- Lần làm mới màn hình: 2,4 lần
- 16 giá trị đo của GNOME Wayland là
6, 5, 6, 5, 5, 6, 6, 4, 8, 6, 5, 5, 5, 6, 5, 6khung hình- Trung bình: 5,5625 khung hình
- Thời gian trễ: 23,2ms
- Lần làm mới màn hình: 3,3 lần
- Trên hệ thống này, Wayland cho thấy độ trễ con trỏ trung bình cao hơn X11 khoảng 6,5ms
- Tác giả không có chuyên môn để phân tích đúng mức liệu điều này có ý nghĩa thống kê hay không, nhưng nhìn vào các giá trị đo thì dường như có chênh lệch rõ ràng và nhất quán
- Chênh lệch gần tương đương 1 lần làm mới màn hình, nhưng không rõ đây có phải ngẫu nhiên hay không
Kết luận và phạm vi diễn giải
- Thử nghiệm này cho thấy trên phần cứng cụ thể có chênh lệch độ trễ đầu vào giữa X11 và Wayland, và chênh lệch đó có thể đủ lớn để một số người dùng nhận ra
- Cần kiểm thử thêm trên nhiều phần cứng và tần số quét màn hình khác nhau để hiểu rõ phạm vi và mức độ của vấn đề
- Độ lớn của chênh lệch có thể thay đổi tùy theo các yếu tố như compositor đang dùng và tần số quét màn hình
- Các thử nghiệm bổ sung tốn nhiều thời gian nên có khả năng tác giả sẽ không tự thực hiện
- Bài kiểm thử này không cho thấy Wayland nhìn chung có độ trễ đầu vào cao hơn X11
- Đặc biệt, đây không phải bằng chứng rằng độ trễ đầu vào của Wayland cao hơn trong game
- Có khả năng độ trễ bổ sung chỉ riêng cho con trỏ
- Tác giả hiểu rằng con trỏ được xử lý rất khác so với các ứng dụng đồ họa thông thường
- Việc Wayland có độ trễ đầu vào cao hơn X11 trong game hay không cần được kiểm thử riêng
1 bình luận
Ý kiến trên Hacker News
Cách tiếp cận rất hay. Có vẻ mọi người quá thường xuyên suy đoán về những thứ hoàn toàn có thể kiểm chứng bằng thực nghiệm. Từ khi học phương pháp khoa học, tôi luôn bị thu hút bởi hướng “hãy thiết kế một thí nghiệm”
Tôi không biết vì sao Wayland lại có thêm độ trễ, nhưng với tư cách là người đã ở trong cộng đồng máy tính từ thời X11 mới xuất hiện, tôi có thể nói rằng ngay từ những ngày đầu đã có rất nhiều phàn nàn về độ trễ hiển thị. Dù là phản hồi con trỏ hay cuộn xterm cũng vậy
Khi “workstation” xuất hiện, đôi khi chúng có phần cứng hiển thị riêng chỉ dành cho chuột, nhằm giảm độ trễ do render chuột vào trong frame. Cũng có bằng sáng chế XOR khét tiếng: https://patents.google.com/patent/US4197590
Nhờ những phàn nàn như vậy, đường đi của code từ nhập bàn phím/chuột đến phản ánh lên màn hình đã liên tục được xem xét để làm “nhanh hơn, độ trễ thấp hơn”. Wayland tương đối “mới” so với X11 nên chưa được kiểm chứng lâu đến mức đó, nhưng tôi hy vọng mọi người sẽ dần sửa được
Plane có thể được cập nhật hoặc đổi vị trí mà không cần vẽ lại phần còn lại của màn hình. Ảnh màn hình thông thường nằm trên primary plane, còn di chuyển con trỏ gần như là commit vị trí mới của plane
Độ trễ nhập liệu mà GNOME Mutter, máy chủ Wayland được dùng ở đây, thêm vào có lẽ chủ yếu là vấn đề chiến lược về thời điểm lấy mẫu input và commit. Mỗi server có chiến lược và ưu tiên khác nhau, tạo ra ưu nhược điểm riêng
Wayland là một giao thức nên không can dự vào quy trình định vị con trỏ thông thường. Vì vậy vấn đề này hoàn toàn thuộc phạm vi triển khai và tối ưu hóa bên trong display server. Ở cấp giao thức, về cơ bản chỉ có việc cho client đặt ảnh con trỏ và thông báo vị trí con trỏ cho client
Theo tôi nhớ, tình hình bắt đầu tệ đi khi glamour xuất hiện trong Xorg. Khi đường render con trỏ không còn an toàn để chạy trong signal handler nữa — điều hiển nhiên nếu dựa trên OpenGL — độ trễ đã trở nên tệ hơn
Trước đây, ngay cả khi máy Linux đang thrashing, con trỏ chuột vẫn phản hồi, và đó là một chỉ báo đáng tin để đoán kernel có bị treo hay không. Nếu con trỏ không phản hồi đủ sớm, đó thường là trường hợp cần bật unmask irq bằng hdparm trên host IDE/PATA. Con trỏ không phản hồi trong XFree86 từng là một tín hiệu rất hữu ích cho thấy có gì đó sai hoặc cấu hình bị lệch; tôi nhớ thời đó
Tôi biết than phiền về phần mềm miễn phí là thế nào, nhưng chuyện này đã bị ép chuyển đổi sang thứ tệ hơn trong thời gian quá dài. Việc áp dụng Wayland lẽ ra phải dựa trên tiền đề rằng nó gần như vượt trội phổ quát đối với mọi yêu cầu input và hiển thị
Intel, AMD, Nvidia, các nhà sản xuất Arm nên dốc toàn lực như một consortium để tạo ra desktop Linux dùng được. Chính phủ cũng vậy. Vì một desktop Linux an toàn thực sự là khả thi, và đó là con đường nhanh nhất để trình diễn CPU, khả năng 3D và phần cứng vector/máy tính cao cấp
Wayland xuất hiện đúng thời điểm Windows tự phá mình bằng UI dạng ô gạch khủng khiếp, còn Apple thì ngoan cố từ chối phần vốn hóa thị trường bổ sung mà họ có thể có nếu phát hành macOS cho x86 phổ thông, rốt cuộc lại làm độ trễ của desktop Linux tăng thêm
Phần cần khéo là khi kéo cửa sổ hoặc biểu tượng, lúc đó độ trễ swapchain bắt đầu lộ ra. Một số window compositor cho rằng nhờ tần số quét cao nên độ trễ ít thấy hơn và không còn bận tâm nữa; macOS là ví dụ, còn Windows dường như chuyển sang con trỏ chuột phần mềm trong lúc kéo
Ứng dụng toàn màn hình nên đi qua đường nhanh, hoặc đi qua compositor hoặc bypass nó
Nếu ai dùng ffmpeg cho kiểu phân tích theo từng frame này, có thể lấy thời điểm hiển thị của từng frame trong video bằng
ffmpeg -skip_frame nokey -i file -vsync 0 -frame_pts true out%d.png. Cách này chính xác hơn việc chỉ dump frame rồi tính timestampTrên trình duyệt web cũng có thể làm tương tự bằng cách phát video và dùng
requestVideoFrameCallback(). Tuy nhiên nếu máy tính không decode kịp mọi frame đủ nhanh thì có thể cần giảm.playbackRateViệc trên màn hình 144Hz, Wayland chậm hơn X11 trung bình khoảng 6,5ms, và chênh lệch đó gần bằng một lần refresh màn hình, có thể không phải ngẫu nhiên. Nếu độ trễ gần 1/144 giây thì trên màn hình 60Hz thông thường nó cũng có thể thành 1/60 giây. Nếu không luyện tập thì khó nhận ra một cách có ý thức, nhưng đa số vẫn có thể “cảm thấy” dù không giải thích được
Tất nhiên với nhiều người dùng, polling rate 125Hz của chuột cũng là một yếu tố gây nhiễu, nhưng trường hợp này dùng chuột 1KHz
Chênh lệch 7ms thì không tệ, nhưng chênh lệch 16,6ms bắt đầu khá lớn. Cá nhân tôi nghĩ máy tính nên cố gắng hướng tới mục tiêu độ trễ 1,6 frame: nửa frame do pha ngẫu nhiên, một frame, và một chút thời gian xử lý
Kết quả sẽ khác nhau tùy theo compositor, GPU và cấu hình. Trên X11, gần như chỉ có một triển khai X server được các hệ thống desktop Linux sử dụng, nên sự khác biệt này ít hơn
Vẫn có thể còn vấn đề là nhiều tổ hợp compositor/GPU không có được mặt phẳng con trỏ phần cứng, và nếu vậy thì những chênh lệch độ trễ như thế này hoàn toàn có thể xảy ra
Hôm nay mới biết Wayland đã 16 năm tuổi rồi. Vài năm nữa Wayland sẽ bằng tuổi X vào thời điểm Wayland xuất hiện, vậy mà dường như nó vẫn bị xem là tầm thường hoặc không bằng X
$very_specific_feature” hoặc “thật buồn vì driver độc quyền của hãng card đồ họa của tôi chưa được kiểm thử đủ trên Wayland”Khoảng 99,999% những lời phàn nàn như vậy đến từ những người 1) không tự làm, 2) không có hứng thú hoặc khả năng làm, và 3) không hiểu hoặc không thừa nhận rằng các nhà phát triển Wayland và X phần lớn là cùng một nhóm người, và họ không còn muốn làm việc với X11 nữa
Tôi không có lợi ích đặc biệt nào trong cuộc tranh luận này, nhưng đã mệt mỏi khi thấy người ta dùng phần mềm do người khác cho miễn phí rồi phàn nàn về Wayland. Nếu có nhiều lời phàn nàn về Wayland đến thế, hẳn đến giờ họ đã có thể tập hợp lại để bảo trì và cải thiện X, và nếu các phàn nàn cùng lý thuyết của họ đúng thì có thể bỏ Wayland lại phía sau
Lạ là X là mã nguồn mở và có thể fork tùy ý, từng có tiền lệ X.org ra đời từ XFree86, vậy mà những người ủng hộ chỉ để nó phủ bụi và chẳng làm gì cho việc bảo trì
Nếu có kết quả kiểu “Wayland không tốt bằng X nên chúng tôi đã tạo một fork X hiện đại hóa mà ai cũng có thể dùng”, tôi sẽ khá quan tâm xem thử
Tức là Wayland hiện chỉ bằng khoảng 66% tuổi của X vào thời điểm Wayland ra đời, và để bằng tuổi thì cần thêm 50% vòng đời hiện tại của Wayland nữa
Hiện tôi đang dùng Wayland trên Plasma 6 và nó hoạt động đủ tốt, nhưng tôi không có yêu cầu đặc biệt nào, nên chẳng hạn tôi không biết trình đọc màn hình hoạt động tốt đến đâu
Tôi dự đoán đến thời điểm đó stack frontend trình duyệt sẽ nuốt chửng hoàn toàn desktop. Dù sao thì Linux vốn cũng không có nhiều ứng dụng desktop mới
Không ngạc nhiên khi đa số nỗ lực viết lại một giải pháp đang hoạt động với lý do “hiện đại hơn, dễ bảo trì hơn và sẵn sàng cho tương lai” lại không thành ra như vậy. Thường thì nó chậm hơn, tăng độ trễ, và chỉ được phần cứng nhanh hơn chống lưng chứ không phải phần mềm nhanh hơn
Cứ mỗi 20 năm lại có cảm giác một thế hệ mới yếu hơn, được nuông chiều dựa vào các lớp trừu tượng mà thế hệ trước đã vất vả tạo ra. Sau khoảng 3 thế hệ lập trình viên, những gì còn lại chỉ là người gọi thư viện/framework, và hầu như không còn ai thật sự hiểu về hiệu năng và tối ưu hóa
Wayland vẫn còn thiếu một số tính năng so với X11, nhưng vì các ưu điểm khác nên tôi sẵn sàng thỏa hiệp ở mức đó
Nhiều compositor Wayland gặp vấn đề lớn với bàn phím, chuột và các thiết bị nhập khác. Đó là vì đặc tả Wayland và triển khai tham chiếu đã quyết định không hỗ trợ những thứ đó. Vì vậy mỗi compositor Wayland chọn một giải pháp khác nhau
Các lựa chọn phổ biến là libei và libinput, nhưng cũng nhiều trường hợp hoàn toàn không hỗ trợ đầu vào chuột/bàn phím “nâng cao”. weston là một ví dụ như vậy. Hoàn toàn không thể biết một phần mềm Linux cụ thể có chạy trong một môi trường Wayland cụ thể hay không, và mức độ phân mảnh là nghiêm trọng
Trên X, thực tế có một tham chiếu X11 mạnh mẽ triển khai mọi thứ, nên nếu chạy được ở một nơi thì có thể tin chắc nó cũng chạy ở nơi khác
Thậm chí sau 12 năm vẫn chưa có compositor Wayland nào hỗ trợ trình đọc màn hình cho người khiếm thị. Nó chỉ ở mức đồ chơi
Vì vậy nó không tốt cho game, không tốt cho công việc đồ họa chuyên nghiệp, và không tốt cho người có thị lực kém. Rốt cuộc nghĩa là nhìn chung nó không tốt cho bất kỳ người dùng nào hơi khác với những người tạo ra nó
Dù vậy, nếu may mắn thì có lẽ nó đã giảm được hiện tượng xé hình mà tôi chưa từng cảm nhận bao giờ
Một kết quả tuyệt vời từ đây là việc mọi người thêm các workflow trợ năng lên trên hệ sinh thái này. Có người điều khiển toàn bộ desktop thông qua trình quản lý cửa sổ xếp ô bằng điều khiển giọng nói: https://youtu.be/fiPJLmhnnXM
Khi GPU chịu tải lớn, ví dụ như chạy tác vụ suy luận Stable Diffusion, sẽ xuất hiện các đỉnh trễ rất lớn. Tôi chưa thử kiểm tra A/B với X11, nhưng trước đây tôi không nhớ là có chuyện như vậy
Việc bị trễ thêm một khung hình cũng không hay, nhưng những đỉnh trễ thỉnh thoảng vọt lên mới thật sự gây khó chịu
Độ trễ nhập của con trỏ là thứ gây phiền nhiễu, liên tục bào mòn mức độ hài lòng với ứng dụng hoặc hệ điều hành
Trễ con trỏ văn bản trong IDE? Không thể chấp nhận
Trễ con trỏ văn bản trong shell? Không thể chấp nhận
Trễ con trỏ chuột trong GUI? Không thể chấp nhận
Tất cả đều là điều kiện loại ngay lập tức
Ngay cả System 1 chạy trên phần cứng yếu gần như vô hạn cách đây hơn 40 năm cũng đặt độ phản hồi của con trỏ lên hàng đầu và vượt qua mọi đối thủ. Nền tảng OS và UI hiện nay đã khác 100%, nhưng mức ưu tiên đó vẫn được duy trì
Gần đây tôi đã gặp tình trạng chuột chậm cực kỳ nghiêm trọng với tổ hợp X11 và NVidia trên KDE/Plasma 6. Tôi nhận ra hiện tượng chậm đặc biệt nặng khi đưa chuột lên các tab trình duyệt
Ghi lại cho những ai gặp cùng vấn đề: cách khắc phục là tắt OpenGL flipping. Tôi hoàn toàn không biết OpenGL flipping làm gì, nhưng khi tắt trong nvidia-settings và
/etc/X11/xorg.confthì vấn đề được giải quyếtMong ai đó có thể giải thích vì sao lại như vậy, hoặc vì sao đây không phải là thiết lập mặc định
Công việc rất hay. Có lẽ đáng để đặt màn hình ở tần số quét rất thấp, chẳng hạn 30Hz, rồi lặp lại thí nghiệm
Nếu Wayland luôn chậm hơn X11 một khung hình thì sẽ dễ quan sát hơn nhiều
Tôi có một than phiền cá nhân hơi khác. Khi tôi mới bắt đầu dùng Linux, desktop dùng compositing bằng phần mềm. Có lẽ CPU vẽ UI vào RAM rồi blit sang framebuffer của GPU, và tôi nghĩ đó là cách đã được dùng từ lâu
Khi compositor, kể cả X11 composite, rồi các GPU renderer trở nên phổ biến, độ trễ trở nên kinh khủng, đúng nghĩa ở mức hàng trăm ms. Điều đó thật lạ vì khi lớn lên với các game DOS, tôi không gặp vấn đề này
Theo thời gian thì đã có cải thiện, nhưng tôi không chắc chúng ta đã quay lại được thời hoàng kim của rendering bằng CPU hay chưa