Wine 11 เขียนวิธีรันเกม Windows บน Linux ใหม่ในระดับเคอร์เนล พร้อมยกระดับประสิทธิภาพครั้งใหญ่

 (xda-developers.com)
23 คะแนน โดย GN⁺ 2026-03-25 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • มีการออกแบบโครงสร้างการรันเกม Windows บน Linux ใหม่ทั้งหมดในระดับเคอร์เนล เพื่อตัดคอขวดการซิงโครไนซ์แบบเดิมที่อาศัย wineserver
  • ไดรเวอร์ NTSYNC ใหม่จัดการอ็อบเจ็กต์ซิงโครไนซ์ของ NT ได้โดยตรงในเคอร์เนล และทำสถิติได้ว่า FPS เพิ่มขึ้นสูงสุดมากกว่า 8 เท่า
  • การทำ WoW64 เสร็จสมบูรณ์ ทำให้บน Linux 64 บิตสามารถรันแอป Windows 32 บิตได้โดยไม่ต้องใช้ไลบรารีแยกต่างหาก
  • มีการขยายความเข้ากันได้ทั้งด้านกราฟิกและอินพุต/เอาต์พุต เช่น เสริมไดรเวอร์ Wayland, รองรับ Vulkan 1.4, และ ปรับปรุง Bluetooth·Force feedback
  • ผลลัพธ์ด้านประสิทธิภาพและเสถียรภาพที่ดีขึ้น กระจายไปทั่วทั้งอีโคซิสเต็มที่อิงกับ Wine เช่น Proton, SteamOS และ Lutris

การเปลี่ยนแปลงสำคัญของ Wine 11

  • Wine 11 ไม่ใช่แค่อัปเดตรายปีธรรมดา แต่เป็นรุ่นปรับโครงสร้างครั้งใหญ่ที่เขียนวิธีรันเกม Windows บน Linux ใหม่ในระดับเคอร์เนล

    • นอกจากการสะสมการแก้บั๊กและปรับปรุงประสิทธิภาพมาหลายปีแล้ว ยังมีการเปลี่ยนแปลงเชิงโครงสร้างอย่าง รองรับ NTSYNC, ทำ WoW64 เสร็จสมบูรณ์, และ เสริมไดรเวอร์ Wayland
    • การยกระดับประสิทธิภาพยังส่งผลไปยังโครงการทั้งหมดที่อิงกับ Wine เช่น Proton และ SteamOS

ข้อจำกัดเดิมและวิธีแก้ชั่วคราว

  • ก่อนหน้านี้ Wine ไม่สามารถอิมพลีเมนต์ primitive การซิงโครไนซ์ของ Windows NT (mutex, semaphore, event เป็นต้น) บน Linux ได้อย่างสมบูรณ์
    • ทุกครั้งที่ต้องซิงโครไนซ์ระหว่างแต่ละเธรด จะต้องเรียก RPC ไปยัง wineserver ทำให้มีการเรียกหลายพันครั้งต่อวินาที และก่อให้เกิดอาการเฟรมหน่วงกับจังหวะเวลาที่ไม่สม่ำเสมอ
  • Esync ใช้ eventfd เพื่อลดการเรียก wineserver แต่เจอปัญหาขีดจำกัดของ file descriptor
  • Fsync เร็วกว่าโดยอิงกับ futex แต่ต้องใช้ แพตช์นอกเคอร์เนล ทำให้ใช้งานได้ยากบนดิสทริบิวชันทั่วไป
    • futex_waitv ใน Linux 5.16 แตกต่างจากต้นแบบของ Fsync และไม่ใช่ตัวแทนที่สมบูรณ์
  • ทั้งสองแนวทางเป็นเพียงวิธีแก้เฉพาะหน้า และไม่สามารถอิมพลีเมนต์ NT API บางส่วนได้อย่างถูกต้อง (เช่น NtPulseEvent, โหมด wait-for-all ของ NtWaitForMultipleObjects)

