ไดรเวอร์ GPU M1 ตัวแรกที่ได้รับการรับรองความสอดคล้อง OpenGL ES

 (rosenzweig.io)
1 คะแนน โดย GN⁺ 2023-08-23 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • มีไดรเวอร์สำหรับ Linux ที่ทำให้ แอปพลิเคชัน OpenGL ES 3.1 ทำงานบน GPU ตระกูล M1·M2 ได้ตามมาตรฐาน
  • ไดรเวอร์ฟรีและโอเพนซอร์สของ Asahi Linux ที่พัฒนาด้วยวิศวกรรมย้อนกลับ เป็น implementation ของ OpenGL ES 3.1 เพียงหนึ่งเดียวบนฮาร์ดแวร์กราฟิก M1·M2 ที่ผ่าน Khronos conformance tests
  • การรับรองต้องผ่านการทดสอบอย่างเป็นทางการ ส่งให้ Khronos และผ่าน ระยะเวลาตรวจสอบ 30 วัน โดยมีรายการที่ลงทะเบียนคือ M1, M1 Pro/Max/Ultra, M2, M2 Pro/Max
  • OpenGL ES 3.1 เป็นการอัปเดตจากการรองรับ OpenGL ES 3.0·OpenGL 3.1 แบบทดลองเมื่อเดือนมิถุนายน และเพิ่ม compute shader กับ atomic operation สำหรับ image
  • บน M1 ไม่มีคำสั่งเฉพาะสำหรับ atomic operation บน image จึงเลี่ยงด้วยการคำนวณ address และภายหลังพบ คำสั่ง bit interleave ทำให้ลดจาก 10 คำสั่งเหลือ 1 คำสั่ง

การรับรองความสอดคล้อง OpenGL ES 3.1 สำหรับ M1·M2

  • มีไดรเวอร์ที่ได้รับ การรับรองความสอดคล้อง OpenGL ES 3.1 สำหรับ GPU ตระกูล M1·M2 แล้ว
    • เข้ากันได้กับแอปพลิเคชัน OpenGL ES 3.1
    • ใช้งานได้ผ่านการติดตั้ง Linux
  • ผู้ใช้ Asahi Linux เดิมสามารถรับไดรเวอร์ล่าสุดได้ด้วยคำสั่งอัปเกรดตามแต่ละดิสทริบิวชัน
    • Fedora: dnf upgrade
    • Arch: pacman -Syu
  • ไดรเวอร์กราฟิกฟรีและโอเพนซอร์สที่พัฒนาด้วยวิศวกรรมย้อนกลับเผยแพร่อยู่ที่ asahi/mesa
  • ไดรเวอร์นี้เป็น implementation ที่ได้รับการรับรองความสอดคล้อง OpenGL ES 3.1 เพียงหนึ่งเดียวในโลกบนฮาร์ดแวร์กราฟิกตระกูล M1·M2
    • พิสูจน์ความถูกต้องด้วยการผ่านการทดสอบหลายหมื่นรายการ
    • ได้รับการยอมรับจากองค์กรกำหนดมาตรฐานในอุตสาหกรรม

กระบวนการของ Khronos และตระกูลชิปที่ลงทะเบียน

  • หากต้องการได้รับการรับรองความสอดคล้อง implementation จะต้องผ่าน conformance test suite อย่างเป็นทางการ
    • test suite ถูกออกแบบมาเพื่อตรวจสอบทุกฟีเจอร์ตามสเปก
    • ผลการทดสอบจะถูกส่งให้องค์กรมาตรฐาน Khronos
    • หากไม่มีปัญหาในช่วง ระยะเวลาตรวจสอบ 30 วัน ก็จะกลายเป็น implementation ที่ได้รับการรับรองความสอดคล้อง
  • บนเว็บไซต์ Khronos มีไดรเวอร์ต่อไปนี้ลงทะเบียนเป็น implementation ที่ได้รับการรับรองความสอดคล้อง
  • ความสำเร็จครั้งนี้ไม่ได้หยุดอยู่แค่ OpenGL ES
    • ถือเป็น implementation ที่ได้รับการรับรองความสอดคล้อง ครั้งแรกสำหรับมาตรฐานกราฟิกทั้งหมดบน M1

