Box64 และ RISC-V ในปี 2024: เงื่อนไขสำหรับรัน The Witcher 3 บน RISC-V

 (box86.org)
1 คะแนน โดย GN⁺ 2024-08-28 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • RV64 DynaRec ของ Box64 พัฒนาจากระดับที่เมื่อ 1 ปีก่อนรันได้เพียงเกม Linux แบบเนทีฟง่าย ๆ ไปจนถึงขั้นรัน The Witcher 3 บนพีซี RISC-V ได้
  • จุดเปลี่ยนของความคืบหน้าคือการที่สามารถ ใช้การ์ดจอ AMD ได้ ทำให้ข้อจำกัดด้าน OpenGL ลดลง และสามารถทดสอบโปรแกรม x86 ได้มากขึ้นพร้อมแก้บั๊กได้มากขึ้น
  • แบ็กเอนด์ RV64 มีจำนวนคำสั่ง x86 ที่อิมพลีเมนต์น้อยกว่าแบ็กเอนด์ ARM64 และในฝั่ง RISC-V ยังมีงานค้างอีกมากสำหรับ คำสั่ง AVX
  • RISC-V ขาดการดึง/แทรกช่วงบิตและ คำสั่งอะตอมิกขนาด 16 ไบต์ ทำให้ต้นทุนการแปลสำหรับอีมูเลชัน x86 สูงกว่า AArch64 หรือ LoongArch64
  • The Witcher 3 สามารถรันจริงด้วย box64 โดยทำได้สูงสุด 15fps ในเกม และถึงความเร็วเต็มในเมนูหลัก

กว่าจะรัน The Witcher 3 บน RISC-V ได้

  • เมื่อ 1 ปีก่อน RV64 DynaRec รันได้เฉพาะ เกม Linux แบบเนทีฟที่รันค่อนข้างง่าย อย่าง Stardew Valley และ World of Goo
  • คอขวดในตอนนั้นมีหลัก ๆ 2 อย่าง
    • ระหว่างเพิ่มคำสั่ง x86_64 ให้แบ็กเอนด์ RISC-V อย่างรวดเร็ว ยังมี บั๊กของ DynaRec เหลืออยู่มาก
    • GPU ในตัว IMG ของ VisionFive 2 และ LicheePi 4A รองรับเฉพาะ OpenGL ES และไม่รองรับ OpenGL
  • แม้จะได้การรองรับ OpenGL บางส่วนผ่าน gl4es จนรันเกมอย่าง Stardew Valley ได้ แต่ก็ยังไม่เพียงพอสำหรับเกม Linux ที่หนักกว่าและเกม Windows ทั่วไป
  • Milk-V Pioneer ของ Sophgo เป็นพีซี RISC-V แบบ 64 คอร์ และมีสล็อต PCIe สำหรับเสียบการ์ดจอ
  • ผู้ร่วมพัฒนาอีกคนคือ xctan พบวิธี “เชื่อมต่อ” การ์ดจอ AMD เข้ากับ VisionFive 2 ผ่านอินเทอร์เฟซ M.2
  • เมื่อสามารถใช้การ์ดจอ AMD ได้ ขอบเขตโปรแกรม x86 ที่ทดสอบได้ก็กว้างขึ้น และมีการแก้บั๊ก RV64 DynaRec กับเพิ่มคำสั่ง x86 จำนวนมาก
  • ผลคือเมื่อรัน The Witcher 3 ครั้งแรก เกมก็ทำงานได้ทันที

