Wine 11 tái viết cách Linux chạy game Windows ở cấp độ kernel, đạt mức tăng hiệu năng lớn

• Thiết kế lại toàn diện ở cấp độ kernel cấu trúc chạy game Windows trên Linux, loại bỏ nút thắt đồng bộ dựa trên wineserver trước đây
• Driver NTSYNC mới xử lý trực tiếp các đối tượng đồng bộ NT trong kernel, ghi nhận mức tăng FPS tối đa hơn 8 lần
• Hoàn thiện WoW64, cho phép chạy ứng dụng Windows 32-bit trên Linux 64-bit mà không cần thư viện riêng
• Tăng cường driver Wayland, hỗ trợ Vulkan 1.4, cải thiện Bluetooth và force feedback cùng mở rộng khả năng tương thích trên toàn bộ đồ họa và I/O
• Hiệu quả cải thiện hiệu năng và độ ổn định lan rộng ra toàn bộ hệ sinh thái dựa trên Wine như Proton, SteamOS, Lutris

---

Những thay đổi cốt lõi của Wine 11

• Wine 11 không chỉ là một bản cập nhật thường niên đơn thuần, mà là một đợt cải tổ lớn tái viết cách Linux chạy game Windows ở cấp độ kernel

  • Ngoài nhiều năm tích lũy sửa lỗi và cải thiện hiệu năng, còn bao gồm các thay đổi mang tính cấu trúc như hỗ trợ NTSYNC, hoàn thiện WoW64, tăng cường driver Wayland
  • Cải thiện hiệu năng cũng lan sang toàn bộ các dự án dựa trên Wine như Proton, SteamOS

Giới hạn trước đây và các giải pháp tình thế

• Trước đây Wine không thể triển khai hoàn chỉnh các primitive đồng bộ NT của Windows (mutex, semaphore, event, v.v.) trên Linux
  • Để đồng bộ giữa các thread, mỗi lần đều phải thực hiện gọi RPC tới wineserver, với hàng nghìn lần gọi mỗi giây gây ra độ trễ khung hình và thời điểm xử lý thiếu ổn định
• Esync giảm số lần gọi wineserver bằng cách dùng eventfd, nhưng phát sinh vấn đề giới hạn file descriptor
• Fsync nhanh hơn nhờ dựa trên futex, nhưng cần bản vá ngoài kernel nên khó dùng trên các bản phân phối thông thường
  • futex_waitv của Linux 5.16 khác với nguyên mẫu của Fsync và không phải là thay thế hoàn chỉnh
• Cả hai cách đều là giải pháp tạm thời, và không thể triển khai chính xác một số NT API (ví dụ: NtPulseEvent, chế độ wait-for-all của NtWaitForMultipleObjects)

NTSYNC — thiết kế lại cơ chế đồng bộ ở cấp độ kernel

• NTSYNC bổ sung một driver thiết bị /dev/ntsync mới vào Linux kernel để mô hình hóa trực tiếp các đối tượng đồng bộ Windows NT
  • Đồng bộ được xử lý bên trong kernel thay vì user space, loại bỏ các vòng gọi qua lại với wineserver
  • Kernel trực tiếp đảm nhiệm quản lý hàng đợi, ngữ nghĩa event và các thao tác nguyên tử
• Người phát triển là Elizabeth Figura, tác giả của Esync và Fsync; sau khi được trình bày tại Linux Plumbers Conference 2023, tính năng này đã được hợp nhất vào Linux 6.14

• Số liệu cải thiện hiệu năng

  • Dirt 3: 110.6 → 860.7 FPS (tăng 678%)
  • Resident Evil 2: 26 → 77 FPS
  • Call of Juarez: 99.8 → 224.1 FPS
  • Tiny Tina’s Wonderlands: 130 → 360 FPS
  • Call of Duty: Black Ops I đạt trạng thái chơi hoàn chỉnh

• Khác biệt so với fsync

  • Với người dùng fsync, mức cải thiện có thể hạn chế, nhưng ở các game từng có nút thắt đa luồng thì thay đổi là rất lớn
  • Vì đã có trong kernel chính thức, không cần bản vá riêng, có thể dùng ngay trên các bản phân phối mới như Fedora 42, Ubuntu 25.04
  • Được tích hợp mặc định trong SteamOS 3.7.20 beta và cũng đã bật trong Proton GE
  • Đây là lần đầu tiên trong lịch sử Wine, cơ chế đồng bộ chính xác được hiện thực ở cấp độ kernel