ช่องว่างระหว่างไดรเวอร์ผู้ผลิตกับ API มาตรฐาน

  • ไดรเวอร์ M1 ของผู้ผลิตไม่ได้รับ การรับรองความสอดคล้อง สำหรับ API กราฟิกมาตรฐานใด ๆ ไม่ว่าจะเป็น Vulkan, OpenGL หรือ OpenGL ES
  • ในสภาพแวดล้อม M1·M2 ที่ไม่ได้ใช้ Linux จึงไม่มีการรับประกันว่าแอปพลิเคชันที่อิงมาตรฐานจะทำงานได้
  • ในกรณีของ Vulkan นั้น MoltenVK วางเลเยอร์ Vulkan บางส่วนไว้เหนือไดรเวอร์ proprietary
    • ไดรเวอร์ proprietary ดังกล่าวขาดฟีเจอร์หลักบางอย่าง
    • แอปพลิเคชัน Vulkan ที่ถูกต้องตามสเปกอาจทำงานเสียได้
    • กลายเป็นอุปสรรคทั้งต่อผู้พัฒนาและผู้ใช้ที่ยังไม่ได้เปลี่ยนคอมพิวเตอร์ M1·M2 ไปใช้ Linux
  • การพัฒนาไดรเวอร์ของ Asahi Linux มีเป้าหมายให้ซอฟต์แวร์มาตรฐานทำงานได้โดยไม่ต้องแฮ็กหรือพอร์ตเฉพาะสำหรับ M1
    • ไม่พอใจกับไดรเวอร์ proprietary, API proprietary และการปฏิเสธที่จะทำ implementation ตามมาตรฐาน
    • มองว่า implementation มาตรฐานเปิด ที่สอดคล้องกับสเปกคือทิศทางที่พึงประสงค์ของ ecosystem

ฟีเจอร์หลักที่เพิ่มใน OpenGL ES 3.1

  • OpenGL ES 3.1 อัปเดตจากการรองรับ OpenGL ES 3.0 และ OpenGL 3.1 แบบทดลองที่เปิดให้ใช้เมื่อเดือนมิถุนายน
  • ฟีเจอร์สำคัญที่เพิ่มเข้ามาคือ compute shader
    • มักใช้เพื่อเร่งการคำนวณทั่วไปภายในแอปพลิเคชันกราฟิก
    • เกม 3D สามารถรันการจำลองฟิสิกส์ใน compute shader ได้
    • หากนำผลการจำลองไปใช้ในการเรนเดอร์ได้โดยตรง จะช่วยลดการหยุดชะงักที่เกิดจากการซิงโครไนซ์ระหว่าง GPU กับการจำลองฟิสิกส์บน CPU
    • ส่งผลให้เกมอาจทำงานได้เร็วขึ้น

เหตุผลที่ต้องใช้ atomic operation บน image

  • OpenGL ES เวอร์ชันก่อนหน้าอนุญาตให้แอปพลิเคชันอ่าน image เพื่อแสดงผลบนหน้าจอได้
  • ES 3.1 อนุญาตให้แอปพลิเคชัน เขียนลง image ได้ โดยมักทำใน compute shader
    • ลดข้อจำกัดที่ต้องปรับอัลกอริทึมประมวลผลภาพให้เข้ากับ fixed-function 3D pipeline
  • GPU เป็นสถาปัตยกรรมขนานขนาดใหญ่ที่รันเธรดได้พร้อมกันนับพัน
    • หากสองเธรดเขียนไปยังตำแหน่งเดียวกัน ผลลัพธ์จะแตกต่างไปตามลำดับการทำงาน
    • สถานการณ์นี้คือ race condition
  • การเข้าถึงหน่วยความจำแบบ atomic เป็นวิธีพื้นฐานในการจัดการ race condition
    • ฮาร์ดแวร์พิเศษใน memory subsystem รับประกันผลลัพธ์ที่สอดคล้องกันสำหรับ operation ที่เลือกไว้ โดยไม่ขึ้นกับลำดับของเธรด
    • ฮาร์ดแวร์กราฟิกสมัยใหม่รองรับ atomic operation หลายแบบ เช่น การบวก
  • ส่วนขยาย OpenGL ES OES_shader_image_atomic เพิ่ม atomic operation สำหรับพิกเซลของ image
    • ส่วนขยายนี้เป็นข้อบังคับใน ES 3.2
    • ตัวอย่างเช่น compute shader สามารถเพิ่มค่าของพิกเซล (10, 20) แบบ atomic ได้

วิธี implement atomic operation บน image ใน M1

  • GPU อื่น ๆ มีคำสั่งเฉพาะสำหรับ atomic operation บน image ทำให้การ implement ในไดรเวอร์เรียบง่าย
  • M1 ไม่มี คำสั่งฮาร์ดแวร์เฉพาะสำหรับ atomic operation บน image
    • มี atomic operation ที่ไม่ใช่ image
    • มีฟีเจอร์ image แบบไม่ atomic
  • ดังนั้นจึงไม่ได้ทำ atomic operation กับพิกเซลโดยตรง แต่คำนวณ address ของพิกเซลในหน่วยความจำ แล้วทำ atomic operation ทั่วไปกับ address นั้น
  • หาก image ถูกจัดวางในหน่วยความจำแบบ linear การคำนวณ address จะเรียบง่าย
    • นำพิกัด Y คูณกับ stride ซึ่งเป็นจำนวนไบต์ต่อแถว
    • นำพิกัด X คูณกับจำนวนไบต์ต่อพิกเซล
    • บวกสองค่านี้เพื่อหา byte offset จากพิกเซลแรก
    • นำ offset ไปบวกกับ address ของพิกเซลแรกเพื่อได้ address สุดท้าย
  • โดยปกติ image จริงไม่ได้ถูกจัดวางแบบ linear
    • ฮาร์ดแวร์กราฟิกสมัยใหม่ interleave พิกัด X·Y เพื่อเพิ่มประสิทธิภาพ cache
    • การจัดวางพิกเซลในหน่วยความจำไม่ได้เป็นรายแถว แต่เป็นไปตาม เส้นโค้งที่ใกล้เคียงเกลียว