สถานะปัจจุบันของ RV64 DynaRec

  • ชุดคำสั่ง x86 มีขนาดใหญ่มาก และขนาดการอิมพลีเมนต์ก็แตกต่างกันไปในแต่ละแบ็กเอนด์
    • แบ็กเอนด์ ARM64 อิมพลีเมนต์คำสั่ง x86 โดยรวมแล้ว มากกว่า 1,600 คำสั่ง
    • แบ็กเอนด์ RV64 อิมพลีเมนต์คำสั่ง x86 ประมาณ 1,000 คำสั่ง
    • ในจำนวนนี้มากกว่า 300 คำสั่งเป็นคำสั่ง AVX ที่เพิ่งรองรับใหม่ และยังไม่ได้อิมพลีเมนต์บน RISC-V เลย
  • ในการอิมพลีเมนต์คำสั่ง SSE นั้น RISC-V ก็เสียเปรียบด้านประสิทธิภาพ
    • แบ็กเอนด์ RV64 อิมพลีเมนต์คำสั่ง SSE ด้วย คำสั่งสเกลาร์
    • AArch64 ใช้ส่วนขยาย Neon ส่วน LoongArch64 ใช้ส่วนขยาย LSX
    • ความแตกต่างนี้ทำให้ประสิทธิภาพต่ำกว่าอีกสองแบ็กเอนด์อย่างมาก
  • RISC-V มีส่วนขยายเวกเตอร์ชื่อ RVV
    • Milk-V Pioneer รองรับส่วนขยาย xtheadvector ซึ่งเป็นรูปแบบหนึ่งของ RVV 0.7.1
    • SoC SpacemiT K1/M1 รองรับ RVV 1.0 ที่ได้รับการให้สัตยาบันแล้ว
    • Banana Pi F3 และ Milk-V Jupiter ที่ใช้ SoC นี้มีวางจำหน่ายแล้ว
  • เมื่อเร็ว ๆ นี้ box64 ได้เพิ่มการรองรับ RVV ขั้นพื้นฐานและการอิมพลีเมนต์คำสั่ง SSE ทั่วไปบางรายการ
  • งานด้าน RVV ยังอยู่ในช่วงเริ่มต้นมาก จึงยังไม่ช่วยเพิ่มประสิทธิภาพในตอนนี้

คำสั่ง RISC-V ที่ขาดเป็นพิเศษสำหรับอีมูเลชัน x86

  • จากมุมมองของอีมูเลชัน x86 นั้น RISC-V ถือว่าเป็นหนึ่งในสถาปัตยกรรมที่ มีความสามารถในการแสดงคำสั่งต่ำที่สุด ในบรรดา 3 สถาปัตยกรรมที่รองรับ
  • เมื่อเทียบกับ AArch64 และ LoongArch64 แล้ว RISC-V ขาดคำสั่งที่สะดวก ทำให้ต้องใช้คำสั่งมากกว่าเมื่ออีมูเลตการทำงานเดียวกัน
  • โดยเฉพาะอย่างยิ่ง ขาดฟังก์ชันสำคัญ 2 อย่าง
    • ฟังก์ชันเลือก ช่วงบิต เฉพาะจากรีจิสเตอร์หนึ่งแล้วนำไปยังอีกรีจิสเตอร์หนึ่ง
    • ฟังก์ชันแทรกบางบิตของรีจิสเตอร์หนึ่งเข้าไปในช่วงเฉพาะของอีกรีจิสเตอร์หนึ่ง
  • LoongArch64 และ AArch64 มีคำสั่งที่ทำสิ่งนี้ได้
    • LoongArch64 ใช้ BSTRPICK.D และ BSTRINS.D
    • ARM64 ใช้ opcode UBFX และ BFI
  • RISC-V ไม่มีคำสั่งที่สอดคล้องกันทั้งในส่วนขยายทางการและส่วนขยายของผู้ผลิต

ตัวอย่าง ADD AH, BL แสดงต้นทุนการแปล

  • x86 ISA มีแนวโน้มที่จะคงบิตที่ไม่ได้เปลี่ยนไว้ ทำให้การจัดการรีจิสเตอร์บางส่วนมีความสำคัญ
  • ในกรณีของ ADD AH, BL box64 ต้องทำงานต่อไปนี้
    • ดึงไบต์ล่างสุดของ RBX
    • นำไปบวกกับไบต์ล่างสุดลำดับที่สองของ RAX
    • แทรกผลลัพธ์กลับเข้าไปในไบต์ล่างสุดลำดับที่สองของ RAX
    • คงไบต์ที่เหลือของ RAX ไว้เหมือนเดิม
  • บน LoongArch64 สามารถอิมพลีเมนต์ได้อย่างเรียบง่ายและตรงไปตรงมาด้วย BSTRPICK.D, ADD, BSTRINS.D
  • บน RISC-V ต้องผสมผสาน shift, mask, AND, OR ฯลฯ เพื่อทำงานเดียวกัน จึงต้องใช้ 10 คำสั่ง
  • กรณีแบบนี้ไม่ได้เป็นตัวอย่างโดดเดี่ยว และ x86 มีคำสั่งรูปแบบคล้ายกันจำนวนมาก ทำให้การอิมพลีเมนต์บน RISC-V ยุ่งยากกว่า

