ZLUDA โปรเจกต์โอเพนซอร์สที่ทำให้แอป CUDA รันบน AMD GPU ได้

 (cgchannel.com)
3 คะแนน โดย GN⁺ 2024-03-06 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ZLUDA 3 เป็นเทคโนโลยีโอเพนซอร์สที่พยายามทำให้แอปพลิเคชันสำหรับ NVIDIA GPU ซึ่งเคยผูกกับ CUDA สามารถรันบน AMD GPU ได้โดยไม่ต้องแก้ไข
  • เริ่มต้นจากการเป็น implementation ทดแทน CUDA สำหรับ Intel GPU แต่หลังจาก Intel และ AMD ยุติการประเมิน ครั้งนี้จึงมีการเปิดเผย โค้ดสำหรับ AMD GPU
  • ใน Blender มีกรณีที่ประสิทธิภาพใกล้เคียงกับ backend HIP แบบ native แต่ 3DF Zephyr และ RealityCapture ถูกระบุว่า “much slower” บน ZLUDA จึงมีความแตกต่างมากตามแต่ละแอป
  • ยืนยันแล้วว่ามีความเป็นไปได้ในการรันแอป CG ที่จำกัดเฉพาะ NVIDIA อย่าง RealityCapture และ Arnold แต่ การรองรับ OptiX ยังอยู่ในระดับขั้นต่ำบน Linux ทำให้มีข้อจำกัดต่อ workflow งานเรนเดอร์
  • เมื่อไม่มีการสนับสนุนจาก Intel หรือ AMD โปรเจกต์จึงใกล้เคียงกับสถานะ “realistically now abandoned” และไลเซนส์ NVIDIA SDK ก็จำกัดการพัฒนาเลเยอร์แปลงสำหรับแพลตฟอร์มที่ไม่ใช่ NVIDIA

ปัญหาการพึ่งพา CUDA ที่ ZLUDA 3 พยายามแก้

  • ZLUDA 3 เป็นโปรเจกต์โอเพนซอร์สที่ทำให้แอปพลิเคชันบน GPU ซึ่งสร้างมาสำหรับ NVIDIA GPU สามารถรันบนฮาร์ดแวร์ของผู้ผลิตรายอื่นได้
  • ออกแบบมาให้แอปพลิเคชันเดิมรันบนฮาร์ดแวร์ใหม่ได้ โดยไม่ต้องแก้ไข จึงไม่ต้องการงานพอร์ตเพิ่มเติมจากนักพัฒนาแอป
  • ZLUDA เปิดตัวครั้งแรกในปี 2020 ในฐานะ implementation ทดแทน CUDA แบบ drop-in สำหรับ Intel GPU และหลังเวอร์ชัน 2 ในปี 2021 การพัฒนาต่อก็ทำได้ยากขึ้น
  • ในปี 2021 ขณะที่ Andrzej Janik ยังทำงานอยู่ที่ Intel บริษัทได้ประเมิน ZLUDA ในฐานะตัวเลือกเทคโนโลยีอย่างเป็นทางการ แต่สรุปว่า “ไม่มี business case สำหรับการรันแอปพลิเคชัน CUDA บน Intel GPU”
  • หลัง Janik ออกจาก Intel ในปี 2022 เขาได้เข้าหา AMD และ AMD ก็ประเมิน ZLUDA เป็นเวลา 2 ปี แต่ตัดสินใจไม่เดินหน้าต่อ
  • หลังจากนั้นโค้ดที่อัปเดตแล้วถูกเผยแพร่เป็นโอเพนซอร์ส และสามารถอ่านเบื้องหลังเพิ่มเติมได้จาก บทความของ Phoronix