การปรับแต่ง bit interleave และการค้นหาคำสั่งที่ซ่อนอยู่

  • เมื่อ interleave พิกัด X·Y วิธี mask และ shift ทีละบิตนั้นไม่มีประสิทธิภาพ
  • อัลกอริทึมจัดการบิต ที่เป็นที่รู้จักกันดีจะผสมกลุ่มบิตเพื่อทำให้ปัญหาเป็นแบบขนาน
    • หาก implement อัลกอริทึมนี้ในโค้ด shader จะช่วยเพิ่มประสิทธิภาพ
  • ในทางปฏิบัติจะ interleave เฉพาะบิตล่างไม่เกิน 7 บิตของแต่ละพิกัด
    • สามารถใส่พิกัด X·Y ไว้ใน 16 บิตล่าง·บนของรีจิสเตอร์ 32 บิต แล้วประมวลผลพร้อมกันด้วยคำสั่ง 32 บิตได้
    • ลดจำนวนคำสั่งลงได้ครึ่งหนึ่ง
    • ยังใช้ประโยชน์จากคำสั่งผสาน shift-and-add ของ GPU ด้วย
  • เมื่อรวมเทคนิคเหล่านี้ ทำให้ทำ interleave ได้ด้วยคำสั่ง assembly ของ GPU M1 จำนวน 10 คำสั่ง
  • หลังจากนั้นจึงพิจารณาความเป็นไปได้ของ คำสั่ง bit interleave โดยเฉพาะ
    • PowerVR มีคำสั่ง shuffle shfl
    • GPU M1 มีองค์ประกอบบางส่วนที่นำมาจาก PowerVR จึงพิจารณาว่าอาจมีคำสั่งที่คล้ายกัน
    • คอมไพเลอร์ proprietary ไม่ได้ใช้คำสั่งดังกล่าวเมื่อคอมไพล์ shader ทดสอบ จึงทำ reverse engineering จากการสังเกตผลการคอมไพล์เพียงอย่างเดียวได้ยาก