ข้อจำกัดของคำสั่งอะตอมิกขนาด 16 ไบต์

  • x86 มี คำสั่งที่มีคำนำหน้า LOCK สำหรับการทำงานแบบอะตอมิกที่ไม่ต้องใช้ lock
  • box64 อีมูเลตสิ่งนี้หลัก ๆ ด้วยลำดับ LR/SC
    • LR/SC ย่อมาจาก Load-Reserved / Store-Conditionally
    • ตัวอย่างเช่น LOCK ADD [RAX], RCX จะถูกสร้างเป็นรูปแบบ LR.D, ADD, SC.D, และการแตกแขนงตามเงื่อนไข
  • หากที่อยู่ RAX ไม่ได้จัดแนวไว้ จะซับซ้อนขึ้น แต่โดยทั่วไปวิธีนี้ทำงานได้ดี
  • ปัญหาคือ LOCK CMPXCHG16B
    • คำสั่งนี้เปรียบเทียบ RDX:RAX กับข้อมูล 16 ไบต์ในหน่วยความจำ
    • จากนั้นสลับ RCX:RBX ไปยังที่อยู่หน่วยความจำนั้นตามเงื่อนไข
  • AArch64 และ LoongArch64 มี คำสั่งอะตอมิกขนาด 16 ไบต์ บางส่วนที่ใช้ในการอิมพลีเมนต์ได้
  • RISC-V ไม่มีคำสั่งที่สอดคล้องกัน จึงไม่สามารถอิมพลีเมนต์ได้สมบูรณ์เท่าสถาปัตยกรรมอื่น
  • โปรแกรมจำนวนมากรวมถึงเกม Unity ใช้ LOCK CMPXCHG16B