Hoàn thiện WoW64 — hợp nhất khả năng tương thích 32-bit

• Kiến trúc WoW64 (Windows 32-bit on Windows 64-bit) đã được hoàn thiện trong Wine 11
  • Trên hệ thống Linux 64-bit, khi chạy ứng dụng Windows 32-bit thì không còn cần cài thêm thư viện 32-bit riêng
  • Một binary duy nhất sẽ tự động phát hiện độ rộng bit của tệp thực thi và xử lý
• Bao gồm cả ánh xạ bộ nhớ OpenGL, truyền qua SCSI và cả hỗ trợ ứng dụng 16-bit
  • Ngay cả phần mềm Windows cũ từ thập niên 1990 cũng có thể chạy được
• Trước đây việc chạy phụ thuộc vào cấu hình multilib khác nhau của từng bản phân phối, nhưng giờ Wine đã tự xử lý nội bộ

Wayland và các cải tiến lớn khác

• Driver Wayland

  • Hỗ trợ sao chép clipboard hai chiều, drag and drop, và compositor scaling khi chuyển độ phân giải, giúp tăng khả năng tương thích với game cũ
  • Phần lớn vấn đề tương thích của Wine khi chuyển từ X11 sang Wayland đã được giải quyết

• Đồ họa và media

  • Trên X11, EGL trở thành backend OpenGL mặc định, thay cho GLX
  • Bổ sung hỗ trợ Vulkan 1.4 và giải mã tăng tốc phần cứng H.264 dựa trên Vulkan Video

• I/O và thiết bị ngoại vi

  • Force feedback được cải thiện, tăng hỗ trợ cho vô lăng đua xe và cần lái bay

  • Hỗ trợ dịch vụ Bluetooth BLE và ghép cặp**,** cải thiện xử lý soundfont MIDI

    • Bổ sung nén Zip64, Unicode 17.0.0, quét TWAIN 2.0 (64-bit), tính năng IPv6 ping

• Hiệu năng và mở rộng nền tảng

  • Cải thiện quản lý ưu tiên thread trên Linux và macOS, tăng hiệu năng đa luồng
  • Bổ sung hỗ trợ mô phỏng kích thước trang 4K trên ARM64, mở rộng khả năng tương thích cho thiết bị Linux dùng ARM

Tương thích game và sửa lỗi

• Cải thiện khả năng tương thích cho các tựa game lớn như Nioh 2, StarCraft 2, The Witcher 2, Call of Duty: Black Ops II, Final Fantasy XI, Battle.net
• Bao gồm hàng trăm bản sửa lỗi, giúp tăng độ ổn định và hiệu năng tổng thể

Đánh giá tổng thể

• Với sự kết hợp của NTSYNC, hoàn thiện WoW64, cải thiện Wayland và sửa lỗi trên diện rộng, Wine 11 là bản phát hành quan trọng nhất kể từ sau Proton
• Hiệu năng và khả năng tương thích đều được cải thiện trên mọi dự án dựa trên Wine như Proton, Lutris, Bottles
• Với người dùng chơi game trên Linux, Wine 11 là một phiên bản rất đáng để thử

[kh0324]

Kết luận là lại thành chuyện đánh đổi bằng việc làm hỏng khả năng tương thích ngược của cả đống game cũ trong vài năm nữa thôi..

Đúng là kiểu trao đổi tương đương mà

[GN⁺]

Ý kiến trên Hacker News