ขอบเขตการทำงานที่ยืนยันในแอป CG

  • ZLUDA 3 มีเป้าหมายให้แอป GPU ที่พัฒนาด้วย API CUDA ของ NVIDIA สามารถรันบน AMD GPU ได้
  • ในสายงาน VFX, motion graphics และ visualization มีแอป CG และ renderer หลักบางตัวที่อิง CUDA จึงยังคงเป็นซอฟต์แวร์เฉพาะ NVIDIA ในทางปฏิบัติ
  • HIP ของ AMD เป็นเทคโนโลยีสำหรับพอร์ตแอป CUDA ไปยังฮาร์ดแวร์ AMD แต่ต้องอาศัยงานจากนักพัฒนาซอฟต์แวร์
    • HIP ถูกใช้ในเวอร์ชันที่รองรับ AMD ของ Redshift และ Blender Cycles
    • ZLUDA 3 ก็สร้างขึ้นบน HIP เช่นกัน แต่เป้าหมายคือการรันแอป CUDA เดิม โดยไม่ต้องแก้ไข
  • ซอฟต์แวร์เฉพาะ NVIDIA ที่ Janik ทดสอบด้วย ZLUDA ได้แก่ 3DF Zephyr, RealityCapture และ Autodesk Arnold
  • การรองรับ Arnold อยู่ในระดับ proof of concept และมีฉากที่เรนเดอร์สำเร็จด้วย implementation ของ OptiX ใน ZLUDA เพียงจำกัด

ข้อจำกัดจริงด้านประสิทธิภาพและความเข้ากันได้

  • Janik ประเมินว่าแอป CUDA รันบน AMD GPU ได้ด้วย “near-native performance”
  • ตาม benchmark ของ Phoronix และ เธรด ในฟอรัม Blender Artists มีกรณีที่ประสิทธิภาพของ ZLUDA ใน Blender ใกล้เคียงกับ backend HIP แบบ native
  • ในทางกลับกัน repository GitHub ของ ZLUDA ระบุว่า 3DF Zephyr และ RealityCapture บน ZLUDA นั้น much slower
  • GPU renderer จำนวนมากใช้ NVIDIA OptiX ควบคู่กับ CUDA เพื่อเร่งความเร็ว ray tracing
    • การรองรับ OptiX ของ ZLUDA อยู่ในระดับ “minimum”
    • การรองรับ OptiX มีเฉพาะบน Linux และไม่มีบน Windows
    • สถานะ implementation คือ “buggy, unoptimized and incomplete”
    • ZLUDA-OptiX ไม่รวมอยู่ในเวอร์ชัน redistributable จึงต้อง build เอง
  • ความเป็นไปได้ในการรันแอป CG อื่น ๆ ที่อิง CUDA นั้นประเมินได้ยากหากไม่มีการทดสอบจากผู้ใช้
    • ยังมี known issues คงอยู่
    • V-Ray benchmark รันได้ในบาง combination ที่ “lucky” ของ ZLUDA และ HIP เวอร์ชันเก่า
    • OctaneBench รันไม่ได้เลย