NTSYNC — ออกแบบการซิงโครไนซ์ใหม่ในระดับเคอร์เนล

  • NTSYNC เพิ่ม ไดรเวอร์อุปกรณ์ /dev/ntsync ใหม่เข้าไปใน Linux kernel เพื่อจำลองอ็อบเจ็กต์ซิงโครไนซ์ของ Windows NT โดยตรง
    • จัดการการซิงโครไนซ์ ภายในเคอร์เนล แทน user space และตัดการเรียกไป-กลับของ wineserver
    • เคอร์เนลเป็นผู้จัดการคิว, semantics ของ event และการดำเนินการแบบอะตอมทั้งหมดโดยตรง
  • ผู้พัฒนาคือ Elizabeth Figura ผู้สร้าง Esync และ Fsync โดยมีการนำเสนอในงาน Linux Plumbers Conference ปี 2023 ก่อนถูกรวมเข้า Linux 6.14

  • ตัวเลขการเพิ่มประสิทธิภาพ

    • Dirt 3: 110.6 → 860.7 FPS (เพิ่มขึ้น 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 อยู่ในสถานะที่เล่นได้สมบูรณ์

  • ความแตกต่างเมื่อเทียบกับ fsync

    • สำหรับผู้ใช้ fsync การปรับปรุงอาจมีจำกัด แต่ใน เกมที่มีคอขวดด้านมัลติเธรด จะเห็นการเปลี่ยนแปลงอย่างชัดเจน
    • เนื่องจาก รวมอยู่ใน mainline kernel จึงไม่ต้องใช้แพตช์แยก และใช้งานได้ทันทีบนดิสทริบิวชันใหม่อย่าง Fedora 42 และ Ubuntu 25.04
    • มีมาให้โดยค่าเริ่มต้นใน SteamOS 3.7.20 เบตา และถูกเปิดใช้งานใน Proton GE ด้วย
    • NTSYNC เป็นกรณีแรกในประวัติศาสตร์ของ Wine ที่ทำให้เกิดการอิมพลีเมนต์การซิงโครไนซ์อย่างถูกต้องในระดับเคอร์เนล

WoW64 เสร็จสมบูรณ์ — รวมความเข้ากันได้ของ 32 บิต

  • สถาปัตยกรรม WoW64 (Windows 32-bit on Windows 64-bit) ถูกอิมพลีเมนต์จนเสร็จสมบูรณ์ใน Wine 11
    • บนระบบ Linux 64 บิต สามารถรัน แอป Windows 32 บิตได้โดยไม่ต้องติดตั้งไลบรารี 32 บิตแยก
    • ไบนารีเดียวสามารถตรวจจับบิตของไฟล์ปฏิบัติการและจัดการให้โดยอัตโนมัติ
  • ครอบคลุมถึงการแมปหน่วยความจำของ OpenGL, SCSI passthrough และแม้แต่ รองรับแอปพลิเคชัน 16 บิต
    • ทำให้ซอฟต์แวร์ Windows รุ่นเก่าจากยุค 1990 ยังสามารถรันได้
  • เดิมทีการรันทำได้ยากเพราะการตั้งค่า multilib ของแต่ละดิสทริบิวชันแตกต่างกัน แต่ตอนนี้ Wine จัดการภายในเองแล้ว

Wayland และการปรับปรุงสำคัญอื่น ๆ

  • ไดรเวอร์ Wayland

    • รองรับการคัดลอกคลิปบอร์ดแบบสองทาง, drag and drop, และ การสเกลโดย compositor เมื่อสลับความละเอียด เพื่อเพิ่มความเข้ากันได้กับเกมเก่า
    • ปัญหาความเข้ากันได้ของ Wine ส่วนใหญ่ที่เกิดขึ้นระหว่างการย้ายจาก X11 ไป Wayland ได้รับการแก้ไขแล้ว

  • กราฟิกและสื่อ

    • บน X11 มีการเปลี่ยน EGL ให้เป็นแบ็กเอนด์ OpenGL เริ่มต้น แทน GLX
    • เพิ่ม รองรับ Vulkan 1.4 และ การถอดรหัส H.264 ด้วยฮาร์ดแวร์ผ่าน Vulkan Video

  • อินพุต/เอาต์พุตและอุปกรณ์ต่อพ่วง

    • ปรับปรุง Force feedback เพื่อรองรับพวงมาลัยแข่งรถและ flight stick ได้ดีขึ้น

    • เพิ่มการรองรับบริการและการจับคู่ Bluetooth BLE รวมถึงปรับปรุงการจัดการ soundfont ของ MIDI

      • เพิ่มความสามารถ Zip64 compression, Unicode 17.0.0, TWAIN 2.0 scanning (64-bit) และ IPv6 ping

  • ประสิทธิภาพและการขยายแพลตฟอร์ม

    • ปรับปรุง การจัดการลำดับความสำคัญของเธรด บน Linux และ macOS ทำให้ประสิทธิภาพแบบมัลติเธรดดีขึ้น
    • เพิ่มการรองรับการจำลองขนาดเพจ 4K บน ARM64 เพื่อให้เข้ากันได้กับอุปกรณ์ Linux ที่ใช้ ARM

ความเข้ากันได้ของเกมและการแก้บั๊ก

  • ปรับปรุงความเข้ากันได้ของเกมหลัก ๆ เช่น Nioh 2, StarCraft 2, The Witcher 2, Call of Duty: Black Ops II, Final Fantasy XI และ Battle.net
  • มีการแก้บั๊กหลายร้อยรายการ ส่งผลให้เสถียรภาพและประสิทธิภาพโดยรวมดีขึ้น

การประเมินโดยรวม

  • ด้วยการรวมกันของ NTSYNC, WoW64 ที่เสร็จสมบูรณ์, การปรับปรุง Wayland และ การแก้บั๊กครั้งใหญ่ ทำให้ Wine 11 เป็นรีลีสที่สำคัญที่สุดนับตั้งแต่ Proton
  • ประสิทธิภาพและความเข้ากันได้ของทุกโครงการที่อิงกับ Wine เช่น Proton, Lutris และ Bottles ดีขึ้น
  • สำหรับผู้ใช้ที่เล่นเกมบน Linux Wine 11 เป็นเวอร์ชันที่ควรลองอย่างยิ่ง

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

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

 
kh0324 2026-03-28

สรุปก็คงออกมาเป็นผลลัพธ์แบบว่าเกมเก่าอีกหลายปีพังเรื่องความเข้ากันได้ย้อนหลังอีกสินะ..

นี่มันการแลกเปลี่ยนที่เท่าเทียมกันนี่นา
 
GN⁺ 2026-03-25
ความเห็นจาก Hacker News

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

    • เมื่อก่อนฉันคิดว่า Wine คงไม่มีทางทำงานได้ดี เลยหลีกเลี่ยงการเล่นเกมบน Linux
      บางครั้งลองรันเกมง่าย ๆ แล้วก็คิดว่า “อ้าว มันได้แฮะ?” แต่ก็ยังไม่คิดว่ามันเชื่อถือได้
      ตอนนี้ยอมรับแล้วว่าการตัดสินนั้น ผิดสนิท
    • แม้จะเป็นโปรเจกต์ที่ยอดเยี่ยมมาก แต่ก็น่าเสียดายที่ แอปสายธุรกิจ อย่าง Word, Excel, Outlook ยังทำงานได้ไม่ดีนัก
      ว่ากันว่า Excel 2010 เป็นเวอร์ชันสุดท้ายที่ได้ระดับ Platinum
      น่าสนใจว่าทำไมแอปพวกนี้ถึงยากกว่าเกม
    • Wine รัน การทดสอบความเข้ากันได้ แบบอัตโนมัติบนหลายแพลตฟอร์ม
      ดูจากหน้าผลการทดสอบ จะเห็นว่าการตรวจสอบอย่างเป็นระบบแบบนี้คือกุญแจสำคัญที่ทำให้ความเข้ากันได้สูง
    • ReactOS ก็ควรค่าแก่การพูดถึง
      ความรู้ที่ได้จากโปรเจกต์นั้นไหลเข้ามาสู่การพัฒนา Wine มากพอสมควร
    • ตอนใช้ OS/2 ในยุค 90 ถ้าอยากรันแอป Windows ก็ต้องเปิด Windows ทั้งระบบขึ้นมาก่อน
      ตอนนั้นอยากสร้างอะไรแบบ Wine เอง แต่ยังมีความรู้ไม่พอ
      ตอนนี้ใช้ Linux แค่สำหรับเซิร์ฟเวอร์เลยไม่ได้ใช้มันแล้ว และก็ได้ยินว่ามี Wine สำหรับ Mac ด้วย แต่ก็ไม่มีแอป Windows อะไรที่อยากรันเป็นพิเศษ

  • รู้สึกทึ่งที่เห็นเฟรมเรตเกมพุ่งขึ้นมหาศาลเพราะ Proton
    Dirt 3 จาก 110FPS ไปเป็น 860FPS และ Resident Evil 2 จาก 26FPS ไปเป็น 77FPS นี่แทบไม่น่าเชื่อ
    คิดว่านี่เป็นผลจากการที่ Valve ทุ่มเงินลงไปกับเรื่องนี้

    • แต่ตัวเลขนี้เป็นการเปรียบเทียบระหว่าง Wine+ntsync กับ Wine เวอร์ชันพื้นฐาน เลยมีส่วนที่ดูเกินจริง
      ถ้าเทียบกับ Wine แบบเดิมที่ใช้ fsync การปรับปรุงจะอยู่แค่ระดับไม่กี่เปอร์เซ็นต์
      ถึงอย่างนั้น ntsync ก็ยังเป็นการพัฒนาที่ชัดเจน
      ดูจากเอกสารของ ntsync มันคือไดรเวอร์ในเคอร์เนลที่ทำขึ้นเพื่อจำลองโครงสร้างการซิงก์ของ Windows บน Linux ให้แม่นยำขึ้น
    • ต้องระวังด้วยว่านี่คือการเปรียบเทียบในกรณี ไม่ได้ใช้ esync หรือ fsync
    • อยากรู้ความสัมพันธ์ระหว่าง Proton กับ Wine — Proton เป็นแค่ชื่อที่ใช้สำหรับ Valve/SteamOS หรือเป็นโปรเจกต์แยกต่างหาก

  • มีความเห็นด้วยว่าไม่ควรตื่นเต้นกับการเพิ่มประสิทธิภาพของ ntsync มากเกินไป
    ในกรณีส่วนใหญ่ประสิทธิภาพเพิ่มขึ้นแค่ระดับเลขหลักเดียว และบางเกมอาจกลับช้าลงเล็กน้อยด้วยซ้ำ

    • ถ้าเป็นคนที่ใช้เคอร์เนลที่ไม่มีแพตช์ fsync เรื่องก็อาจต่างออกไป
    • มีคนเสนอว่าความต่างด้านประสิทธิภาพระหว่าง Wayland กับ X11 ก็น่าลองเปรียบเทียบเหมือนกัน

  • เวลาเห็นเรื่องเทคนิคระดับล่างแบบนี้แล้วรู้สึกอายที่ตัวเองทำแต่ แอป CRUD

    • แต่ CRUD ก็มีคุณค่า และดีต่อสุขภาพจิต
      เคยได้ยินเรื่องเล่าว่านักพัฒนาระดับอัจฉริยะคนหนึ่งโดนตารางงานสุดโหดกดดันจนสุดท้ายย้ายไปทำงาน VB CRUD ง่าย ๆ แล้วบอกว่า “เหมือนวันลาพักร้อนแบบได้เงินเดือน”
    • ฉันเองก็ช่วยเรื่องง่าย ๆ ใน Outlook แบบ “คลิกตรงนี้ คลิกตรงนั้น” แต่เรื่องแบบนี้ก็เป็น งานที่จำเป็น
    • ในทางกลับกัน นักพัฒนาระดับล่างเองเวลาเจอระบบระดับสูงก็รู้สึกว่าตัวเองไม่เก่งพอเหมือนกัน
    • ต่อให้ฉันจะทำคอมไพเลอร์ได้ แต่ก็พยายามทำแอป CRUD สำหรับโปรเจกต์ส่วนตัวหลายครั้งแล้วล้มเหลว
      ลองทั้ง Rails, Phoenix, Django แล้ว แต่ก็ไม่ง่าย
      ช่วงหลัง ๆ มีความคืบหน้าขึ้นนิดหน่อยด้วยความช่วยเหลือจาก Claude
    • แอป CRUD ก็ไม่ใช่ของง่าย
      ความต้องการขององค์กรซับซ้อนมากจน สถาปัตยกรรมพังได้ง่าย

  • ดีใจที่เงินหลายพันดอลลาร์ที่จ่ายให้ Valve สุดท้ายถูกนำไปใช้ปรับปรุง Wine
    เลยสงสัยว่า Valve จ้างนักพัฒนาและผู้รับเหมาไว้มากแค่ไหน

    • นักพัฒนา Wine ราว 2 ใน 3 สังกัด CodeWeavers และมีสัญญากับ Valve/Proton
      หมายความว่าเงินทุนส่วนใหญ่ไหลไปทางนั้น

  • Wine อาจมีความย้อนแย้งตรงที่ ทำลายตัวเอง ก็ได้
    ถ้าเกมรันบน Linux ได้ดี นักพัฒนาอาจทำพอร์ตลง Linux โดยตรงจนไม่ต้องใช้ Wine อีกต่อไป

    • แต่ API ของ Wine เสถียรกว่า Linux เสียอีก จึงอาจกลายเป็นว่า Wine กลายเป็นเป้าหมายระดับหลักแทน
    • ฉันกลับคิดว่าความจริงเป็นตรงข้าม
      ต่อให้มี native port การรันเวอร์ชัน Windows ผ่าน Proton ก็ยังเสถียรกว่า
      Windows API คุ้นเคยและไม่ค่อยเปลี่ยน ทำให้นักพัฒนายังคงพัฒนาโดยยึดฝั่งนั้นเป็นหลัก
    • ทุกวันนี้คำว่า “รองรับ Linux” มักหมายถึง ทำให้รันบน Proton ได้ดี
    • มองว่าเป็น “ปัญหาที่ดี”
    • อีกอย่าง Wine ก็ยังถูกใช้ในงานอีกหลากหลาย ไม่ได้มีแค่เกม ดังนั้นถึง native port จะเพิ่มขึ้น ความต้องการก็น่าจะยังมีต่อไป
      เพราะ Windows ABI ยังเสถียรกว่าอยู่มาก ตราบใดที่ความต่างด้านประสิทธิภาพยังน้อย การดูแลแค่ Windows build เดียวก็ยังคุ้มกว่า

  • มีคนถามว่าเราจะทำ ntsync ใน user space ด้วย shared memory ไม่ได้หรือ
    Claude อธิบายว่า “สำหรับ 95% ของเกม วิธีที่ง่ายกว่านั้นก็เพียงพอแล้ว จึงไม่มีแรงจูงใจให้ทำลอจิก shared memory ที่ซับซ้อน และเมื่อถึงจุดที่ความถูกต้องสำคัญขึ้น การเอาไปไว้ในเคอร์เนลก็เป็นทางเลือกที่เป็นธรรมชาติ”

    • แต่ในความเป็นจริง มันทำไม่ได้เพราะ Linux ไม่มีความสามารถใน user space แบบนั้นให้ใช้งาน
      ntsync ไม่ใช่แค่ตัวห่อ API ธรรมดา แต่เป็น ตัวปรับระดับเคอร์เนล ที่จำลองพฤติกรรมการซิงก์ของ NT kernel
      ดูจากซอร์สโค้ด จะเห็นว่ามันผูกกับ scheduler ของเคอร์เนลอย่างใกล้ชิด
    • ในเอกสารของเคอร์เนลก็ระบุชัดว่า “การทำใน user space ไม่สามารถให้ประสิทธิภาพและความถูกต้องระดับ Windows ได้”
      ลิงก์เอกสาร

  • น่าทึ่งที่ได้เห็น Linux นำ Windows มาสร้างใหม่แล้วทำได้ดีกว่าเดิมเสียอีก
    ในขณะที่ Microsoft ทำให้ซอฟต์แวร์ของตัวเองใช้งานยากขึ้นเรื่อย ๆ ความสำเร็จแบบนี้ยิ่งน่าประทับใจ

    • โดยเฉพาะการที่ Wine ยังคงรองรับ 16-bit ซึ่งหายไปจาก Windows 64-bit แล้ว นี่มีความหมายมาก
      เกมเก่า ๆ หลายเกมสร้างอยู่บนฐาน 16-bit และแม้แต่เกม 32-bit บางเกม ตัวติดตั้งก็ยังเป็น 16-bit

  • ถ้ามีนักพัฒนา Wine มาเห็นโพสต์นี้ อยากให้ไปพูดเรื่องนี้ที่ Carolina Code Conference 2026
    เปิดรับวิทยากรถึงวันที่ 31 มีนาคม

  • ถ้าอยากได้อะไรแบบเดียวกันบน macOS ก็ไปช่วยรีโพซิทอรีนี้ได้

    • แต่พูดตรง ๆ ว่า เกมบน MacOS มีน้อยเกินไป จนอาจแทบไม่มีนักพัฒนาที่สนใจ
      ถึงจะมีความทรงจำสมัยก่อนที่เคยเล่นเกมรถถัง Bolo บน Mac ที่โรงเรียน แต่ก็คงมีไม่ถึง 1% ของจำนวนเกมบน Windows
    • แต่ถ้าสุดท้ายต้องใส่ไว้ในเคอร์เนลเพราะเหตุผลด้านประสิทธิภาพ ก็ยังสงสัยอยู่ว่าทำไม Linux ถึงไม่ทำใน user space ตั้งแต่แรก