• Tôi gần như có sự kính trọng vô hạn dành cho dự án Wine
  Trong 30 năm, việc cố tái hiện y nguyên hành vi được ghi chép/không được ghi chép của Windows nghe có vẻ là một công việc tẻ nhạt và ít được đền đáp, nhưng chính nhờ vậy mà Wine đã trở thành một sản phẩm thực sự dùng được
  Đặc biệt khi thấy các game cũ chạy còn tốt hơn trên Windows, tôi cảm nhận được mức độ tỉ mỉ và khả năng chịu đựng đau khổ của họ thật đáng nể

  • Trước đây tôi từng nghĩ Wine không thể nào hoạt động tử tế nên tránh chơi game trên Linux
    Thỉnh thoảng tôi thử chạy vài game đơn giản và nghĩ “ơ, cái này chạy được à?”, nhưng chưa từng cho rằng nó đáng tin cậy
    Giờ thì tôi thừa nhận phán đoán đó là hoàn toàn sai
  • Dù là một dự án thực sự tuyệt vời, vẫn đáng tiếc là các ứng dụng phục vụ công việc như Word, Excel hay Outlook vẫn chưa chạy tốt
    Nghe nói Excel 2010 là phiên bản cuối cùng đạt hạng Platinum
    Thật thú vị khi các ứng dụng kiểu này lại khó hơn cả game
  • Wine tự động chạy kiểm thử tương thích trên nhiều nền tảng khác nhau
    Nhìn vào trang kết quả kiểm thử, có thể thấy việc kiểm chứng có hệ thống như vậy là chìa khóa tạo nên mức tương thích cao
  • ReactOS cũng đáng được nhắc đến
    Kiến thức thu được từ dự án đó đã chảy vào việc phát triển Wine rất nhiều
  • Hồi những năm 90 khi dùng OS/2, nếu muốn chạy ứng dụng Windows thì phải khởi chạy cả Windows
    Khi đó tôi từng muốn tự làm một thứ như Wine, nhưng không đủ kiến thức
    Giờ tôi chỉ dùng Linux cho máy chủ nên không có dịp dùng, và dù nghe nói cũng có Wine cho Mac, tôi chẳng có ứng dụng Windows nào thật sự muốn chạy cả

• Tôi ngạc nhiên khi thấy số khung hình game tăng mạnh nhờ Proton
  Dirt 3 tăng từ 110FPS lên 860FPS, Resident Evil 2 từ 26FPS lên 77FPS, thật khó tin
  Tôi nghĩ đó là nhờ Valve đã đổ tiền mạnh vào chuyện này

  • Tuy nhiên các con số này là kết quả so sánh Wine+ntsync với Wine bản mặc định, nên có phần cường điệu
    Nếu so với Wine dùng fsync trước đó thì mức cải thiện chỉ ở mức vài phần trăm
    Dù vậy ntsync vẫn là một cải tiến rõ ràng
    Xem tài liệu về ntsync thì đây là driver kernel nhằm triển khai chính xác hơn cấu trúc đồng bộ hóa của Windows trên Linux
  • Cũng cần lưu ý đây là phép so sánh trong trường hợp không dùng esync hay fsync
  • Tôi tò mò về mối quan hệ giữa Proton và Wine — Proton chỉ là tên mà Valve/SteamOS dùng, hay là một dự án tách biệt?

• Cũng có ý kiến cho rằng đừng quá phấn khích về mức tăng hiệu năng của ntsync
  Trong đa số trường hợp, cải thiện hiệu năng chỉ ở mức phần trăm một chữ số, và một số game thậm chí còn có thể chậm đi đôi chút

  • Nếu bạn đang dùng kernel không có bản vá fsync thì câu chuyện có thể khác
  • Cũng có ý kiến cho rằng đáng để so sánh cả chênh lệch hiệu năng giữa Wayland và X11

• Mỗi lần đọc những câu chuyện kỹ thuật cấp thấp như thế này, tôi lại thấy xấu hổ vì mình chỉ làm ứng dụng CRUD

  • Nhưng CRUD cũng có giá trị và tốt cho sức khỏe tinh thần
    Tôi từng nghe một giai thoại về một lập trình viên thiên tài bị vắt kiệt trong lịch trình cực hạn rồi cuối cùng chuyển sang làm các công việc CRUD đơn giản bằng VB và nói rằng nó “như một kỳ nghỉ có lương”
  • Tôi cũng chỉ giúp những việc đơn giản kiểu “bấm chỗ này, bấm chỗ kia” trong Outlook, nhưng những việc đó cũng là công việc thiết yếu
  • Ngược lại, ngay cả các lập trình viên cấp thấp khi xử lý hệ thống cấp cao cũng nói rằng họ thấy bản thân còn thiếu sót
  • Ngay cả tôi, người làm compiler, cũng đã thử làm ứng dụng CRUD cho dự án cá nhân nhiều lần rồi thất bại
    Tôi đã thử Rails, Phoenix, Django cả rồi nhưng không hề dễ
    Gần đây có chút tiến triển nhờ sự giúp sức của Claude
  • Ứng dụng CRUD cũng không hề đơn giản
    Yêu cầu doanh nghiệp rất phức tạp nên kiến trúc có thể sụp đổ rất dễ dàng

