ไดรเวอร์ GPU Apple M1/M2 เดินหน้าถึง OpenGL 4.6 และ Vulkan 1.3

 (lwn.net)
1 คะแนน โดย GN⁺ 2024-11-01 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ไดรเวอร์กราฟิกระดับเคอร์เนลสำหรับ GPU Apple M1/M2 นอกจากมีจุดเด่นว่า พัฒนาบน Rust แล้วยังผ่านความสอดคล้องตามมาตรฐาน OpenGL 4.6 และ Vulkan 1.3 ทำให้รองรับมาตรฐานได้กว้างขึ้น
  • Tessellation ซึ่งเป็นหัวใจของ OpenGL 4.0 ทำให้เป็นไปตามมาตรฐานได้ยากด้วยความสามารถของฮาร์ดแวร์ Apple GPU เพียงอย่างเดียว จึงจัดการด้วยการพอร์ต reference tessellator ของ Microsoft ไปเป็น OpenCL C แล้วรันบน GPU
  • ในเดโม Vulkan บน M2 Mac, tessellation ที่ใช้ OpenCL ทำได้ 265fps เร็วกว่าการทำแบบซอฟต์แวร์ล้วนที่ต่ำกว่า 1fps มาก แต่ยังไม่ถึงฮาร์ดแวร์ tessellator ที่ทำได้ 820fps
  • การรันเกม AAA ต้องปรับสภาพแวดล้อม DirectX·Windows·x86·เพจ 4KB ให้เข้ากับ Apple Silicon ที่อิง Linux·Arm64·เพจ 16KB โดยใช้ทั้งหลายชั้นการแปลงและการตั้งค่า virtual machine ร่วมกัน
  • เกมอย่าง Portal, The Witcher 3 และ Cyberpunk 2077 รันได้จริงแล้ว แต่ความต้องการหน่วยความจำและขอบเขตการรองรับ ray tracing ยังคงเป็นข้อจำกัดสำคัญ

ไดรเวอร์ Apple GPU ที่ขยับขึ้นถึง OpenGL 4.6

  • ไดรเวอร์กราฟิกระดับเคอร์เนลสำหรับ GPU Apple M1/M2 เขียนด้วย Rust และผ่าน ความสอดคล้องตามมาตรฐาน ของมาตรฐานกราฟิกหลายรายการ
  • Alyssa Rosenzweig อัปเดตสถานะไดรเวอร์และเกมที่รองรับได้ในงาน X.Org Developers Conference 2024
  • ใน XDC ปีก่อน ไดรเวอร์ผ่านความสอดคล้องของ OpenGL ES 3.1 และหลังจากนั้นก็มาถึงความสอดคล้องของ OpenGL 4.6
  • Tessellation) ที่จำเป็นใน OpenGL 4.0 คือเทคนิคสำหรับเพิ่มหรือลดรายละเอียดของฉากแบบไดนามิก

ข้อจำกัดของฮาร์ดแวร์ tessellator ใน Apple GPU

  • Apple GPU มี hardware tessellator แต่ขาดฟังก์ชันที่จำเป็นสำหรับการทำตามมาตรฐาน OpenGL ไดรเวอร์จึงไม่สามารถใช้ตรง ๆ ได้
  • ดูเหมือนว่าฮาร์ดแวร์จะไม่รองรับ point mode และ isoline โดยทั้งสองฟังก์ชันนี้สามารถจำลองได้
  • ปัญหาใหญ่กว่าคือ transform feedback และ geometry shader
    • ฮาร์ดแวร์ไม่รองรับทั้งสองอย่าง
    • ไดรเวอร์จำลองสิ่งเหล่านี้ด้วย compute shader
    • ความแตกต่างระหว่างอัลกอริทึม tessellation ของ hardware tessellator กับของการจำลองอาจทำให้ invariance ล้มเหลว จึงควรหลีกเลี่ยงชุดผสมนี้
  • Apple รองรับ OpenGL 4.1 แต่ไม่ได้มีความสอดคล้องตามมาตรฐาน และฟังก์ชันที่ฮาร์ดแวร์ไม่รองรับจะถูกแทนที่ด้วยซอฟต์แวร์
  • Rosenzweig ระบุว่าเธอไม่ได้กำลังทำ implementation ของ Metal จึงจะไม่ไปในแนวทางนั้น

