คำร้องทางเทคนิคจากนักพัฒนา Anukari ถึง Apple
(anukari.com)- Anukari โปรแกรมจำลองเสียงแบบเรียลไทม์บน GPU อธิบายปัญหาที่ ไม่สามารถรับประกันประสิทธิภาพที่คาดการณ์ได้บนอุปกรณ์ macOS ที่ใช้ Apple Silicon และ ขอให้ได้เชื่อมต่อโดยตรงกับทีม Apple Metal
- Anukari เป็นซินธิไซเซอร์เสียงแบบอิงฟิสิกส์ ซึ่งต้องรวมวัตถุหลายร้อยชิ้นบน GPU ในทุกบล็อกบัฟเฟอร์เสียง และ พึ่งพาสมรรถนะ GPU ALU อย่างเต็มที่
- เนื่องจาก ตรรกะปรับพลังงาน/ประสิทธิภาพอัตโนมัติของ macOS ไม่สามารถรับรู้เวิร์กโหลดเสียงลักษณะพิเศษนี้ได้ดีพอ ทำให้ความถี่สัญญาณนาฬิกา GPU ถูกคงไว้ในระดับต่ำ และเกิด ประสิทธิภาพตกกับอาการเสียงสะดุด
- เพื่อแก้ปัญหานี้ มีการใช้กลยุทธ์ “waste makes haste” โดยเพิ่ม spin kernel ที่สร้างโหลดปลอมเพื่อหลอก GPU แต่ มีแนวโน้มล้มเหลวบน Mac ประสิทธิภาพสูงตั้งแต่ M1 เป็นต้นไป
- แนวทางแก้ที่เสนอคือ เพิ่มความสามารถให้ GPU command queue รับรู้เวิร์กโหลดแบบเรียลไทม์ หรือ ขยายแนวคิด Audio Workgroup ไปถึง Metal เป็นต้น
Anukari คืออะไร?
- Anukari คือ ซินธิไซเซอร์เสียงแบบเรียลไทม์ 3D ที่อิงฟิสิกส์ ซึ่งสร้างเสียงโดยคำนวณโมเดลสปริง-มวลขนาดใหญ่บน GPU
- ใช้งานในเวิร์กสเตชันเสียง (DAW) ในรูปแบบ AudioUnit/VST3 และส่งคำขอคำนวณไปยัง GPU เป็นหน่วยตามบัฟเฟอร์เสียง
- การคำนวณนี้ เน้นปริมาณการประมวลผล (=ALU) มากกว่าหน่วยความจำ และใช้ GPU threadgroup memory เพื่อให้ประมวลผลความเร็วสูงระดับแคช L1
แก่นของปัญหาด้านประสิทธิภาพ
- macOS จะ ปรับความถี่ GPU อัตโนมัติโดยเน้นประสิทธิภาพต่อพลังงาน และจะลดความถี่ลงเมื่อรับรู้ว่าโหลด GPU ต่ำ
- Anukari มีโครงสร้างที่ทำงาน แบบเรียลไทม์ช่วงสั้นแต่หนาแน่น ซ้ำ ๆ จึงทำให้ macOS รับรู้โหลด GPU ได้ไม่ถูกต้อง
- สิ่งนี้ทำให้ ไม่สามารถรับประกันประสิทธิภาพที่จำเป็น เพื่อให้ผ่านข้อจำกัดของงานแบบเรียลไทม์ได้
หลักฐานและการทดสอบ
- ใช้ Metal Profiler ของ Apple Xcode เพื่อตรวจสอบ ความแตกต่างของความถี่ในแต่ละสถานะประสิทธิภาพ ได้โดยตรง
- ในสถานะ Maximum performance สามารถทำงานได้ลื่นไหล แต่ในสถานะ Minimum จะเกิดอาการเสียงขาดช่วง
กลยุทธ์ “waste makes haste”
- เพื่อบังคับให้ความถี่ GPU สูงขึ้น Anukari จึงรัน งาน GPU สำหรับสร้างโหลดแบบ spin loop ควบคู่กันไป
- กลยุทธ์นี้ใช้ได้ผลบน M1 แต่บน ชิประดับ Pro/Max มีโอกาสล้มเหลว เพราะโหลดอาจถูกกระจายไปยังคอร์ GPU อื่นแทน
แนวทางแก้ที่เสนอ
- ขยาย Audio Workgroup ไปถึง GPU เพื่อให้ระบบรับรู้เป็นเวิร์กโหลดแบบเรียลไทม์
- เพิ่ม ธงบอกความไวต่อเวลาจริง ใน Metal API
- (ในแง่ดี) หากมีวิธีที่มีอยู่แล้ว ก็หวังว่าจะได้รับคำแนะนำ
ทางเลือกอื่นที่พิจารณาและข้อจำกัด
- Game Mode อิงกับทั้งโปรเซส จึงใช้กับ Anukari ที่อยู่ในรูปแบบปลั๊กอินไม่ได้
- บน Windows ไม่มีปัญหานี้ อาจเป็นเพราะการจัดการความถี่มีข้อจำกัดน้อยกว่าหรือควบคุมการตั้งค่าได้
- การรันหลายเคอร์เนลแบบเฮดจ์ ไม่เหมาะสม เพราะเพิ่มความหน่วงของเสียงและมีปัญหาเรื่องการซิงก์สถานะ
- โค้ดฝั่ง GPU ถูกปรับแต่งจนถึงขีดสุดแล้ว (ใช้ FP16, จัดแนว SIMD group, ปรับแต่ง ALU ฯลฯ)
ทำไมต้องเป็น GPU ไม่ใช่ CPU?
- Anukari ทำการคำนวณฟิสิกส์ของวัตถุ 768~1024 ชิ้น 48,000 ครั้งต่อวินาที และ รองรับโพลีโฟนีได้สูงสุด 16 เสียง
- CPU ไม่สามารถรองรับได้ทั้งในแง่ปริมาณการคำนวณและความขนาน
- ความสามารถของ GPU ALU, การควบคุมแคช L1, และการควบคุมความขนานด้วย threadgroup_barrier เป็นสิ่งจำเป็นอย่างยิ่ง
ทำไม Apple ควรใส่ใจกับปัญหานี้?
- Anukari เป็น ผลิตภัณฑ์เฉพาะทางของสตาร์ทอัพขนาดเล็ก แต่มี กลุ่มผู้ใช้ที่หลงใหล และ ได้รับความสนใจจากศิลปินชื่อดัง
- Apple Silicon มีสมรรถนะเพียงพอสำหรับเวิร์กโหลดนี้อยู่แล้ว และ หากเปลี่ยนนโยบายการปรับความถี่ก็อาจแก้ปัญหาได้
ทำไม GPU Audio API ถึงใช้ไม่ได้?
- Anukari ไม่ใช่ DSP แบบดั้งเดิม แต่เป็น ตัวอินทิเกรตสมการเชิงอนุพันธ์เชิงตัวเลข ที่ใกล้เคียงกับเอนจินฟิสิกส์ของเกมมากกว่า จึง ไม่สอดคล้องกับระดับนามธรรมของ GPU Audio
- ใช้ Metal API โดยตรง และจำเป็นต้องมี การปรับแต่งอย่างสุดขั้วเฉพาะโดเมน
สรุปคำขอ: กำลังรอการตอบกลับจากวิศวกร Apple ให้เพิ่ม ความสามารถรับรู้การประมวลผลแบบเรียลไทม์ สำหรับเสียงบน GPU ใน Metal API หรือนโยบายปรับประสิทธิภาพของ macOS
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
สวัสดีทุกคน ผมได้คุยกับคนที่เหมาะสมในทีม Metal อย่างมีประสิทธิผลมาก ขอบคุณที่ช่วยให้เรื่องนี้ไปเตะตา Apple ผมไม่คาดคิดเลยว่าจะได้รับการสนับสนุนมากขนาดนี้
สงสัยที่มาของชื่อ Anukari
ผมมีประสบการณ์กับบริษัทดังสองแห่งที่มีแอปชื่อดังมากอยู่บน Apple App Store
Metal profiler มีความสามารถที่มีประโยชน์มากอย่างหนึ่ง: คุณสามารถเลือก Metal "performance state" ได้ระหว่างโปรไฟล์แอปพลิเคชัน ซึ่งไม่สามารถตั้งค่าได้นอก profiler
ปัญหาของการเปิดเผย API สำหรับเรื่องนี้คือ นักพัฒนาจำนวนมากเกินไปน่าจะบังคับให้ใช้สถานะประสิทธิภาพสูงสุดตลอดเวลา ผมไม่แน่ใจว่ามีวิธีดี ๆ ที่จะป้องกันเรื่องนั้นและยังคงมี API นี้ไว้ได้หรือไม่
วิธีที่ดีที่สุดในการแก้ปัญหานี้:
อย่าพลาดลิงก์ที่ถูกโยนไว้ในย่อหน้ารองสุดท้าย เป็นลิงก์ไปยังเดโมที่ทำโดย Mick Gordon โดย @anukarimusic ได้ตอบกลับเรื่องนี้ไว้
เสริมอีกนิด Anukari ควรออก Mick Gordon sound pack และแบ่งรายได้กับเขา คนนี้กำลังสร้างสิ่งที่น่าทึ่งอยู่ เดโมของเขายอดเยี่ยมมาก การร่วมงานกับศิลปินเมื่อคุณมีเครื่องมือทรงพลังเป็นทั้งธุรกิจที่ดีและเป็นผลดีกับโลก ถ้าคุณชอบ Mick Gordon ผมชอบนะ
ผมไม่จำเป็นต้องใช้แอปนี้ แต่เจ๋งมาก แอปแบบนี้นำ "ความสนุก" กลับมาสู่การคอมพิวเตอร์ ไม่ใช่ว่าตอนนี้ไม่มีความสนุกนะ แต่มันทำให้นึกถึงสมัยก่อนที่ยังมีโปรแกรมกราฟิกและโปรแกรมเชิงทดลองลอยไปมาเยอะกว่านี้ แม้แต่เดโมซีนด้วย