ความต่อเนื่องของโปรเจกต์และข้อจำกัดด้านไลเซนส์

  • Janik มองว่าหากไม่มีการสนับสนุนจาก Intel หรือ AMD ZLUDA จะอยู่ในสถานะ “realistically now abandoned”
    • ยังเปิดรับข้อเสนอที่จะช่วยผลักดันโปรเจกต์ให้เดินหน้าต่อ
    • หากไม่เช่นนั้น ก็มีแนวโน้มจะเพิ่มเฉพาะการรองรับเทคโนโลยี NVIDIA ที่เขาสนใจเป็นการส่วนตัว เช่น DLSS
    • โค้ดปัจจุบันยังอาจเป็นประโยชน์ต่อนักพัฒนาซอฟต์แวร์ที่กำลังทำ การพอร์ตแบบค่อยเป็นค่อยไป จาก CUDA ไปยัง HIP
  • ตามอัปเดตวันที่ 14 มีนาคม 2024 Tom’s Hardware ชี้ว่า เงื่อนไขไลเซนส์ SDK ของ NVIDIA ห้ามใช้ผลลัพธ์จาก SDK รวมถึง CUDA Toolkit ในการพัฒนาเทคโนโลยีแปลงสำหรับแพลตฟอร์มที่ไม่ใช่ NVIDIA
  • เวอร์ชันที่คอมไพล์แล้วของ ZLUDA 3 มีให้สำหรับ Windows และ Linux ส่วนซอร์สโค้ดเผยแพร่ภายใต้ Apache 2.0 หรือ MIT license
  • สามารถ ดาวน์โหลด ZLUDA 3 ได้จาก repository GitHub ของโปรเจกต์

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

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

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

  • มีการพูดคุยที่เกี่ยวข้องเมื่อ 22 วันก่อนด้วย: มีโพสต์ที่บอกว่า AMD สนับสนุนเงินทุนให้กับ การทำ CUDA แบบ drop-in ที่สร้างบน ROCm และหลังจากนั้นก็เปิดซอร์ส โดยโพสต์นั้นมีคอมเมนต์ 400 รายการ [0]
    คอมเมนต์ระดับบนสุดที่น่าสนใจในเธรดนั้นระบุว่า การเปิดเผยซอร์สครั้งนี้เป็นผลจากการที่ AMD หยุดสนับสนุนเงินทุนเอง: “หลังจากพัฒนาและตรวจสอบมา 2 ปี AMD ตัดสินว่าไม่มีความคุ้มค่าทางธุรกิจในการรันแอปพลิเคชัน CUDA บน AMD GPU เงื่อนไขหนึ่งในสัญญากับ AMD คือถ้า AMD เห็นว่าไม่เหมาะกับการพัฒนาต่อ ผมสามารถเปิดเผยซอร์สได้ และนั่นพาเรามาถึงวันนี้” ที่มา: https://github.com/vosen/ZLUDA?tab=readme-ov-file#faq
    [0] https://news.ycombinator.com/item?id=39344815

    • ถ้ากางโพสต์ที่เกี่ยวข้องออกมาจะได้ประมาณนี้: AMD funded a drop-in CUDA implementation built on ROCm: It's now open-source - https://news.ycombinator.com/item?id=39344815 - กุมภาพันธ์ 2024, คอมเมนต์ 410 รายการ
      Zluda: Run CUDA code on Intel GPUs, unmodified - https://news.ycombinator.com/item?id=36341211 - มิถุนายน 2023, คอมเมนต์ 90 รายการ
      Zluda: CUDA on Intel GPUs - https://news.ycombinator.com/item?id=26262038 - กุมภาพันธ์ 2021, คอมเมนต์ 77 รายการ
      และโพสต์ที่เกี่ยวข้องล่าสุดคือ Nvidia bans using translation layers for CUDA software to run on other chips - https://news.ycombinator.com/item?id=39592689 - มีนาคม 2024, คอมเมนต์ 155 รายการ
    • เงื่อนไขในสัญญาที่ว่า “ถ้า AMD เห็นว่าไม่เหมาะกับการพัฒนาต่อ ผมสามารถเปิดเผยซอร์สได้” ฟังแล้วรู้สึกว่าอยากใส่ไว้ในสัญญาของทุกงานในอนาคต

  • การที่ AMD ตัดเงินทุนโครงการนี้เป็นเรื่องเหลือเชื่อจริง ๆ เพราะทันทีที่เปิดซอร์ส มันก็เริ่มสร้าง คุณค่าให้ผู้ใช้ AMD ได้เลย
    เรื่องแบบนี้น่าจะเป็นงานลำดับต้น ๆ ของ AMD ด้วยซ้ำ แต่พวกเขากลับมัววนอยู่กับ API ทางเลือกสองตัวที่แทบไม่ได้รับการสนับสนุนมาหลายปี หรือเดี๋ยวนี้สามตัวแล้วหรือเปล่า

    • ทันทีที่สิ่งนี้กลายเป็นตัวเลือกที่น่าเชื่อถือ Nvidia ก็คงส่ง คำสั่งให้หยุดดำเนินการ และฟ้องร้องทันที มันเลยเป็นทางตันถ้าจะมองเป็นวิธีแก้ปัญหาอย่างจริงจัง ซึ่งในบริบทนั้นก็พอเข้าใจได้
    • อาจเป็นเพราะพวกเขาอยากให้คนใช้ HIP ก็ได้
      “HIP มีชั้นบางมากจนแทบไม่มีหรือไม่มีผลกระทบด้านประสิทธิภาพเลยเมื่อเทียบกับการเขียนโค้ดในโหมด CUDA โดยตรง”
      “เครื่องมือ HIPIFY จะแปลงซอร์ส CUDA เป็น HIP ให้อัตโนมัติ”
      1. https://github.com/ROCm/HIP
    • ถ้ามองเชิงกลยุทธ์ ก็ยากจะบอกว่านี่คือสิ่งที่ดีที่สุดสำหรับ AMD ถ้ามันยังไม่ถึง ระดับผลิตภัณฑ์ และยังไม่ผ่านการพิสูจน์ทางกฎหมาย มันก็เป็นแค่เครื่องมือที่ช่วยให้นักพัฒนาสร้างแอปบน AMD แล้วไปดีพลอยบน Nvidia เท่านั้น
      ฝั่งการ์ดจอผู้บริโภคอาจได้ประโยชน์ระยะสั้น แต่ระยะยาวแล้วมันแทบจะเป็นการตอกย้ำสถานะของ Nvidia ในดาต้าเซ็นเตอร์ให้แข็งแรงขึ้นเอง
    • มีความเป็นไปได้สูงว่าได้รับข้อมูลล่วงหน้าเกี่ยวกับประกาศของ NVIDIA แล้วจึงปล่อยผู้รับจ้างรายนี้ออกไป ตามเงื่อนไขในสัญญา โครงการนี้ก็น่าจะกลายเป็น โอเพนซอร์ส อยู่ดี
    • ตรงนี้ตั้งอยู่บนสมมติฐานว่า AMD เลือกจะยอมแพ้ บางทีพวกเขาอาจกำลังสร้างอะไรที่ดีกว่านี้อยู่ก็ได้ไม่ใช่หรือ?

  • ในประเด็นนี้ ดูเหมือนจะมีความเกี่ยวข้องกับโพสต์ที่ว่า “Nvidia แบนการใช้ translation layer เพื่อรันซอฟต์แวร์ CUDA บนชิปอื่น” ด้วย [1]

    [1] https://news.ycombinator.com/item?id=39592689

    • ถ้าไม่ได้ใช้ฮาร์ดแวร์ Nvidia ไม่ได้ใช้ไดรเวอร์ Nvidia และไม่เคยยอมรับ EULA ของ Nvidia เลย ก็ไม่เข้าใจว่าทำไมต้องสนใจด้วย
      การจำลองระบบได้รับความคุ้มครองทางกฎหมายอย่างชัดเจน ทั้งในตัวบทและตามบรรทัดฐานคำพิพากษา การทำซ้ำ API เพื่อความเข้ากันได้เคยขึ้นถึงศาลสูงสหรัฐฯ และมีคำตัดสินว่าไม่อยู่ภายใต้ลิขสิทธิ์ อย่างน้อยก็ในขอบเขตที่กว้างพอสมควร
      ผมไม่ใช่ทนาย แต่ก็มองไม่ค่อยออกว่า Nvidia คาดหวังฐานทางกฎหมายอะไร หากเป็นบุคคลหรือบริษัทที่ไม่มีฮาร์ดแวร์ Nvidia เลย ประเด็นนี้ก็ดูแทบไม่มีความหมาย แต่ถ้าเป็นบริษัทที่มีฮาร์ดแวร์ Nvidia อยู่แล้ว พวกเขาอาจพอมีข้ออ้างบางอย่างได้ แม้อย่างนั้นมันก็ไม่ใช่การก้าวตรงเข้าสู่พื้นที่ของพฤติกรรมต่อต้านการแข่งขันหรอกหรือ?
    • ผมไม่เห็นว่ามันต่างจาก Wine/Proton ตรงไหน ใน EULA ของ Microsoft ก็น่าจะมีเงื่อนไขคล้ายกัน ถ้าบังคับใช้ได้จริง Microsoft ก็คงส่งคำสั่งให้หยุดดำเนินการแบบเดียวกันไปยังนักพัฒนา Wine แล้วไม่ใช่หรือ?
    • ควรย้ำอีกครั้งว่าข้อกำหนดนี้มีอยู่ใน CUDA EULA มาตั้งแต่เดือนมกราคม 2022 แล้ว ไม่ใช่เพิ่งเพิ่มเข้ามาตามที่บทความกล่าวอ้าง และไม่ใช่ว่าไม่มีในส่วนดาวน์โหลดตามที่บทความอัปเดตแก้ไขภายหลัง
    • แล้วมันมีความหมายอะไร? การทำระบบหนึ่งให้มี อินเทอร์เฟซที่เข้ากันได้ กับอีกระบบ ไม่จำเป็นต้องได้รับอนุญาตจากใคร
      มันอาจเป็นการละเมิด EULA แต่ตราบใดที่คุณไม่ได้ดาวน์โหลดซอฟต์แวร์ CUDA คุณก็ไม่จำเป็นต้องยอมรับ EULA และผู้เขียน ZLUDA ก็น่าจะหลีกเลี่ยงจุดนั้นได้
    • NVIDIA ไม่มีสิทธิ์ทำแบบนั้น เรื่องนี้ไม่ได้เกี่ยวข้องกับ NVIDIA SDK

  • ฟังแล้วน่าอึดอัดที่ “สุดท้าย Intel ก็สรุปว่า ‘ไม่มีความคุ้มค่าทางธุรกิจในการรันแอปพลิเคชัน CUDA บน Intel GPU’ เช่นกัน”

    • พูดสั้น ๆ คือบริษัทที่มีขนาดและอายุมากพอ ทุกแห่งล้วนเริ่มฝันอยากเป็น ผู้ผูกขาด มากกว่าจะฝันอยากเป็นคู่แข่ง
    • ฝั่งกราฟิกของ Intel แย่มากจนภาพจำแย่ ๆ ที่คนมีต่อมันทำให้ต้องเลิกใช้ชื่อ Intel HD ไปเลย

  • ข้อเท็จจริงที่ใครก็ตามที่เคยแตะ AMD GPGPU สักครั้งย่อมรู้ ได้รับการยืนยันอีกครั้ง คือสิ่งเดียวที่ขัดขวางไม่ให้ AMD กลายเป็นบริษัทมูลค่า 2 ล้านล้านดอลลาร์ก็คือซอฟต์แวร์ที่ย่ำแย่อย่างแท้จริง
    จำได้ว่าเคยเจอบั๊กในคอมไพเลอร์ OpenCL ของ AMD [1] และการทำให้คอมไพเลอร์ OpenCL ล้มด้วย segmentation fault ก็ง่ายมากด้วย สุดท้ายมันไม่เคยถูกแก้ เลยเลิกแจ้งรายงานไป
    การที่ AMD ไม่พัฒนาคู่แข่งของ CUDA เป็นการตัดสินใจที่สายตาสั้นที่สุดอย่างหนึ่งเท่าที่เคยเห็น ต่อให้ทำฮาร์ดแวร์ที่ดีที่สุดได้ แต่ถ้าซอฟต์แวร์ที่ใช้กับมันพูดแบบสุภาพที่สุดก็ยังห่วย ก็จะไม่มีใครซื้อหรือใช้อยู่ดี ไม่เข้าใจเลยว่าทำไมบอร์ดบริหารถึงไม่ถูกเปลี่ยนออกโดยคนที่เข้าใจเรื่องนี้
    ในฐานะลูกค้า เราต้องไปซื้อการ์ด Nvidia แพง ๆ เพราะบอร์ดบริหารของ AMD รวยเกินกว่าจะสนใจมูลค่าราว 1 ล้านล้านดอลลาร์ที่ปล่อยทิ้งไว้บนโต๊ะ ถ้าคุณถือหุ้น AMD คุณควรถามคำถามนั้น บอร์ดชุดนี้ควรถูกส่งลงท่อระบายน้ำที่ใกล้ที่สุด
    [1] https://github.com/msoos/amdmiscompile -- สุดท้ายอันนี้ถูกแก้แล้ว

    • ช่วยอธิบายหน่อยได้ไหมว่า GPGPU คืออะไร แบบอธิบายให้ JavaScript ฟัง
      ตามความเข้าใจแบบใสซื่อของฉัน การ์ดจอคือคอมพิวเตอร์ประหลาดที่คุณอัปโหลดคำสั่งกับข้อมูลขึ้นไป แล้วปล่อยให้มันคำนวณเอง
      ฉันไม่เข้าใจว่าทำไม CUDA ถึงเป็นเรื่องใหญ่ขนาดนั้น AMD เปิดให้เข้าถึง GPU ของตัวเองโดยตรงเหมือนเป็นอาร์เรย์ของบอร์ด Arduino 4096 ตัวไม่ได้หรือ?
    • ใช่แล้ว ในทางกลับกัน AMD โดยทั่วไปแล้ว เป็นมิตรกับโอเพนซอร์สมากกว่า Nvidia เองก็เคยเป็นปฏิปักษ์อย่างชัดเจนอยู่พักใหญ่ แค่ดูวิดีโอ “F* you!” ของ Linus ก็พอ
      บริษัทที่ทำฮาร์ดแวร์ส่วนใหญ่มักทำซอฟต์แวร์ไม่เก่ง มีข้อยกเว้นอยู่บ้างแต่ไม่มาก และบริษัทพวกนั้นก็ได้รับผลตอบแทนในราคาหุ้นจริง ๆ ฉันไม่รู้ว่าวัฒนธรรมของฝ่ายซอฟต์แวร์ที่ AMD เป็นอย่างไร แต่ปกติการจะแก้เรื่องแบบนี้ต้องเปลี่ยนแปลงค่อนข้างใหญ่
      แค่เปลี่ยนบอร์ดบริหารอย่างเดียวคงแก้ไม่ได้ เว้นแต่ว่าคำสั่งจากผู้บริหารสูงสุดจะเป็นปัจจัยเดียวที่ฉุดบริษัทลง ซึ่งไม่น่าใช่ คุณน่าจะต้องเปลี่ยนผู้จัดการอีกหลายชั้น และผู้จัดการระดับกลางจำนวนมากด้วย ถ้าการรับคนสายซอฟต์แวร์ทำได้ไม่ดี บางครั้งก็ต้องเปลี่ยนถึงระดับ individual contributor ด้วย
    • ไม่เข้าใจว่าทำไม AMD ไม่ร่วมมือกับ Intel เพื่อผลักดัน SYCL ให้เป็นแนวมาตรฐานของการเขียนโปรแกรม GPGPU และ heterogeneous programming
      Intel ทำซอฟต์แวร์เก่ง SYCL ก็เป็นมาตรฐานเปิด ทั้งสองบริษัทจึงได้ประโยชน์จากโค้ดชุดเดียวกัน และลูกค้าก็สามารถรันโค้ด SYCL บน Threadripper ได้ด้วยถ้าต้องการ ทุกวันนี้ Threadripper บางรุ่นก็เร็วพอ ๆ กับ GPU บางตัวแล้ว
      AMD กำลังพยายามสร้างระบบนิเวศแบบผูกขาดของตัวเองงั้นหรือ? ไม่เข้าใจว่าทำไมถึงไม่ทุ่มกับมาตรฐานเปิดข้ามแพลตฟอร์ม
    • โดยส่วนตัวฉันค่อนข้างชอบ AMD Software เองนะ มันตั้ง จำกัดเฟรมเรตไว้ที่ 60 ได้ง่าย เพื่อไม่ให้ GPU วิ่งเต็มที่เวลาเกมหรือซอฟต์แวร์ไม่รองรับเอง และยังตั้ง hotkey สำหรับ instant replay แบบบันทึกไม่กี่นาทีล่าสุดไว้ตลอดเหมือน Shadowplay ได้ด้วย
      ตอนที่ UPS ไม่ค่อยดี ก็ยังจำกัดพลังงาน GPU ได้ และยังใช้ auto overclock เพื่อยืดอายุ RX 580 ออกไปอีกราวปีหนึ่งได้
      แต่ซอฟต์แวร์/ไดรเวอร์ตั้งแต่ราวปี 2020 เป็นต้นมาทำให้เกม VR แครชภายในไม่ถึงชั่วโมง อีกทั้งไม่มีแพ็กเกจซอฟต์แวร์สำหรับ Linux และ CoreCtrl ก็ไม่ดีเท่า instant replay เองก็บางครั้งไม่ทำงานเฉย ๆ ฉันเองก็ไม่เคยทำให้ ROCm ใช้งานกับ local LLM ได้อย่างถูกต้องสักครั้งทั้งบน Windows และ Linux และ DKMS ก็ชอบคอมไพล์อะไรไร้สาระเต็มไปหมดทุกครั้งที่ apt upgrade
      ตอนนี้กำลังลังเลว่า GPU ตัวถัดไปจะลอง Intel Arc เพราะความอยากรู้อยากเห็น หรือจะกลับไป Nvidia เลย ตัวเลือกที่มองไว้คือ A580, RX 6600, RTX 3050 หรืออาจจะทนใช้ไปก่อนจนกว่าราคาชิ้นส่วนอื่นจะลง

  • มีภาษาโปรแกรมที่คอมไพล์ไปเป็น ภาษาเคอร์เนล หลายแบบ เช่น Metal, CUDA หรืออะไรฝั่ง AMD ได้ไหม? ถ้าไม่มี ทำไมถึงไม่มีล่ะ?
    คอมไพเลอร์ C คอมไพล์ไปสถาปัตยกรรม CPU ได้หลายแบบอยู่แล้ว ก็น่าจะมีคอมไพเลอร์ที่ไปสถาปัตยกรรม GPU ได้เหมือนกันไม่ใช่หรือ? หรืออาจจะแค่ยังไม่มีใครทำ

    • ถ้านับ OpenCL ด้วยจะถือว่าใช่ไหม?
      https://www.khronos.org/api/opencl
    • OpenMP 5 ระบุรองรับ GPU ไว้อย่างชัดเจน ลองค้นคร่าว ๆ ดูแล้วเหมือนว่าตอนนี้คอมไพเลอร์บางตัวก็รองรับอย่างน้อยบางส่วนแล้ว

  • มีใครเคยลองใช้สิ่งนี้เพื่อรัน เครื่องมือ photogrammetry แบบโอเพนซอร์ส อย่าง Meshroom ไหม? ในบทความพูดถึงเครื่องมือแบบ proprietary อยู่บ้าง แต่ความต้องการของฉันค่อนข้างเล็ก

  • เรื่องนี้ดูแทบจะเหมือนคดี Oracle ปะทะ Google เกี่ยวกับการใช้ JVM bytecode เลย

    • ฉันว่าไม่ค่อยเหมือนนะ ประเด็นไม่ใช่การแปลง bytecode แต่เป็นการผูก ทรัพย์สินทางปัญญาระดับไลบรารี ที่อยู่ในระดับสูงกว่านั้นเข้ากับฮาร์ดแวร์
      มันคล้ายกับที่ Google บอกว่า “แอป Android ของเราจะรันได้เฉพาะบนโทรศัพท์ที่ Google อนุมัติเท่านั้น” ซึ่งเท่าที่ฉันเข้าใจ Google ก็ทำแบบนั้นจริงกับ Play framework หรือ Maps อะไรทำนองนั้น

  • เพิ่งได้ยินข่าวลือที่น่าสนใจมาไม่นานว่า คนที่รับผิดชอบ CUDA ที่ NVIDIA เคยต่อสู้อยู่นานหลายปีเพื่อให้ได้ทรัพยากรและโน้มน้าวบริษัทให้จริงจังกับโครงการนี้
    ถ้าไม่มี CUDA ก็ไม่มีทางเลยที่ NVIDIA จะกลายเป็นบริษัทเกือบ 1 ล้านล้านดอลลาร์ได้ในวันนี้

  • เรื่องนี้ยังเกี่ยวข้องกับที่ geohot ต้องมาสู้กับ AMD GPU ราคาแพงอย่างต่อเนื่องด้วย: https://twitter.com/tinygrad/status/1764734675002810622