Reference tessellator ที่พอร์ตไปเป็น OpenCL C

  • ไดรเวอร์ใช้ reference tessellator ที่ Microsoft เผยแพร่มากว่า 10 ปีก่อน
    • เดิมเป็นโค้ดสำหรับแสดงพฤติกรรมที่ผู้ผลิตฮาร์ดแวร์ควร implement เมื่อเริ่มรองรับ tessellation
    • เป็นโค้ด C++ ประมาณ 2,000 บรรทัด และ tessellate patch เดียว
  • เนื่องจากในไดรเวอร์ GPU ไม่สามารถรัน C++ 2,000 บรรทัดนี้ตรง ๆ ได้ จึงพอร์ตโค้ดนี้ไปเป็น OpenCL C
    • OpenCL C แทบเหมือน C สำหรับ CPU ทั่วไป แต่มีข้อจำกัดและส่วนขยายสำหรับ GPU
    • เป้าหมายไม่ใช่การทำความเข้าใจโค้ดทั้งหมด แต่คือไม่ทำให้พฤติกรรมเสียระหว่างการพอร์ต
  • CPU tessellator ประมวลผลได้ครั้งละหนึ่ง patch เท่านั้น แต่ในฉากอาจมี patch 10,000 รายการ
    • ใช้ความขนานขนาดใหญ่ของ GPU ให้หลายเธรดทำ tessellation
    • ระหว่างประมวลผลแบบขนาน การจัดสรร output buffer จัดการด้วยคำสั่ง atomic ของ GPU
  • เอาต์พุตของ tessellator ต้องถูกวาดเป็นคำสั่ง draw ในรูปแบบ packed data structure ที่ GPU ต้องการ
    • โดยทั่วไปในโค้ดไดรเวอร์ภาษา C จะมีฟังก์ชันที่สร้างโดย GenXML tool คอยจัดการส่วนนี้
    • เนื่องจาก tessellator อยู่ในรูปโค้ด C ด้วย OpenCL จึงสามารถรวมฟังก์ชันที่สร้างขึ้นเข้าไปในโค้ดที่รันบน GPU ได้

ประสิทธิภาพของ tessellation

  • Tessellation ที่ใช้ OpenCL ถูกใช้เพื่อรัน terrain tessellation ของเดโม Vulkan บน M2 Mac
  • การเปรียบเทียบประสิทธิภาพมีดังนี้
    • terrain tessellation แบบซอฟต์แวร์ล้วน: ต่ำกว่า 1fps
    • tessellation ที่ใช้ OpenCL: 265fps
    • ตัวเลขที่วัดได้เมื่อเชื่อมต่อ hardware tessellator: 820fps
  • Rosenzweig ประเมินว่าประสิทธิภาพของวิธี OpenCL นั้น “ใช้ได้” และมองว่าในเกมจริงมีโอกาสน้อยที่จะกลายเป็นคอขวด
  • ประสิทธิภาพของไดรเวอร์ยังมีพื้นที่ให้ปรับปรุงได้อีก

Vulkan 1.3 และ Honeykrisp

  • ไดรเวอร์ GPU Honeykrisp M1/M2 ผ่าน ความสอดคล้องตามมาตรฐาน Vulkan 1.3
  • จุดเริ่มต้นคือการคัดลอก NVK Vulkan driver for NVIDIA GPUs แล้วนำมาผสานกับไดรเวอร์ OpenGL 4.6
    • เริ่มผ่านชุดทดสอบความสอดคล้องได้ภายในประมาณหนึ่งเดือน
    • จุดนั้นเกิดขึ้น 6 เดือนก่อนการนำเสนอ
  • หลังจากนั้นมีการเพิ่มฟังก์ชันต่อไปนี้
    • geometry shader
    • tessellation shader
    • transform feedback
    • shader object
  • ไดรเวอร์ปัจจุบันรองรับฟังก์ชันทั้งหมดที่จำเป็นสำหรับ DirectX หลายเวอร์ชัน