ผลการรันจริง

  • แม้ยังมีข้อจำกัดเหลืออยู่ แต่ The Witcher 3 ก็รันบน RISC-V ได้ด้วย box64
  • ประสิทธิภาพในเกมทำได้สูงสุดถึง 15fps
  • ในเมนูหลักทำงานที่ ความเร็วเต็ม
  • ถือว่าไม่เลวสำหรับผลลัพธ์จากเครื่องที่ไม่ได้ออกแบบมาเพื่อรันเกม AAA

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

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

 
GN⁺ 2024-08-28
ความคิดเห็นจาก Hacker News

  • ในฐานะคนที่ไม่ได้ทำงานฝั่งชิป อยากรู้ว่าเวลาเขียน ซอฟต์แวร์สำหรับ RISC-V วิศวกรซอฟต์แวร์ต้องทำอะไรให้ต่างออกไปบ้าง
    สงสัยว่าขนาดไฟล์ปฏิบัติการจะใหญ่ขึ้นจนต้องปรับแต่ง cache locality อย่างจริงจังหรือเปล่า และก็อยากรู้ว่ามีประเภทซอฟต์แวร์แบบเกมหรือเว็บเซิร์ฟเวอร์ที่เหมาะกับ CISC/RISC ฝั่งใดฝั่งหนึ่งมากกว่ากันไหม

    • RISC-V ที่มี ส่วนขยายคำสั่งแบบบีบอัด โดยเฉลี่ยแล้วมักให้ขนาดโค้ดเล็กกว่า x86-64 หรือ ARM
      ในเชิงแนวทางการทำซอฟต์แวร์ ไม่ได้มีอะไรที่ต้องเปลี่ยนโดยพื้นฐานมากนัก และความต่างใหญ่สุดเมื่อเทียบกับ x86-64 คือมีรีจิสเตอร์ 32 ตัว จึงเก็บค่ากลางได้มากขึ้นก่อนที่จะต้อง spill ลงสแตก แต่ ARM ก็มี 32 ตัวเช่นกันจึงคล้ายกัน ปกติถ้าไม่ได้ทำ micro-optimization ก็แทบไม่ต้องกังวลมาก
      ถ้าลงรายละเอียดกว่านั้น ส่วนขยายเวกเตอร์ (V/RVV) ไม่ได้อยู่ใน ISA พื้นฐาน rv64gc จึงอาจไม่ได้รับการปรับแต่ง SIMD แล้วแต่เป้าหมาย และ popcount รวมถึงการนับจำนวน 0 นำหน้า/ต่อท้ายก็ไม่มีใน rv64gc พื้นฐาน ต้องใช้ Zbb นอกจากนี้ การเลือกแบบไม่มี branch อย่าง a ? b : c ใน rv64gc พื้นฐานต้องใช้คำสั่ง 4~5 คำสั่ง, ถ้าใช้ Zicond ใช้ 3 คำสั่ง แต่ใน x86-64 และ aarch64 ทำได้ด้วยคำสั่งเดียว
      โปรไฟล์ RISC-V ช่วยแก้ปัญหาสองข้อแรกได้ในระดับหนึ่ง เช่น Android กำหนดให้ใช้ rva23 ซึ่งต้องมี RVV, Zbb, Zicond ฯลฯ แต่ถ้าดิสทริบิวชันลินุกซ์ตั้งเป้าเป็น rva20/rv64gc โค้ดที่คอมไพล์ไว้ล่วงหน้าและไม่ได้ใส่ dynamic dispatch ก็แทบจะใช้ส่วนขยายเหล่านั้นไม่ได้ไปอีกนาน ปัญหาคล้ายกันก็มีใน x86-64 แต่ ARM มีส่วนขยายน้อยกว่ามากจึงเบากว่า โดย SVE เป็นข้อยกเว้นที่ใหญ่ที่สุด แต่ตอนนี้ยังไม่ได้รับการรองรับอย่างแพร่หลาย
    • ส่วนใหญ่ไม่จำเป็นต้องทำอะไรให้ต่างออกไปเลย โค้ดที่เขียนอย่างถูกต้องด้วยภาษาระดับสูงอย่าง C ควรทำงานเหมือนเดิม
      ความต่างที่ใหญ่ที่สุดคือ memory model ที่อ่อนกว่า ซึ่งเป็นคุณสมบัติที่มีในสถาปัตยกรรมที่ไม่ใช่ x86 ส่วนใหญ่อย่าง ARM ด้วย และตั้งแต่แรกโค้ดก็ไม่ควรพึ่งพา memory model ที่แข็งอยู่แล้ว
      ความหนาแน่นของโค้ดปฏิบัติการนั้น ด้วยเหตุผลทางประวัติศาสตร์ x86 ไม่ได้ดีนัก ขนาดไฟล์ปฏิบัติการจึงไม่ได้เพิ่มขึ้นมากเท่าที่คิด RISC-V ที่มีส่วนขยายคำสั่งแบบบีบอัด และ ARM 32 บิตที่มีส่วนขยาย Thumb ค่อนข้างหนาแน่นทีเดียว
      สิ่งสำคัญไม่ใช่ CISC เทียบกับ RISC แต่คือการมีอยู่และคุณภาพของ คำสั่งเวกเตอร์ กับส่วนขยายด้านการเข้ารหัส วิดีโอเข้ารหัส/ถอดรหัสพึ่งพาคำสั่งเวกเตอร์อย่างมากเพื่อให้ได้ประสิทธิภาพดี และการเข้ารหัสดิสก์ทั้งลูกหรือการทำแฮชอาจได้ประโยชน์จากคำสั่งเฉพาะที่ช่วยเร่งอัลกอริทึมอย่าง AES, SHA256
    • ไม่ว่าจะเป็นชุดคำสั่งแบบไหน ก็ควรเหมาะกับ workload แทบทุกประเภทได้ใกล้เคียงกัน ถ้าเขียนแอสเซมบลีก็คงมีความต่าง แต่ถ้าทำด้วย Python หรือ Unity ก็แทบไม่เป็นปัญหา
      ประเด็นหลักคือการเป็นอิสระจากสิทธิบัตรของ ARM และใกล้เคียงกับการ เริ่มต้นใหม่ บนพื้นฐานของบทเรียนที่ได้เรียนรู้มา

  • นึกถึงคนรัสเซียชื่อดังที่รัน Atomic Heart บน Elbrus 8S
    Elbrus มีตัวแปลแบบเนทีฟ และเท่าที่รู้ก็ถือว่าใช้ได้ดีทีเดียว Atomic Heart เล่นได้ในระดับหนึ่งที่ประมาณ 15~25fps

  • บทความอธิบาย “พื้นฐาน” น้อยไปหน่อย ตอนแรกนึกว่าใช้พอร์ต Wine อะไรแบบนั้นรัน แต่จริง ๆ ดูเหมือนว่าเป็นการนำ x86_64 ISA ไปใช้งานบนชิป RISC-V ด้วยวิธีใดวิธีหนึ่ง
    ถ้ามีใครอธิบายเพิ่มเติมได้ว่าตรงนั้นทำงานอย่างไรคงดี

    • คำอธิบายพื้นฐานอยู่ที่นี่: https://box86.org/
      แม้จะเป็นอีมูเลเตอร์ แต่ไลบรารี “ระบบ” บางส่วนอย่าง libc, libm, SDL, OpenGL ใช้เวอร์ชันเนทีฟ จึงผสานใช้งานกับแอปพลิเคชันส่วนใหญ่ได้ง่าย และในบางกรณีประสิทธิภาพก็อาจสูงอย่างน่าประหลาดใจ Wine ก็สามารถคอมไพล์เป็นเนทีฟแล้วรันได้เช่นกัน

  • เป็นผลลัพธ์ที่น่าทึ่ง งานหนักมหาศาล และในบางกรณีก็ดูเหมือนจะแตะ ขีดจำกัดของ RISC-V แล้ว
    คำสั่งรวบรวม/กระจายบิตน่าจะควรถูกใส่เข้ามาเป็นส่วนขยาย

    • อยากเห็นผลทดสอบกับเกมที่พึ่งพาคอร์กราฟิกมากกว่า CPU ด้วย Divinity 2 อาจจะเหมาะ

  • สิ่งที่น่าสนใจคือ ในบรรดา 3 สถาปัตยกรรมที่รองรับในบริบทของการจำลอง x86 นั้น RISC-V เป็นตัวที่มีความสามารถในการแสดงออกต่ำที่สุด
    ในวิชาประวัติศาสตร์วิทยาการคอมพิวเตอร์ เราเรียนว่า RISC คือคอมพิวเตอร์ชุดคำสั่งแบบลดทอน แต่พอดูข้อเสนอโปรไฟล์ RISC-V หรือบทความต่าง ๆ ช่วงนี้ มักเห็นแนวคิดประมาณว่า “เพื่อให้มีความสามารถเทียบเท่ากัน แค่ต้องเพิ่มคำสั่งอีกไม่กี่ตัว” ผมเข้าใจว่า RISC-V เป็นทางเลือกที่สะดวกแทนแพลตฟอร์มอื่นสำหรับหลายคน แต่ก็สงสัยว่านี่หมายความว่า ความฝันของ RISC ตายไปแล้วหรือเปล่า

    • เท่าที่เข้าใจ RISC จริง ๆ ไม่ใช่ “ชุดคำสั่งที่น้อยที่สุดแบบสัมบูรณ์” แต่ใกล้กับแนวคิดว่า “อย่าใส่ฟีเจอร์ฉลาด ๆ เพื่อความสะดวกของโปรแกรมเมอร์แอสเซมบลี และถ้าเป็นไปได้ให้ปล่อยให้คอมไพเลอร์จัดการแทนซิลิคอนฝั่งฟรอนต์เอนด์”
      จากที่จำได้ตอนอ่านสเปก RISC-V เขาค่อนข้างเข้มงวดกับการไม่เพิ่มคำสั่งแบบ “คอมโบ” เพราะลำดับคำสั่งที่พบบ่อยสามารถ fuse กันได้ที่ฟรอนต์เอนด์
      สิ่งที่ RISC-V ขาดเมื่อเทียบกับ x86/ARM ดูเหมือนไม่ได้มาจากลัทธิ RISC แบบสุดโต่ง แต่เกิดจากสเปกที่เริ่มจากชิปฝังตัวพื้นฐานมาก ๆ แล้วค่อยเพิ่มส่วนขยายสำหรับ CPU แอปพลิเคชันตามกาลเวลา ใน RV32I พื้นฐานไม่มีแม้แต่การคูณจำนวนเต็มด้วยซ้ำ น่าเสียดายที่การถกเถียงเรื่อง bit manipulation และส่วนขยาย SIMD/เวกเตอร์ใช้เวลายุตินานเกินไป และผลก็คือเกิดช่องว่างของฟีเจอร์ที่กำลังพูดถึงกันตอนนี้
    • ถ้าจะสร้างชุดคำสั่งที่นักศึกษาสามารถนำไปใช้งานจริงได้ภายในหนึ่งภาคเรียน ก็จำเป็นต้องทำให้ง่ายขึ้น เช่นให้ทุกคำสั่งมีอินพุต 2 ตัวและเอาต์พุต 1 ตัว นักวิจัยที่ทดลองออกแบบโปรเซสเซอร์ก็จะทำได้ง่ายขึ้นมาก
      แต่แลกมากับการตัดคำสั่งบางอย่างที่สะดวกสำหรับประสิทธิภาพสูงออกไป
      พายป์ไลน์ที่เรียบง่ายยังมีข้อดีคือกินทรัพยากรวิศวกรรมของทีมที่ออกแบบประสิทธิภาพสูงน้อยลง ทำให้มีเวลาใช้กับการปรับแต่งมากขึ้น
      โดยทั่วไป RISC เป็น ปรัชญาการทำให้เรียบง่าย แต่ระดับของมันแตกต่างกันไป MIPS ถูกทำให้ง่ายพอ ๆ กับ RISC-V แต่ ARM และ POWER ประนีประนอมมากกว่า และดูเหมือนไม่มีปัญหาใหญ่ในการชนกับ x86 ในกลุ่มประสิทธิภาพสูง
      ตลาดของโปรเซสเซอร์ยังมีช่องเฉพาะอีกหลายแบบนอกจากการรันแอปพลิเคชัน เช่น embedded และ accelerator ในช่องเฉพาะที่เรียกว่าแอปพลิเคชันคอร์ ผมค่อนข้างมอง RISC-V ในแง่ลบ แต่ถ้ามองกว้างกว่านั้น ศักยภาพมีมาก และอาจครองช่องเฉพาะเชิงพาณิชย์บางส่วนได้ อีกทั้งยังยอดเยี่ยมในฐานะเครื่องมือเพื่อการศึกษาและวิจัย
    • ความฝันของ RISC คือการทำให้ การออกแบบ CPU เรียบง่ายขึ้น เพราะซอฟต์แวร์ส่วนใหญ่ไม่ได้เขียนด้วยแอสเซมบลีโดยตรง แต่เขียนผ่านคอมไพเลอร์
      ลักษณะของ RISC แบบคลาสสิกคือคำสั่งจัดการข้อมูลส่วนใหญ่ทำงานเฉพาะบนรีจิสเตอร์ คำสั่งหน่วยความจำส่วนมากมีเพียง load/store ไปยังรีจิสเตอร์ จึงต้องมีรีจิสเตอร์จำนวนมาก การส่งพารามิเตอร์ต้องจัดการสแตกโดยตรง ก็เลยต้องสร้างสแตกเอง และแทนที่จะมีคำสั่ง CALL/JSR ก็ทำด้วยคำสั่งพื้นฐานที่ load/store ไปยังรีจิสเตอร์ instruction pointer โดยตรง การเข้ารหัสคำสั่งคาดเดาได้และทุกคำสั่งมีขนาดเท่ากัน สถาปัตยกรรม RISC หลายแบบยังมีรีจิสเตอร์ที่อ่านได้เป็น 0 เสมอและเขียนไม่ได้ ใช้ตอนตั้งค่าเป็น 0
      วิธีนี้ได้ผล แต่ภายหลัง การประมวลผลแบบไม่เรียงลำดับ และ SIMD ทำให้ความสำคัญลดลง สตรีมคำสั่งดิบใกล้เคียงกับการประกาศเส้นทางไปสู่ผลลัพธ์ที่ต้องการ ไม่ได้หมายความว่า CPU จะรันตามนั้นจริง ๆ เบื้องหลังยังมี speculative execution, branch prediction และ register renaming ส่วน SIMD ก็คล้ายกับพื้นที่รีจิสเตอร์กว้าง ๆ และคำสั่งที่ทำงานกับค่าทั้งหมดในนั้น สุดท้ายการประมวลผลแบบไม่เรียงลำดับและ SIMD ก็เป็นฝ่ายนำ
    • ผมไม่แน่ใจว่ามีสิ่งที่เรียกว่าความฝันของ RISC หรือไม่ มีความฝันเรื่องประสิทธิภาพการใช้ทรัพยากร ความฝันเรื่องสมรรถนะ ความฝันเรื่องต้นทุน และความฝันเรื่องความซับซ้อนต่ำเมื่อเทียบกับต้นทุน·สมรรถนะ·ประสิทธิภาพ แต่มีใครบ้างที่ให้ความสำคัญกับ RISC เอง มากกว่าต้นทุน·สมรรถนะ·ประสิทธิภาพ·ความเรียบง่าย?
    • ในบริบทนี้คือการพยายามรันโค้ดที่คอมไพล์มาแล้วสำหรับ x86_64 บน RISC-V ความต้องการแบบ “เพื่อให้มีความสามารถเทียบเท่ากัน แค่ต้องมีคำสั่งเพิ่มอีกไม่กี่ตัว” จึงเกิดขึ้นเพราะกำลังพยายามรันโค้ดที่คอมไพล์มาสำหรับสถาปัตยกรรมที่มีคำสั่งเพิ่มเติมเหล่านั้นอยู่แล้ว
      ในทางทฤษฎี ถ้าคอมไพล์ ซอร์สโค้ด ต้นฉบับสำหรับ RISC ก็จะได้ไบนารีที่ต่างไปโดยสิ้นเชิง และอาจไม่ต้องใช้คำสั่งเฉพาะเหล่านั้น
      แต่ในทางปฏิบัติ คงไม่มีใครจะคอมไพล์เกมพวกนี้สำหรับ RISC-V จริง ๆ

  • ในสกรีนช็อตแสดง RAM 31GB ซึ่งมากกว่าสเปกสูงสุดของบอร์ดพัฒนาที่กล่าวถึงอย่างชัดเจน ที่นี่ใช้ตัวอื่นอยู่หรือเปล่า?

    • เป็นบอร์ดรุ่นเก่ากว่า คือ Pioneer
      ถ้าเป็นตอนนี้ น่าจะดีกว่าถ้าใช้หนึ่งในตัวเลือกล่าสุดที่มีหลายคอร์ที่เร็วกว่าและรองรับ RVA22 กับ RVV 1.0 แล้ว
    • https://milkv.io/pioneer
    • milk-v pioneer มี RAM 128GB

  • นี่คือ 86Box หรือเปล่า? สนุกดีที่ได้ย้อนนึกถึงสมัยที่ซื้อ Amstrad PC1512
    พอเพิ่มฮาร์ดการ์ด 500MB สองตัวกับส่วนขยายหน่วยความจำ 128KB จนเป็น 640KB แล้วสนุกขึ้นมาก ตอนแรกมีแค่ฟลอปปี 360KB สองไดรฟ์ และอีกไม่กี่ปีต่อมาก็เพิ่มฮาร์ดการ์ด 32MB เข้าไป ยังมี Borland TurboPascal กับ Zortech C ด้วย เป็นช่วงเวลาที่สนุกจริง ๆ

    • ไม่ใช่ นี่คือ Box64 และเป็นโปรเจกต์คนละอย่างกันโดยสิ้นเชิง
      แต่ก็ยังจำสมัยใช้ Amstrad PC1512 ได้เหมือนกัน

  • สงสัยว่าสักวันจะมีระบบที่ใส่ CPU RISC-V ขนาดใหญ่ไม่กี่ตัว พร้อม “GPU” ที่สร้างด้วย CPU RISC-V ขนาดเล็กเป็นพวงหรือไม่
    น่าจะเป็นรูปแบบที่ติดฟีเจอร์เวกเตอร์ที่เหมาะสมเข้าไป และคำถามเสริมคือ แนวทางเวกเตอร์แบบคลาสสิก แทน packed SIMD จะมีประโยชน์ใน GPU หรือไม่

  • ถ้าพูดถึงความสำเร็จทางเทคนิคที่น่าประทับใจของ Witcher 3 ก็มีพอร์ต Switch ด้วย และมันรันได้ดีจริง ๆ
    มันแสดงให้เห็นว่าการปรับแต่งทำอะไรได้มากแค่ไหน และบน PC มีทรัพยากรถูกสิ้นเปลืองไปมากเพียงใดเพราะ การปรับแต่งที่แย่

    • อีกส่วนสำคัญคือใช้เท็กซ์เจอร์และโมเดล 3D คุณภาพต่ำกว่ามาก ทำให้ใช้ RAM สำหรับแอสเซ็ตน้อยลงมาก
      มันไม่ใช่การเทียบแบบแอปเปิลกับแอปเปิล และช่วงที่แสดงบนหน้าจอก็ต่างกันมาก จึงยากที่จะสรุปว่าเป็นเพราะการปรับแต่งที่แย่บน PC
    • ถ้าลดความละเอียดเรนเดอร์เป็น 720p และในโหมดพกพาเป็น 540p ตั้งค่าต่ำกว่าขั้นต่ำอีก และเรียกประมาณ 30fps ว่าใช้ได้ PC สเปกขั้นต่ำก็สามารถรัน Witcher 3 ได้ใกล้เคียงกัน

  • หวังว่า ฟีดแบ็กในระดับ ISA แบบนี้จะถูกส่งต่อไปถึงคนฝั่ง RVI

    • ใน SIG ด้านประสิทธิภาพของสเกลาร์ มีการหารือเรื่อง คำสั่งแทรก/ดึงบิตฟิลด์ กันอยู่แล้ว
      เมื่อวานลองตรวจสอบดู [1] พบว่าตัวอย่างในบทความสามารถทำได้ด้วยคำสั่ง RISC-V 4 คำสั่งอยู่แล้ว เพียงแต่ค่อนข้างนึกออกยาก
      # a0 = rax, a1 = rbx
      slli t0, a1, 64-8
      rori a0, a0, 16
      add a0, a0, t0
      rori a0, a0, 64-16
      [1] https://www.reddit.com/r/RISCV/comments/1f1mnxf/box64_and_ri...
    • ในนี้ไม่มีอะไรใหม่เลย
      อันที่จริง การขาด การดึงบิตฟิลด์ เป็นความผิดพลาดที่ชัดเจนเกินไป จนเป็นตัวอย่างโปรดของผมที่แสดงให้เห็นว่า RISC-V ISA นั้นเหลวไหลแค่ไหน อันดับสองคือการไม่มีโหมดการระบุที่อยู่ที่สมเหตุสมผล
      การออกแบบ RISC-V ที่ดีกว่าบางส่วนจึงนำคำสั่งแบบกำหนดเองสำหรับเรื่องนี้มาใช้จริง เช่น BEXTM ของ Hazard3: https://github.com/Wren6991/Hazard3/blob/stable/doc/hazard3....