• Tôi vui khi biết số tiền hàng nghìn đô mà mình chi cho Valve cuối cùng lại được dùng để cải thiện Wine
  Tôi tò mò không biết Valve đã thuê bao nhiêu nhà phát triển và cộng tác viên cho việc này

  • Hai phần ba các nhà phát triển Wine thuộc CodeWeavers, và họ có hợp đồng Proton với Valve
    Nói cách khác, phần lớn nguồn vốn chảy về phía đó

• Một cách nghịch lý, Wine có thể mang tính tự hủy
  Nếu game chạy tốt trên Linux, các nhà phát triển có thể sẽ làm hẳn bản port Linux và khi đó Wine có thể không còn cần thiết nữa

  • Nhưng API của Wine lại ổn định hơn Linux, nên thậm chí Wine có thể trở thành mục tiêu hạng nhất
  • Tôi nghĩ thực tế lại ngược lại
    Ngay cả khi có bản port native, việc chạy bản Windows bằng Proton vẫn ổn định hơn
    API Windows quen thuộc và không thay đổi, nên các nhà phát triển tiếp tục lấy đó làm chuẩn để phát triển
  • Ngày nay “hỗ trợ Linux” về cơ bản có nghĩa là đảm bảo chạy tốt trên Proton
  • Tôi nghĩ đây là một “vấn đề tốt”
  • Hơn nữa, Wine còn được dùng cho nhiều mục đích ngoài game, nên dù số bản port native có tăng thì nhu cầu vẫn sẽ còn
    Vì ABI Windows vẫn ổn định hơn, nên miễn là chênh lệch hiệu năng không đáng kể, chỉ duy trì bản build Windows vẫn là phương án hiệu quả

• Có người hỏi liệu có thể triển khai ntsync trong không gian người dùng bằng bộ nhớ dùng chung hay không
  Claude giải thích rằng “vì với 95% số game, cách tiếp cận đơn giản đã đủ dùng nên không có động lực để hiện thực logic bộ nhớ dùng chung phức tạp, và đến khi độ chính xác trở nên quan trọng thì việc đưa nó vào kernel là điều tự nhiên”

  • Nhưng trên thực tế điều đó là không thể vì Linux không cung cấp tính năng không gian người dùng như vậy
    ntsync không chỉ là một lớp bọc API đơn giản mà là một bộ điều hợp ở cấp kernel tái hiện hành vi đồng bộ hóa của kernel NT
    Nhìn vào mã nguồn có thể thấy nó gắn chặt với bộ lập lịch của kernel
  • Tài liệu kernel cũng ghi rõ rằng “triển khai ở không gian người dùng không thể đạt được mức hiệu năng và độ chính xác như trên Windows”
    Liên kết tài liệu

• Thật đáng kinh ngạc khi thấy Linux tái hiện Windows mà còn làm tốt hơn
  Trong lúc Microsoft ngày càng khiến phần mềm của chính mình trở nên bất tiện, thành tựu như thế này thật ấn tượng

  • Đặc biệt, việc Wine vẫn duy trì hỗ trợ 16-bit đã biến mất trên Windows 64-bit là rất có ý nghĩa
    Nhiều game cũ dựa trên 16-bit, và ngay cả game 32-bit thì trình cài đặt cũng thường là 16-bit

• Nếu có nhà phát triển Wine nào đọc được bài này, tôi mong họ sẽ có một buổi nói chuyện liên quan tại Carolina Code Conference 2026
  Đợt nhận diễn giả đang mở đến ngày 31 tháng 3

• Nếu muốn điều tương tự trên macOS thì có thể đóng góp cho kho lưu trữ này

  • Nhưng thành thật mà nói, game cho MacOS quá ít nên có lẽ cũng gần như không có nhà phát triển nào quan tâm
    Tôi có ký ức chơi game xe tăng Bolo trên máy Mac ở trường ngày xưa, nhưng tổng số game chắc còn chưa bằng 1% số game Windows
  • Nhưng nếu vì lý do hiệu năng mà phải đưa vào kernel, thì tôi lại tò mò vì sao Linux không làm điều đó trong không gian người dùng