ชั้นการแปลงสำหรับรันเกม AAA

  • หากต้องการรันเกม AAA บนสภาพแวดล้อม Apple Silicon ต้องจัดการความต่างของหลายสภาพแวดล้อมพร้อมกัน
    • สภาพแวดล้อมเป้าหมายของเกม: DirectX, Windows, CPU x86, เพจ 4KB
    • ฮาร์ดแวร์เป้าหมายจริง: Apple Silicon ที่อิง Linux, Arm64, เพจ 16KB
  • การแปลงจาก DirectX ไป Vulkan และการรันจาก Windows ไป Linux รับหน้าที่โดย DXVK และ Wine ตามลำดับ
  • สำหรับการแปลงจาก x86 ไป Arm64 มีตัวเลือกเดิมอย่าง FEX-Emu หรือ Box64
  • อุปสรรคใหญ่ที่สุดคือ ความต่างของขนาดเพจ
    • FEX-Emu ต้องใช้เพจ 4KB
    • Box64 มีแฮ็กที่ใช้เพจ 16KB แต่ใช้กับ Wine ไม่ได้ จึงไม่ช่วยในกรณีนี้
    • macOS สามารถใช้เพจ 4KB สำหรับการจำลอง x86 ได้ แต่ต้องอาศัยการรองรับในเคอร์เนลที่แทรกแซงสูงมาก
    • Asahi Linux มีแพตช์ราว 1,000 รายการที่มุ่งเข้าสู่ mainline kernel อยู่แล้ว แนวทางเขียนตัวจัดการหน่วยความจำของ Linux ใหม่จึงไม่สมเหตุสมผล

การตั้งค่า VM ด้วย guest kernel 4KB

  • Linux ไม่รองรับขนาดเพจต่างชนิดกันระหว่างโปรเซสต่าง ๆ แต่รองรับได้ระหว่างเคอร์เนลต่าง ๆ และจัดการด้วย virtualization
  • KVM guest kernel สามารถมีขนาดเพจต่างจาก host kernel ได้
  • โครงสร้างที่ใช้คือใส่ FEX-Emu, Wine, DXVK, Honeykrisp, Steam และทั้งเกมลงใน virtual machine ที่รัน guest kernel 4KB
  • คาดว่าโอเวอร์เฮดของ CPU จะต่ำด้วย hardware virtualization และภาระจริงอยู่ที่ฝั่งอุปกรณ์ต่อพ่วง
  • Honeykrisp ไม่ได้รันผ่าน host kernel แต่รันใน guest ผ่าน virtgpu native contexts
    • งานสร้าง GPU command buffer ขั้นสุดท้ายทำใน guest
    • แทนที่แต่ละ Vulkan call จะข้ามขอบเขต virtual machine, command buffer ที่เสร็จแล้วจะถูกส่งไปยัง host
    • VirGL renderer บน host ส่งต่อสิ่งนี้ไปยัง GPU
  • Rosenzweig กล่าวว่าวิธีนี้ไม่ใช่ความเร็วแบบ native 100% แต่ เกิน 90% อย่างแน่นอน
  • โอเวอร์เฮดของ CPU และ GPU ทำงานแบบขนานกัน ต้นทุนจึงไม่สะสมทบกัน

เกมที่รันได้จริงและสถานะการเผยแพร่

  • การตั้งค่านี้รันเกมหลายเกมได้จริง
  • คอมโพเนนต์ที่เกี่ยวข้องถูก เผยแพร่ ในวันที่นำเสนอคือ 10 ตุลาคม
  • ผู้ใช้ Fedora Asahi Remix สามารถอัปเดตได้ทันทีเพื่อรับคอมโพเนนต์ดังกล่าว
  • ระหว่างการนำเสนอ การเปิด Steam ใช้เวลาพอสมควรเพราะ virtual machine และการจำลอง x86 จากนั้น Control รันบนระบบ M1 MAX ที่ 45fps