คำสั่ง interleave ที่ยืนยันด้วยการคาดเดาและตรวจสอบ

  • Dougall Johnson คาดเดาตัวเลือกจาก instruction encoding ที่รู้จักอยู่แล้ว
  • คำสั่งกลับบิตมีฟิลด์ 2 บิตสำหรับระบุ operation และค่าคือ 01
    • คำสั่งนับจำนวนบิตที่ตั้งค่าไว้คือ 10
    • คำสั่งค้นหาบิตที่ตั้งค่าไว้ตัวแรกคือ 11
    • คำสั่งจัดการบิตที่ซับซ้อนและรู้จักอยู่แล้วใช้สามค่านี้
  • ค่าที่เหลือคือ 00 ซึ่งเป็นค่าที่ไม่เคยสังเกตพบ
    • หากมีคำสั่ง interleave อยู่ ก็พิจารณาความเป็นไปได้ว่าอาจคล้ายกับคำสั่งกลับบิต แต่มี opcode เป็น 00
  • คำสั่งที่รู้จักทั้งสามมี input source เพียงตัวเดียว แต่คำสั่ง interleave ต้องใช้สอง source
    • โดยปกติคำสั่งของ GPU M1 จะ encode ตำแหน่ง source อย่างสม่ำเสมอ
    • ในคำสั่ง arithmetic แบบสอง source มีพื้นที่ว่างในตำแหน่งที่ source ที่สองควรอยู่ จึงสันนิษฐานว่าตำแหน่งนั้นคือ source ที่สอง
  • การตรวจสอบทำโดยแก้ไขคอมไพเลอร์ให้แทนที่ integer operation แบบ 2 source เช่น การคูณ ด้วย encoding ของ interleave ที่คาดเดาไว้
    • ใช้ operation ดังกล่าวใน compute shader
    • shader ทดสอบจะตรวจสอบว่าแต่ละ input ที่เป็นไปได้ทำให้คำสั่งไม่รู้จักนั้นคืนผลลัพธ์แบบ interleave หรือไม่
    • เนื่องจากคำสั่งรับ source แบบ 16 บิตสองตัว จึงมี input ประมาณ 4 พันล้านแบบ
    • GPU M1 ใช้การรองรับ compute ใหม่ของไดรเวอร์ตรวจสอบ input ทั้งหมดได้ภายในเวลาน้อยกว่า 1 วินาที
  • สุดท้ายจึงแทนที่ assembly แบบ vectorized จำนวน 10 คำสั่งด้วย คำสั่ง interleave 1 คำสั่ง
    • วิธีนี้รวดเร็วและผ่าน conformance tests ด้วย

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

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

 
GN⁺ 2023-08-23
ความคิดเห็นบน Hacker News

  • ผมสงสัยว่าเมื่อ Apple ร่วมมือกับ nVidia, Adobe, Autodesk, Microsoft และรายอื่น ๆ ในเรื่องฟอร์แมตฉาก OpenUSD สำหรับเรนเดอร์/แอนิเมชัน/CAD/3D แล้ว การรองรับ OpenGL·Vulkan จะดีขึ้นหรือไม่
    หากแก่นของ OpenUSD คือ “ฟอร์แมตไฟล์เดียวที่เรนเดอร์ได้สม่ำเสมอทุกที่” ก็มีความเป็นไปได้ที่ Apple จะใช้สิ่งนี้เป็นเครื่องมือดึงผู้ผลิตซอฟต์แวร์ 3D ให้เข้ามาสู่ macOS มากขึ้น
    ต่อจากนี้ดูเหมือนมีสองทาง คือ Apple จะทำตามมาตรฐาน OpenGL/Vulkan เดิมที่มีแรงหนุนในไปป์ไลน์การผลิตภาพยนตร์·เกม หรือในทางกลับกันจะผลักดัน Metal ให้หนักขึ้นเพื่อพาโลกไปสู่ Metal + macOS
    ใจผมอยากให้เป็นอย่างแรก แต่สัญชาตญาณบอกว่า Apple น่าจะผลักดันอย่างหลังเต็มกำลัง และไม่ใช่แค่ Apple เท่านั้น nVidia, Autodesk, Adobe, Microsoft ก็เป็นพวกที่ไม่ค่อยชอบมาตรฐานที่ตนเองควบคุมไม่ได้เช่นกัน

    • ผมอยากเติมนัยประมาณว่า “Apple ชอบ มาตรฐานเปิด ตอนที่ตัวเองยังอ่อนแอ”
      iMac และ OS X ยุคแรก ๆ ชูมาตรฐานอย่าง USB, JPEG, MPEG, mp3, PostScript, TCP/IP ในตัว, .rtf ไว้อย่างมาก และ Jobs ก็เน้นย้ำเรื่องนี้
      หลังจากนั้นเมื่อฟื้นตัวจากปากเหว Apple ก็กลับมาเริ่ม “เพิ่มมูลค่า” อีกครั้ง และ iPhone ตอนแรกก็ถูกเน้นว่าเป็นอุปกรณ์ HTML แทน Flash ที่เป็นกรรมสิทธิ์และแย่มาก หรือ “HTML บนมือถือ” ที่ยังไม่สุกงอม
      แม้ตอนนี้ ในพื้นที่ที่อำนาจครองตลาดยังอ่อน Apple ก็ยังรองรับมาตรฐานที่ตนเองควบคุมไม่ได้ เช่น H.264, Matter/Thread
    • Apple รองรับมาตรฐานเปิดหลายอย่าง แต่ดูเหมือนจะพูดให้แม่นกว่าว่า “ไม่อยาก พึ่งพา มาตรฐานที่ตนเองควบคุมไม่ได้”
      เพราะ Apple ผสานฮาร์ดแวร์กับซอฟต์แวร์อย่างแน่นหนาเพื่อสร้างประสบการณ์ผู้ใช้ตามที่ตั้งใจ จึงพอเข้าใจได้ว่าต้องการนำมาตรฐานที่ควบคุมได้ในระดับหนึ่งมาใช้งาน เพื่อไม่ให้ประสบการณ์นั้นถูกผู้อื่นกำหนด
      แม้แต่มาตรฐานอุตสาหกรรมอย่าง USB-C ที่ทิศทางยังไม่ตายตัว หากขยับก่อนก็อาจมีอิทธิพลต่อทิศทางได้ Apple จึงนำมาใช้ในบางกรณี
    • OpenUSD เป็นวิธีรวบรวมและระบุข้อมูลที่จะใช้เรนเดอร์ แยกต่างหากจากว่าแอปจะใช้ API ใดเพื่อเร่งการเรนเดอร์
      ส่วนใหญ่ เช่น Adobe, Autodesk, Blender รองรับแบ็กเอนด์ที่ต่างกันตามระบบปฏิบัติการอยู่แล้ว และบน macOS ก็รวม Metal ด้วย
    • ผมไม่คิดว่า Apple จะกลับไปใช้ OpenGL
      OpenGL เก่าเกินไป การใช้ไดรเวอร์ดี ๆ ก็แทบเหมือนฝันร้าย และแม้แต่การเขียนโค้ดแอปพลิเคชันให้ประสิทธิภาพดีก็ยังยาก จึงไม่ได้รู้สึกเสียดายนัก
      แต่ถ้าถามก็คงอยากให้ผลักดัน Vulkan แทนการสร้าง Metal มากกว่า แม้นอก Linux แล้ว Vulkan โดยทั่วไปจะเกือบเป็นพลเมืองชั้นสอง แต่ก็ยังเป็นพลเมืองชั้นสองที่ค่อนข้างดีพอจะตั้งเป็นเป้าหมายได้
      ในมุมมองเกมหรือการรองรับ Steam เกมจำนวนมากปล่อยให้เอนจินจัดการ API และถ้าเป็นทีมที่มีทรัพยากรพอจะจัดการ API เอง ตราบใดที่ไม่ได้ใช้ฟีเจอร์ล้ำหน้ามาก ๆ MoltenVK ก็น่าจะพอใช้ได้
      ผมใช้ OpenGL มามากตลอดชีวิตเพื่อทำข้ามแพลตฟอร์ม แต่มันเป็น API ที่แย่มากจริง ๆ เพราะ global state, ฟังก์ชันที่ไม่ควรใช้, กับดักต่าง ๆ, เฮดเดอร์ส่วนขยายขนาดมหึมา และการดีบักที่ยาก ส่วน Vulkan แม้จะยืดยาว แต่ในหลายแง่กลับง่ายกว่า
    • สถานการณ์ของ Metal/Vulkan/OpenGL น่าเสียดาย และแรงจูงใจของ Apple ก็เข้าใจได้ไม่ชัดนัก
      แต่ Mac ที่ผมใช้อยู่ตอนนี้เชื่อมต่อกับอุปกรณ์ต่อพ่วงหลายอย่างและจอภาพขนาดใหญ่ผ่าน พอร์ต USB-C เพียงอย่างเดียว โดยใช้โปรโตคอลมาตรฐาน
      โดยรวมแล้ว Apple ดูเหมือนจะชอบมาตรฐานเปิดเมื่อมาตรฐานนั้นดีพอ และในยุคที่ USB2 ยังทำหลายอย่างที่ Lightning ทำไม่ได้ Apple จึงสร้าง Lightning ขึ้นมา แต่เมื่อ USB-C ออกมา ก็รับเข้ามาใช้กับ Mac และ iPad ทันที ส่วน iPhone น่าเสียดายที่ยังถ่วงเวลาอยู่

  • Asahi และ Alyssa คือยักษ์ใหญ่แห่งงานวิศวกรรมย้อนกลับ และผลงานของพวกเขาน่าทึ่งจนแทบไม่น่าเชื่อ
    ผมคิดว่ามีความเป็นไปได้สูงที่ Apple เคยพยายามหรือกำลังพยายามจ้างพวกเขา แต่ถูกปฏิเสธไปแล้ว

    • Alyssa ทำสัญญากับ Valve อยู่แล้ว
      อาจมองได้ว่า Valve มีเหตุผลทางธุรกิจที่จะใช้ประโยชน์จากความสามารถนี้มากกว่า Apple
    • ผมเดาว่า Apple คงเคยลองแล้วแต่ถูกปฏิเสธเพราะ NDA และข้อห้ามแข่งขัน หรือไม่ก็ฝ่าย HR ประเมินโปรไฟล์ของพวกเขาได้ไม่ถูกต้อง
    • การจ้างงานไม่ใช่ข้อเสนอที่ดีนัก
      โดยทั่วไปพนักงานได้รับค่าตอบแทนต่ำเมื่อเทียบกับกำไรที่ตนสร้างขึ้น และในวงการ IT ก็ยิ่งเป็นเช่นนั้น
      คนมีความสามารถควรตั้งนิติบุคคลแล้วขายบริการในราคาที่เหมาะสมจะดีกว่า แต่ในบางประเทศ บริษัทใหญ่ ๆ ล็อบบี้รัฐบาลจนปิดเส้นทางแบบนี้ไปแล้ว

  • ทริกของ atomic operations น่าพอใจมาก และการอนุมานคำสั่ง swizzle จากสายตระกูล PowerVR ก็น่าประทับใจเป็นพิเศษ
    วิศวกรของ Apple เองก็น่าจะได้เรียนรู้จากตรงนี้ หรืออย่างน้อยก็น่าจะชื่นชมความฉลาดของมันมาก
    ทำให้นึกถึงสมัยก่อนที่ Accolade ทำวิศวกรรมย้อนกลับฮาร์ดแวร์วิดีโอของ Sega Genesis วิศวกรใช้เอกสารสาธารณะของ Texas Instruments TMS9918 VDP เป็นจุดเริ่มต้น เพื่ออนุมาน VDP ที่สืบเชื้อสายจาก 9918 ใน Genesis(Mega Drive)

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

  • เพื่อให้ชัดเจน นี่ไม่ใช่ไดรเวอร์ Linux ตัวแรกที่ได้รับการรับรองความสอดคล้อง แต่มีความหมายกว่านั้น
    เพราะแม้แต่ Apple เองก็ไม่สอดคล้องกับ OpenGL ES 3.1 นี่จึงเป็นไดรเวอร์ OpenGL ES 3.1 สำหรับ M series ตัวแรกอย่างแท้จริงที่ได้รับการรับรองความสอดคล้อง ไม่ว่าจะบนระบบปฏิบัติการใด
    นั่นจึงเป็นเหตุผลที่มีการขอให้บริจาคให้ทีม
    https://asahilinux.org/support/

    • ผมชอบสิ่งที่พวกเขาทำมาก แต่ก่อนหน้านี้พอกดลิงก์ asahilinux จาก Hacker News ก็มีป๊อปอัปขึ้นมาว่าผู้อ่าน Hacker News ไม่เป็นที่ต้อนรับบนไซต์ ทำให้อ่านเนื้อหาไม่ได้
    • สงสัยว่าจะใช้สิ่งนี้บน macOS ได้ไหม
    • ลิงก์ GitHub ตรงนั้นพาไปหา marcan ผู้ที่นำ Asahi แต่ผมอยากสนับสนุน การพัฒนาไดรเวอร์ เป็นหลัก
      ถ้ามีตัวเลือกแบบนั้นก็อยากรู้ว่าต้องทำที่ไหน และถ้าไม่มี ภายหลังผมก็คงใช้ลิงก์นั้นไปเลย

  • ตอนนี้ หากลองดีบัก แอป OpenGL บน macOS ซึ่งไม่แนะนำให้ใช้แล้ว ปัญหานี้จะเห็นได้ชัดมาก
    เพราะชั้น abstraction ไม่ได้เปิดเผยสถานะ OpenGL จริงในแบบที่ดีบักเกอร์ OpenGL รุ่นเก่าของ Apple อ่านได้
    ถ้าไม่มี Mac รุ่นเก่าที่ติดตั้ง macOS เก่า ๆ ซึ่ง OpenGL ยังไม่ได้ทำงานอยู่บน Metal ภายใน ก็แทบจะดีบัก OpenGL บน macOS ด้วยดีบักเกอร์พื้นฐานไม่ได้เลย
    ดีบักเกอร์หรือแอปก็แค่แครชไป

  • เรื่องนี้ดูเหมือนจะช่วยเกมเป็นหลัก และไม่ได้ช่วย deep learning มากนัก
    จุดที่น่าสนใจที่สุดของ Mac M1 คือ ความจุหน่วยความจำขนาดใหญ่ และถึงแม้อาจไม่ค่อยเหมาะกับการเทรนเพราะกระจายไปหลายการ์ดไม่ได้ แต่ก็เหมาะเป็นเอนจิน inference สำหรับโมเดลขนาดใหญ่อย่าง Stable Diffusion, LLaMA

    • มาตรฐาน GPU อเนกประสงค์แบบข้ามแพลตฟอร์มรุ่นล่าสุดที่ Apple Silicon สามารถใช้หรืออิมพลีเมนต์ได้ในทางทฤษฎีมีอยู่สองอย่างคือ SYCL และ Vulkan Compute
      SYCL เป็นเฟรมเวิร์กการเขียนโปรแกรมระดับสูงที่เป็นกลางต่อผู้ขายของ Khronos Group แต่การรองรับจากแอปพลิเคชันยังจำกัด และหวังว่าจะค่อย ๆ ดีขึ้นด้วยการสนับสนุนจาก Intel
      Vulkan Compute อ้อมปัญหาด้วย compute shader แต่ไม่ค่อยรู้สถานะการรองรับจากแอปพลิเคชัน
      SYCL สามารถอิมพลีเมนต์บน OpenCL และส่วนขยาย SPIR-V ของ OpenCL ได้ แต่เพราะการผูกติดกับผู้ขายค่อนข้างรุนแรง เส้นทางนี้จึงถูกละทิ้งไปเป็นส่วนใหญ่ ยกเว้น Intel กับ Mesa และปัจจุบันมักอิมพลีเมนต์เป็นแบ็กเอนด์สำหรับ API ของผู้ผลิต GPU แต่ละราย เช่น ROCm, HIP, CUDA
      การใช้วิธีเดียวกันกับ Metal น่าจะยากมาก และแม้ Mesa จะมีการรองรับเชิงทดลองสำหรับ OpenCL+SPIR-V สำหรับ Intel และ AMDGPU ซึ่งในทางทฤษฎีสามารถขยายไปยัง Apple Silicon ได้ แต่ตอนนี้ OpenCL บน Apple Silicon ยังไม่รองรับเลย และเป็นเพียงระดับที่เคยอยู่ใน roadmap เท่านั้น
    • ใช่
      ถ้าจะรัน deep learning ต้องมีแบ็กเอนด์อย่าง CUDA, ROCm, MPS
      การเทรนโมเดล PyTorch บนเซิร์ฟเวอร์ CUDA ขนาดใหญ่ แล้วเอามารัน inference บน MacBook Air ค่อนข้างง่าย
    • ส่วน compute shader ถือเป็นความคืบหน้าที่ดี แต่ก็ยังไม่ได้ให้อินเทอร์เฟซที่เครื่องมือ deep learning เหล่านี้คาดหวัง
      อย่างไรก็ตาม eiln ได้เขียนไดรเวอร์ Apple Neural Engine ทำให้ใช้ฮาร์ดแวร์เฉพาะทางแทน GPU ได้ และมีแผนจะ merge เข้า linux-asahi ในอนาคต
    • TensorFlow Lite รองรับ OpenGL ES จริง ๆ

  • การบอกว่า Asahi Lina กับอีกสองคนเอาชนะบริษัทยักษ์ใหญ่ด้วยเงินทุนขั้นต่ำฟังดูเท่ แต่ในความเป็นจริงน่าจะใกล้เคียงกับการที่ Apple ไม่ได้สนใจมากกว่า ไม่ใช่ว่าถูกเอาชนะ
    Apple ไม่ได้ลงแข่งรายการนั้นตั้งแต่แรก

  • ชอบคำพูดอ้อม ๆ ว่า “คนสองคนเอาชนะบริษัทยักษ์ใหญ่ด้วยเงินทุนขั้นต่ำ”
    เรื่องนี้เป็นเรื่องน่าอับอายอย่างชัดเจนสำหรับ Apple และ Apple ไม่สนใจมาตรฐานหรือการปฏิบัติตามมาตรฐาน แถมยังอยากให้ผู้คนติดอยู่ใน สวนปิด ของตัวเอง
    ถ้าไม่ได้เป็นนักพัฒนา iOS คงออกจาก ecosystem ของ Apple ไปนานแล้ว
    ผมชอบฮาร์ดแวร์ และเคยชอบแบรนด์ที่ชูความคิดสร้างสรรค์กับความเป็นมนุษย์เหมือน Apple ยุค 80–90 แต่บริษัทในตอนนี้ดูเหมือนเน่าเฟะด้วยความโลภอยู่เบื้องหลังวิดีโอการตลาดที่ถูกต้องทางการเมือง

    • เห็นด้วยเต็มที่ แต่การหาทางเลือกที่มีความหมายได้นั้นแทบเป็นไปไม่ได้จริง ๆ
      ตอนอัปเกรดครั้งล่าสุดก็ลองหาทางเลือกแล้ว แต่ถ้าจะออกจาก Apple ต้องยอมประนีประนอมแบบไม่จบสิ้น
      ลองมอง Pixel แทน iPhone โดยหวังว่าจะได้ Android แบบ stock และการซัพพอร์ตยาว ๆ แต่ก็มีเรื่องปัญหาแบตเตอรี่พูดกันไม่หยุด แถมความสมบูรณ์ของซอฟต์แวร์ ecosystem ของแอป และเสถียรภาพก็ยังเป็นอุปสรรค
      ยังหาเครื่องที่คุ้มค่าใกล้เคียง MacBook Air M1 รุ่นพื้นฐานในด้านคุณภาพงานประกอบ แบตเตอรี่ และเสถียรภาพได้ยาก
      ผมอ่านการ์ตูนกับนิตยสารบน iPad ด้วย และในตลาดแท็บเล็ตก็ไม่รู้ว่าทางเลือกคืออะไรมาเป็นหลายปีแล้ว ส่วน Apple Watch อาจจะเลิกใช้ได้ก็จริง แต่มันก็ทำงานได้ดี และมีอุปกรณ์เสริมจาก third party เยอะ
      ตอนนี้พ้นยุคที่แฟลช ROM ใหม่ทุกวันไปแล้ว และน่าเสียดายที่ดูเหมือนจะเอาชนะ Apple ในด้านเสถียรภาพกับความสะดวกในการใช้งานได้ยาก
    • ความลับที่ใหญ่ที่สุดของอุตสาหกรรมนี้อาจเป็นข้อเท็จจริงที่ว่า คนสองคน สามารถทำผลงานได้มากกว่าบริษัทที่ใหญ่ที่สุด
      เหตุผลเดียวที่งานของทุกคนยังปลอดภัย คือไม่มีใครรู้แน่ชัดว่าคนสองคนนั้นคือใคร
    • ดูเหมือนทุกคนจะมองข้ามไปว่า ทั้งที่ Apple น่าจะล็อกโน้ตบุ๊กได้ค่อนข้างง่าย แต่กลับเปิดช่องไว้ให้ระบบปฏิบัติการอื่นและการพัฒนาระบบเหล่านั้นเป็นไปได้
      Apple ทำซิลิคอนเองและสร้างทั้งแพลตฟอร์มขึ้นมา แต่คงยากจะมองว่าการปล่อยให้รันระบบปฏิบัติการอื่นได้เป็นเพียงความผิดพลาด
      ทั้งที่เห็นได้ชัดว่าเป็นการเปิดช่องไว้อย่างตั้งใจเพื่อการพัฒนาของบุคคลที่สาม บรรยากาศที่โทษ Apple จึงน่าผิดหวัง
    • ผมไม่คิดว่าแค่มีมาตรฐานอยู่แล้ว Apple จะต้องอิมพลีเมนต์มันเสมอไป
      ตัวอย่างเช่น การรองรับ การอิมพลีเมนต์ Vulkan อย่างต่อเนื่องต้องใช้ทรัพยากรมากและสร้างภาระต่อกำหนดการออกเวอร์ชัน จึงต้องมีเหตุผลทางธุรกิจ
      “เพื่อเลี่ยงความอับอาย” มีโอกาสสูงว่าจะยังไม่พอ
      เหตุผลเรื่องไมตรีต่อชุมชนอาจเป็นไปได้ แต่ Apple คงไม่ไล่ตามความชื่นชอบจากคนที่เรียก Apple ว่า “บริษัทที่เน่าเฟะด้วยความโลภอยู่เบื้องหลังวิดีโอการตลาดที่ถูกต้องทางการเมือง”
    • OpenGL เป็นสเปกที่กำลังตายซึ่งตั้งอยู่บนโมเดลการเขียนโปรแกรมที่เก่าและเลวร้าย และ การทดสอบความสอดคล้องตามมาตรฐาน ของ Khronos ก็มีส่วนที่แปลกและเกินพอดี
      การทดสอบความสอดคล้องตามมาตรฐานไม่ใช่โอเพนซอร์ส และ “conformance suite” แยกต่างหากบน GitHub ก็อิงจาก dEQP ของ Google ไม่ใช่ชุดทดสอบภายในของ Khronos
      แม้การอิมพลีเมนต์จะมีบั๊กและช่องโหว่ค่อนข้างใหญ่ ก็ยังได้รับ “การรับรองว่าเข้ากันได้กับมาตรฐาน” ได้
      Apple สัญญาแค่รองรับ OpenGL 3.1 และไดรเวอร์ OpenGL สำหรับ M1 ก็ถูกเขียนใหม่เป็นชั้น emulation บน Metal เพื่อให้แอปเดิมยังทำงานต่อได้ แต่จะไม่อิมพลีเมนต์ OpenGL เวอร์ชันใหม่กว่านั้น และก็ไม่จำเป็นต้องทำ
      มีเรื่องให้วิจารณ์ Apple มากมาย และยังมีช่องให้ทำให้ Metal API กับเครื่องมือดีขึ้นอีกมาก แต่การไม่สนใจ OpenGL ในกรณีนี้ถือเป็นการตัดสินใจที่สมเหตุสมผลพอแล้ว

  • น่าสนใจที่ต้นฉบับไม่มีคำว่า ‘Apple’ เลยสักครั้ง และใช้แค่คำว่า ‘ผู้ผลิต’ กับ ‘บริษัทยักษ์ใหญ่’
    ถ้าตั้งใจทำแบบนั้น ก็สงสัยว่าเป็นเหตุผลทางกฎหมายหรือเปล่า

    • น่าจะเป็นเพราะบทความนี้ไม่ได้เกี่ยวกับ Apple
      ประเด็นที่สนใจไม่ใช่ Apple แต่เป็นการรัน Linux ให้ดีบน สถาปัตยกรรม M1/M2 และถ้าเป้าหมายเป็น Microsoft, Amazon, Google ก็คงถูกพูดถึงในลักษณะเดียวกัน

  • การดูไลฟ์สตรีมที่แสดงกระบวนการพัฒนาไดรเวอร์นี้สนุกมาก และเป็นงานที่น่าทึ่งจริง ๆ

    • เผื่อใครยังไม่รู้ สามารถดูได้ที่ https://www.youtube.com/c/AsahiLina
      เป็นหนึ่งในงาน การเขียนโปรแกรมระดับต่ำ ที่น่าทึ่งที่สุดเท่าที่เคยเห็นมา