VDPU381 และ VDPU383 เป็นชิปถอดรหัสวิดีโอ (video decoder) ที่พบในชิป SoC ตระกูล Rockchip RK3588 และ Rockchip RK3576 รวมถึงรุ่นย่อยอย่าง RK3588S และ RK3576J, ที่ผ่านมาเราจำเป็นต้องพึ่งพา Rockchip BSP เพื่อให้สามารถใช้งานการถอดรหัสวิดีโอแบบฮาร์ดแวร์ได้ แต่ล่าสุด Collabora ได้ประกาศรองรับการถอดรหัสวิดีโอแบบฮาร์ดแวร์สำหรับโค้ดเดก H.264 (AVC) และ H.265 (HEVC) บน Linux เวอร์ชัน upstream/mainline สำหรับชิป SoC ตระกูล RK3588 และ RK3576 เป็นที่เรียบร้อยแล้ว
จุดเด่นของการพัฒนาระบบถอดรหัสวิดีโอ H.265 / H.264 บน Linux mainline:
- ชุดแพตช์จำนวน 17 รายการ เพื่อเพิ่มการรองรับตัวถอดรหัสวิดีโอ พร้อมทั้งเพิ่ม dt-bindings และโหนดใน Device Tree
- เพิ่ม UAPI controls ใหม่ของ V4L2 สำหรับ HEVC เพื่อรองรับการจัดการ Short-term และ Long-term RPS (Reference Picture Set) แบบชัดเจน
- แก้ไขปัญหา IOMMU ที่ไม่เห็นได้ชัด ซึ่งเกิดจากการ decoder-embedded IOMMU
- ใช้รูปแบบการโปรแกรมรีจิสเตอร์แบบโครงสร้าง (struct-based register programming model) เพื่อให้มั่นใจในความครบถ้วนของการตั้งค่า ลำดับการทำงานที่ถูกต้อง และรองรับการขยายสู่ระบบ multi-core ในอนาคต
UAPI controls ใหม่ของ V4L2 สำหรับ HEVC ในส่วนของ Long-term และ Short-term Reference Picture Set (RPS) มีความจำเป็นสำหรับตัวถอดรหัสวิดีโอ VDPU381 (RK3588) และ VDPU383 (RK3576) แตกต่างจาก Decoders บางรุ่น (เช่น VeriSilicon) ที่สามารถละเว้นส่วนนี้ได้ ดังนั้นจึงต้องมี API สำหรับให้ userspace ส่งตาราง RPS ทั้งแบบระยะสั้นและระยะยาวที่อธิบายรายละเอียดครบถ้วนไปยังเคอร์เนล บริษัทยังได้เพิ่มการรองรับในไดรเวอร์ Virtual Stateless Decoder (visl) ซึ่งสามารถแสดง ftrace พร้อมพารามิเตอร์ control ทั้งหมดได้ UAPI controls ของ V4L2 ถูกนำไปใช้งานแล้วใน GStreamer 1.28 (ถูกรวมเข้าระบบแล้ว) และใน FFmpeg (อยู่ในขั้นต้น) นอกจากนี้ API ใหม่นี้ยังช่วยให้สามารถทำงานร่วมกับ Vulkan Video Decode ได้อีกด้วย
ประเด็นปัญหา IOMMU restore ถือว่าน่าสนใจทีเดียว เนื่องจาก IOMMU core ถูกฝังอยู่ภายใน Rockchip Decoders ดังนั้นเมื่อรีเซ็ต Decoder ตัว IOMMU ภายในก็จะถูกรีเซ็ตตามไปด้วย ส่งผลให้ address mappings ที่ตั้งค่าไว้ก่อนหน้านี้ถูกล้างทั้งหมด แต่เคอร์เนลยังคงเข้าใจว่าIOMMU mappings ยังคงใช้งานได้หลังจากการรีเซ็ต Decoder จึงมีแพตช์ที่เข้ามาแก้ไขปัญหานี้ โดยทำการกู้คืน (restore) cached IOMMU mappings อย่างชัดเจน หลังจากเกิดการรีเซ็ต Decoder ปัญหานี้ไม่ได้กระทบเฉพาะ Decoders เท่านั้น แต่ยังส่งผลต่อ IP blocks อื่น ๆ ภายใน SoC ของ Rockchip เช่น RGA ซึ่งเป็นตัวเร่งกราฟิก 2 มิติ (2D graphics accelerator) ด้วย
Rockchip decoder registers บางส่วนมีค่าเริ่มต้น ระบุไว้ในเอกสาร datasheet แต่ฮาร์ดแวร์อาจอยู่ในสถานะที่ไม่สอดคล้องกันได้ หากโค้ดในเคอร์เนลข้ามการเขียนค่าไปยังรีจิสเตอร์บางตัว แม้ค่านั้นจะเป็นค่าเริ่มต้นก็ตาม นั่นหมายความว่าวิธีที่ปลอดภัยกว่าคือการเขียนค่าให้ครบทุกรีจิสเตอร์ทุกครั้ง วิศวกรของ Collabora ยังพบเพิ่มเติมว่า “ลำดับ” ในการเขียนค่ารีจิสเตอร์ก็มีความสำคัญเช่นกัน เพราะหากเขียนค่าผิดลำดับ อาจทำให้ Decoder ทำงานผิดพลาดได้ ด้วยเหตุผลทั้งสองประการนี้ พวกเขาจึงตัดสินใจใช้โครงสร้างข้อมูลแบบ C struct สำหรับการตั้งค่ารีจิสเตอร์ แทนการเรียก writel() แบบเฉพาะจุด (ad-hoc) หรือใช้ regmap สามารถดูรายละเอียดเพิ่มเติมได้จาก commit ที่เกี่ยวข้อง
การรองรับดังกล่าวถูกรวมเข้าใน Linux เวอร์ชัน 7.0 แล้ว (ดูในส่วนความคิดเห็น) ข่าวลักษณะนี้ให้ความรู้สึกทั้งน่ายินดีและน่าหงุดหงิดในเวลาเดียวกัน เพราะเราสามารถเลือกใช้โปรเซสเซอร์ที่ค่อนข้างใหม่และมีประสิทธิภาพสูงได้ หากยอมใช้ vendor BSP แต่หากต้องการใช้งาน mainline Linux อย่างเต็มรูปแบบ กลับมักต้องเลือกใช้โปรเซสเซอร์ที่มีอายุ 4–5 ปีแล้ว ดูเหมือนว่าเรายังไม่สามารถได้โปรเซสเซอร์รุ่นใหม่พร้อมการรองรับ mainline Linux อย่างสมบูรณ์ในเวลาเดียวกันได้
ต่อไป Collabora จะดำเนินการพัฒนาการรองรับแบบ multi-core บน Rockchip RK3588 เนื่องจากชิปรุ่นนี้มีคอร์ดีโค้ดเดอร์ VDPU381 จำนวน 2 คอร์ นอกจากนี้ยังมีแผนเพิ่มการรองรับ AV1 บน Rockchip RK3576 และรองรับโค้ดเดก VP9 บน RK3588 รวมถึงเพิ่มการรองรับ VDPU346 decoder ซึ่งเป็นรุ่นย่อยของ VDPU381 ที่พบใน SoC ตระกูล RK356X ได้แก่ RK3562, RK3566 และ RK3568 สามารถดูสรุปรายละเอียดการเปลี่ยนแปลงทั้งหมดเพิ่มเติมได้ที่เว็บไซต์ของ Collabora
แปลจากบทความภาษาอังกฤษ : Rockchip RK3588 and RK3576 H.264 and H.265 video decoders gain mainline Linux support
บรรณาธิการข่าวและบทความภาษาไทย CNX Software ได้มีความสนใจในด้านเทคโนโลยี โดยเฉพาะ Smart Home และ IoT