ข้อจำกัดด้านหน่วยความจำและ ray tracing

  • แม้บน Mac RAM 8GB เกมบางส่วนก็รันได้
    • Rosenzweig เล่น Castle Crashers บนระบบ 8GB ระหว่างงานคอนเฟอเรนซ์
    • Portal ก็ทำงานบนระบบ 8GB ได้
  • เกมระดับสูงมีแนวโน้มสูงว่าจะทำงานได้เฉพาะบนระบบที่มี 16GB ขึ้นไป
  • Rosenzweig หวังว่าเมื่อเวลาผ่านไป ทรัพยากรที่ต้องใช้จะลดลง
  • การรองรับ ray tracing ไม่ใช่ลำดับความสำคัญสูง
    • Control สามารถใช้ฟังก์ชันนี้ได้
    • ฮาร์ดแวร์ Apple รองรับ ray tracing ตั้งแต่ M3 เป็นต้นไปเท่านั้น
    • ไดรเวอร์ปัจจุบันสำหรับ GPU M1 และ M2
    • Rosenzweig มีแผนจะเริ่มงานกับ M3 ในไม่ช้า

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

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

 
GN⁺ 2024-11-01
ความคิดเห็นบน Hacker News

  • ความทุ่มเทที่จะทำให้การรองรับ M1/M2 สมบูรณ์จนถึงที่สุดนั้นน่านับถือจริงๆ
    มีโปรเจกต์มากเกินไปที่ถูกทิ้งทันทีที่ของเล่นใหม่แวววาวอย่าง ray tracing โผล่มา แต่งานแบบนี้แม้จะเจ็บปวดเพราะฮาร์ดแวร์มีเอกสารไม่พอ แต่เมื่อมันทำงานได้ก็ให้ผลตอบแทนคุ้มค่ามาก
    ผมก็ซื้อ M1 เพราะโปรเจกต์นี้กับงาน OpenGL+ES ของ Alyssa และบูตแค่ Asahi Linux เท่านั้น

    • ในคอมเมนต์ตอนเปิดตัว M4 MacBook สังเกตได้ว่ามีคนจำนวนมากพอใจกับโน้ตบุ๊ก M1 และก็มีหลายคนที่ใช้ MacBook กันเกือบ 10 ปี
      อุปกรณ์แบบนี้ถูกสร้างมาให้อยู่ได้นาน และการสนับสนุนระยะยาวทั้งจาก Apple เองกับชุมชน Linux ก็น่าชื่นชม
      เพราะเป็นโอเพนซอร์ส Apple เองก็น่าจะกำลังดูอยู่ และบทความยังพูดถึงงานที่เลี่ยงข้อจำกัดของฟีเจอร์ที่ขาดไปในชิปด้วย
    • เห็นด้วยกับคำว่า “ผลตอบแทนเมื่อมันทำงานได้”
      ผมเขียนโค้ดมากว่า 20 ปีแล้ว แต่ทั้งช่วงเวลาที่มีความสุขที่สุดและหดหู่ที่สุดในอาชีพ ล้วนมาจาก โปรเจกต์ฮาร์ดแวร์ ที่ผมเข้าไปร่วมแค่ 4 เดือนพอดี
    • ในบทความก็พูดว่า “พูดตรงๆ ผมคิดว่า ray tracing เป็นฟีเจอร์หลอกตานิดหน่อย” และเมื่อรวมกับประเด็นที่ว่าโปรเจกต์ถูกทิ้งเมื่อมีของเล่นใหม่ออกมา ผมเห็นด้วยเต็มที่ทั้งสองเรื่อง

  • วิธีของ Alyssa ที่รันทุกอย่างใน virtual machine เพื่อแก้ความต่างของ ขนาดเพจ 4KB กับ 16KB เป็นแฮ็กที่ฉลาด แต่ก็รู้สึกเหมือนเป็นคอขวดด้านประสิทธิภาพที่อาจเกิดขึ้นได้
    อยากรู้ว่าวิธีเลี่ยงแบบนี้มีความหมายอย่างไรในระยะยาว
    เรามาถึงจุดที่ความซับซ้อนในการอุดช่องว่างของฮาร์ดแวร์กรรมสิทธิ์ซึ่งถูกออกแบบมาให้เป็นระบบนิเวศปิด มีมากกว่าประโยชน์ที่ได้แล้วหรือเปล่า
    การที่ Control รันได้ 45fps บน M1 MAX ด้วยไดรเวอร์โอเพนซอร์สเป็นเรื่องน่ายินดี แต่ก็สงสัยว่าชุมชนควรต้องทุ่มทรัพยากรจำนวนมากต่อไปเพื่อเปิดระบบปิดให้มากขึ้น หรือควรผลักดันมาตรฐานฮาร์ดแวร์ที่เปิดกว่านี้แทน
    Apple กำลังสร้างอุปสรรคที่ไม่จำเป็นให้กับนักพัฒนาด้วยข้อจำกัดของ GPU ที่ทำให้ฟีเจอร์มาตรฐานอย่าง tessellation shader ทำได้ยาก และด้วยขนาดเพจที่ไม่เป็นมาตรฐาน ระบบนิเวศปิดแบบนี้ไม่เพียงทำให้ผู้ร่วมพัฒนาโอเพนซอร์สลำบาก แต่ยังกดทับนวัตกรรมที่จะเป็นประโยชน์ต่อผู้ใช้ทุกคนด้วย

    • Apple ออกแบบฮาร์ดแวร์ให้ตรงกับเป้าหมายของตัวเอง และเพื่อเป้าหมายของตัวเองเท่านั้น
      เห็นได้ชัดว่าสิ่งนี้ค้ำจุนโมเดลธุรกิจแบบปิด และในทางปฏิบัติก็ได้ผลดีมากสำหรับ Apple
      พวกเขาสร้างฮาร์ดแวร์ที่ยอดเยี่ยม และแม้ซอฟต์แวร์ช่วงหลังจะค่อนข้างไม่นิ่ง ผู้ใช้ทั่วไปก็มักได้ประสบการณ์ที่ดีโดยรวมจากชุดฮาร์ดแวร์กับซอฟต์แวร์
      ดังนั้นการที่ Apple ออกแบบฮาร์ดแวร์แบบทุกวันนี้ไม่ได้หมายความว่ากำลังวาง “อุปสรรคที่ไม่จำเป็น” ให้กับนักพัฒนา แต่เป็นแค่การโฟกัสกับการออกแบบฮาร์ดแวร์ให้ตรงกับความต้องการของตัวเอง
      อีกอย่าง ถ้าฮาร์ดแวร์ไม่ได้ยอดเยี่ยมขนาดนี้ ก็คงไม่มีคนสนใจมากขนาดนี้ที่จะเอาไปใช้ในแบบที่ Apple ไม่ได้ตั้งใจ
    • ผมสงสัยจริงๆ ว่าอุปสรรคเหล่านั้นมี เหตุผลทางเทคนิค รองรับหรือไม่
      การไม่สนใจมาตรฐานแล้วสร้างล้อขึ้นมาใหม่ให้ดีกว่า กับการจงใจเบี่ยงออกจากมาตรฐานเพื่อขัดขวางความเข้ากันได้นั้นต่างกันมากทีเดียว
      ประเด็นสำคัญคือพวกเขาไม่ใช้ทรัพยากรเพื่อรักษาพฤติกรรมตามมาตรฐาน หรือใช้ทรัพยากรอย่างจริงจังเพื่อเบี่ยงออกจากมาตรฐานกันแน่ และถ้าเป็นอย่างแรก ส่วนตัวผมก็ไม่คิดว่าเป็นเรื่องควรตำหนิ
    • ในการประกาศช่วงแรก Alyssa ยก overhead ด้านหน่วยความจำของ virtual machine เป็นเหตุผลว่าทำไมความต้องการขั้นต่ำในการ emulation เกม Windows ส่วนใหญ่ถึงกลายเป็น RAM 16GB
    • จากมุมมองของ Apple ก็เหมือนมีนักพัฒนาที่มีแรงจูงใจมาช่วยทำงานยากๆ แทน
      ภายในระบบนิเวศนี้ สิ่งที่ Apple น่าจะสนใจหลักๆ คือความเข้ากันได้ของแอปเนทีฟกับ ประสบการณ์ AI inference ในระดับใกล้เคียงกัน ซึ่งทั้งสองอย่างก็ดูเหมือนบางครั้งจะถูกแก้ด้วยความพยายามร่วมกัน
      นอกเหนือจากนั้น พวกเขาน่าจะชอบล็อกให้มากที่สุดเท่าที่ทำได้ และน่าเสียดายที่ชุมชนมักถูกดึงดูดด้วยความน่าใช้โดยรวมมากกว่า initiative แบบเปิดที่ดี
    • “จะเปิดระบบปิดให้มากขึ้น หรือผลักดันมาตรฐานฮาร์ดแวร์แบบเปิด” เป็น ทางเลือกเทียม
      ก็ทำทั้งสองอย่างได้

  • ตอนแรกผมกำลังจะบอกว่า Alyssa ควรทำงานที่ Valve เพื่อช่วยให้ Steam รันบน Linux ของ Mac ได้ แต่ดูเหมือนว่าเป็นอย่างนั้นอยู่แล้ว [1]
    [1] https://en.wikipedia.org/wiki/Alyssa_Rosenzweig#Career

    • ดีเลย
      ทำให้เกิดคำถามที่น่าสนใจมากว่า Valve กำลังวางแผนอะไรตรงนี้
      แม้จะยาก แต่การทำให้ Steam/Proton รันบน Mac นั้นสมเหตุสมผลมากสำหรับ Valve และถ้าผู้คนบูต Linux บน Mac เพื่อเล่นเกม Apple ก็คงหงุดหงิดไม่น้อย

  • งานของ Alyssa R และ Asahi Lina ยอดเยี่ยมมาก
    เพียงแต่ว่าถ้าไม่คุ้นกับโค้ดไดรเวอร์ เนื้อหาส่วนใหญ่จะเข้าใจยากจริงๆ และฝั่งฮาร์ดแวร์ก็มีส่วนที่แปลกเฉพาะตัวเยอะมาก จนอยากให้การเขียนโค้ดแบบนี้ทำได้ง่ายกว่านี้มาก
    มุกแบบ old-school อย่างชุดแม่มดก็ดูเพลินทีเดียว

    • ช่วงดูงานนำเสนอล่าสุด เหมือนเห็นเขาโบกไม้กายสิทธิ์เพื่อเลื่อนสไลด์
      เลยสงสัยว่ามีฮาร์ดแวร์ที่เป็นที่รู้จักสำหรับทำสิ่งนี้หรือเปล่า
      ลองค้นหาแล้ว แต่หาผลลัพธ์ที่ต้องการได้ยากท่ามกลางบล็อกสแปมเกี่ยวกับ PowerPoint และ AI ของ Google ก็ไม่ช่วยอะไร
    • งานที่พวกเขาทำนั้นแทบจะ เกือบเป็นเวทมนตร์ อยู่แล้ว บางทีมันอาจไม่ใช่ชุดคอสตูมก็ได้

  • สงสัยว่ามีใครอีกไหมที่ประหลาดใจกับข้อเท็จจริงที่ว่าฮาร์ดแวร์ขาดหลายอย่างขนาดนี้ และมีหลายส่วนมากที่ถูก emulation

    • กราฟิกส์ไปป์ไลน์ของ GPU สมัยใหม่โดยรวมคือการวางเลเยอร์ระดับต่ำบางๆ แบบ Vulkan/Metal ไว้บน สถาปัตยกรรมการคำนวณขนานขนาดใหญ่แนว CUDA
      โดยแท้จริงแล้วแทบทั้งหมดถือเป็น emulation ได้
      หนึ่งในเหตุผลที่ผู้ผลิต GPU ไม่ค่อยอยากเปิดซอร์สไดรเวอร์ ก็เพราะส่วนสำคัญของความลับอยู่ในซอฟต์แวร์ไดรเวอร์ที่ทำงานบนสถาปัตยกรรมการคำนวณขนานขนาดใหญ่นั่นเอง
    • สิ่งที่ถูก emulation ส่วนใหญ่เป็น ฟีเจอร์ legacy ที่แทบไม่ใช้หรือไม่ใช้เลยในซอฟต์แวร์สมัยใหม่ ดังนั้น overhead ของ emulation เพื่อความเข้ากันได้ย้อนหลังจึงไม่ได้ร้ายแรง
      geometry shader ถูกมองอย่างกว้างขวางว่าเป็นความผิดพลาดที่ไม่ควรถูกทำให้เป็นมาตรฐานตั้งแต่แรก และ Metal ก็ไม่เคยรองรับเลย จึงน่าจะโผล่มาแค่ในโค้ด OpenGL เก่าบน macOS เท่านั้น เลยยากที่จะโทษ Apple ที่ไม่รองรับสิ่งนี้ในฮาร์ดแวร์
      https://x.com/pointinpolygon/status/1270695113967181827
    • ไม่แน่ใจว่าสิ่งนี้ต่างจาก GPU สาย mobile-derived อื่นๆ มากขนาดนั้นจริงหรือเปล่า

  • Alyssa เก่งมาก
    ผมจำบทความแรกของเธอเกี่ยวกับงาน GPU ได้ แล้วพอรู้ทีหลังว่าเธออายุแค่ 17 ปี ตอนนั้นรู้สึกเหมือนหัวจะระเบิด
    แค่มีใครสักคนทำเรื่องแบบนั้นได้ก็น่าทึ่งแล้ว ยิ่งเป็นวัยรุ่นที่ทำได้ยิ่งช็อกจริง ๆ

  • ถ้าการนำ OpenGL และ Vulkan รุ่นล่าสุดมาสู่ Apple Silicon ยังไงก็เป็นไปไม่ได้หากไม่มีเลเยอร์อีมูเลชัน ตามทฤษฎีแล้วจะสร้าง Metal API แบบเนทีฟ สำหรับ Linux ได้ไหม
    หรือว่า Metal ฝังลึกอยู่ใน macOS SDK เกินไป
    MoltenVK เองก็กำลังพยายามแก้ปัญหาแบบเดียวกับที่ Alyssa พูดถึงในงานนำเสนอ [1, คอมเมนต์สุดท้ายในอิชชูเป็นของ Alyssa]
    [1] https://github.com/KhronosGroup/MoltenVK/issues/1524

    • ไม่มีอะไรขวางไม่ให้ Apple รองรับ Vulkan แบบเนทีฟบน macOS
      นี่แทบจะเป็นข้อสรุปจากการนำเสนอของ Alyssa Rosenzweig เลย
      Apple รู้เอกสารภายในอยู่แล้ว จึงอยู่ในตำแหน่งที่ดีที่สุดในการสร้าง implementation ระดับต่ำที่ดีกว่า
      อุปสรรคหลักตอนนี้คือ จุดยืนแบบดื้อดึง ที่ว่าเส้นทางที่รองรับอย่างเป็นทางการมีแค่การพอร์ตไป Metal เท่านั้น
      ถ้า Valve งัดวิธีแบบเวทมนตร์เพื่อรันเกม AAA บน Mac ได้โดยไม่ต้องมีการสนับสนุนจาก Apple ก็น่าจะกลายเป็นสถานการณ์ที่น่าสนใจ และอาจทำให้ Apple ต้องทบทวนแนวทางใหม่ ถ้าไม่อยากถูกบีบให้จนมุมบนแพลตฟอร์มของตัวเอง
    • ดูเหมือนไม่มีเหตุผลที่ทำไม่ได้
      ก็มี implementation ของ DirectX สำหรับ Linux อยู่ และ Proton ก็ทำงานในแนวนั้น
      เพียงแต่ประเด็นคือจะทำ API นั้นเป็นเลเยอร์บน Vulkan, จัดการทั้งหมดฝั่งไคลเอนต์แบบ MoltenVK หรือ dxvk, หรือผสานเข้าไปใน Mesa ให้ลึกกว่านั้น
      แบบแรกน่าจะง่ายกว่าแน่นอนสำหรับการเริ่มต้น

  • พอเห็นบทความชื่อแบบนี้ ผมถูกฝึกให้คาดหวังไปแล้วว่าจะเป็นเนื้อหาแนว “หยุดสนับสนุนแล้วถูก acqui-hire” อะไรทำนองนั้น

  • Alyssa Rosenzweig สมควรได้ Turing Award

  • ผมสงสัยลิงก์แบบ /SubscriberLink/ นี้มาตลอด
    การแชร์ถือว่าไม่ถูกจริยธรรมหรือเปล่า

    • ใน LWN FAQ ระบุว่าสถานที่ที่โพสต์ลิงก์สำหรับสมาชิกได้คือแทบทุกที่
      ไม่ว่าจะเป็นอีเมลส่วนตัว ข้อความในเมลลิงลิสต์ของโปรเจกต์ หรือบล็อกโพสต์ ล้วนเหมาะสม และบอกว่ายินดีให้แชร์ตราบใดที่ไม่ได้ใช้เป็นวิธีเลี่ยงความพยายามในการหาสมาชิก
    • คนของ LWN เคยพูดไว้ที่นี่เมื่อนานมาแล้วว่าแชร์ได้ไม่เป็นไร
      แต่ก็ขออย่างสุภาพว่าอย่าเผยแพร่กันมากเกินไป เพราะต้องดูแลไซต์ นักเขียน และบรรณาธิการ ซึ่งแหล่งทุนเท่าที่ผมเข้าใจคือค่าสมาชิกเท่านั้น
      ค่าสมาชิก LWN อยู่ในระดับที่จ่ายได้พอสมควร และช่วยสนับสนุนงานรายงานเชิงเทคนิคเชิงลึกที่ดีที่สุดเกี่ยวกับ Linux และหัวข้อที่เกี่ยวข้อง
      ผมไม่ได้เกี่ยวข้องกับ LWN แค่เป็นสมาชิกที่พอใจ และคิดว่าความรู้ที่ได้จากบทความของ LWN ก็มีส่วนช่วยให้ผมประสบความสำเร็จในอาชีพด้วย
    • ผมว่า LWN น่าจะดีใจมากที่ HN ส่งทราฟฟิกมหาศาลไปยังไซต์ LWN เป็นประจำ
      ก่อนที่ผู้คนจะสมัครสมาชิกได้ ก็ต้องรู้จัก การมีอยู่ของ LWN ก่อน
    • จุดประสงค์ของลิงก์แบบนี้คือการแชร์
      ดู FAQ ได้: https://lwn.net/op/FAQ.lwn#slinks
      paywall ของ LWN มีเอกลักษณ์ตรงที่คอนเทนต์ทั้งหมดจะเปิดให้อ่านฟรีหลังผ่านไปหนึ่งสัปดาห์
      ลิงก์สำหรับสมาชิกมีไว้เพื่อกระตุ้นให้สมัครสมาชิกถ้าพอมีศักยภาพ
    • ข้อความแจ้งระบุว่า “คอนเทนต์สำหรับสมาชิกต่อไปนี้มีสมาชิก LWN ทำให้คุณดูได้”
      ผมอาจเข้าใจผิดก็ได้ แต่ฟังดูเหมือนมีการจ่ายเงินเพื่อเปิดเผยคอนเทนต์ที่ก่อนหน้านี้เป็นแบบเสียเงิน อาจเป็นรายบทความ
      สงสัยว่ามีใครรู้ไหมว่าจริง ๆ แล้วเป็นแบบนั้นหรือเปล่า