ZLUDA, dự án mã nguồn mở cho phép chạy ứng dụng CUDA trên GPU AMD

 (cgchannel.com)
3 điểm bởi GN⁺ 2024-03-06 | 1 bình luận | Chia sẻ qua WhatsApp
  • ZLUDA 3 là công nghệ mã nguồn mở nhằm chạy các ứng dụng dành cho GPU NVIDIA vốn bị ràng buộc với CUDA trên GPU AMD mà không cần chỉnh sửa
  • Ban đầu dự án bắt đầu như một triển khai thay thế CUDA cho GPU Intel, nhưng sau khi việc đánh giá từ Intel và AMD bị dừng lại, lần này mã dành cho GPU AMD đã được công khai
  • Trên Blender, có trường hợp hiệu năng tương tự backend HIP gốc, nhưng với 3DF Zephyr và RealityCapture, chúng được ghi là “much slower” trên ZLUDA, cho thấy chênh lệch lớn tùy theo từng ứng dụng
  • Khả năng chạy các ứng dụng CG chỉ dành cho NVIDIA như RealityCapture và Arnold đã được xác nhận, nhưng hỗ trợ OptiX chỉ ở mức tối thiểu trên Linux nên vẫn có hạn chế với quy trình render
  • Khi không có sự hỗ trợ từ Intel và AMD, dự án được xem là gần với trạng thái “realistically now abandoned”, và giấy phép SDK của NVIDIA cũng hạn chế việc phát triển lớp chuyển đổi cho nền tảng không phải NVIDIA

Vấn đề phụ thuộc CUDA mà ZLUDA 3 muốn giải quyết

  • ZLUDA 3 là dự án mã nguồn mở cho phép chạy các ứng dụng GPU được tạo cho GPU NVIDIA trên phần cứng của nhà sản xuất khác
  • Dự án được thiết kế để chạy ứng dụng hiện có trên phần cứng mới mà không cần chỉnh sửa, nên không yêu cầu nhà phát triển ứng dụng phải thực hiện thêm công việc porting
  • ZLUDA lần đầu được giới thiệu vào năm 2020 như một triển khai thay thế CUDA dạng drop-in cho GPU Intel, nhưng sau phiên bản 2 năm 2021 thì việc tiếp tục phát triển trở nên khó khăn
  • Năm 2021, khi Andrzej Janik còn làm việc tại Intel, Intel đã đánh giá ZLUDA như một ứng viên công nghệ chính thức, nhưng kết luận rằng “không có cơ sở kinh doanh để chạy ứng dụng CUDA trên GPU Intel”
  • Sau khi rời Intel vào năm 2022, Janik đã tiếp cận AMD, và AMD cũng đánh giá ZLUDA trong 2 năm nhưng quyết định không tiếp tục
  • Sau đó, mã đã được cập nhật và công bố mã nguồn mở, và có thể xem thêm bối cảnh liên quan trong bài viết của Phoronix

Phạm vi hoạt động đã được xác nhận trong các ứng dụng CG

  • ZLUDA 3 nhắm tới việc chạy các ứng dụng GPU được phát triển bằng API CUDA của NVIDIA trên GPU AMD
  • Trong các lĩnh vực VFX, motion graphics và trực quan hóa, một số ứng dụng CG cốt lõi và renderer vẫn dựa trên CUDA nên trên thực tế vẫn chỉ dành cho NVIDIA
  • HIP của AMD là công nghệ để port ứng dụng CUDA sang phần cứng AMD, nhưng cần có công việc từ phía nhà phát triển phần mềm
    • HIP được dùng trong các phiên bản tương thích AMD của Redshift và Blender Cycles
    • ZLUDA 3 cũng được xây dựng dựa trên HIP, nhưng mục tiêu là chạy ứng dụng CUDA hiện có mà không cần chỉnh sửa
  • Phần mềm chỉ dành cho NVIDIA mà Janik đã thử nghiệm với ZLUDA gồm 3DF Zephyr, RealityCapture và Autodesk Arnold
  • Hỗ trợ Arnold mới ở mức proof of concept, và số cảnh được render thành công bằng triển khai OptiX của ZLUDA còn hạn chế

Giới hạn thực tế về hiệu năng và khả năng tương thích

  • Janik đánh giá rằng các ứng dụng CUDA chạy trên GPU AMD với hiệu năng ở mức “near-native performance”
  • Theo benchmark của Phoronix và chủ đề trên diễn đàn Blender Artists, có trường hợp hiệu năng của ZLUDA trong Blender tương tự backend HIP gốc
  • Ngược lại, kho GitHub của ZLUDA ghi 3DF Zephyr và RealityCapture là much slower khi chạy trên ZLUDA
  • Nhiều GPU renderer ngoài CUDA còn dùng OptiX của NVIDIA để tăng tốc ray tracing
    • Hỗ trợ OptiX của ZLUDA ở mức “minimum”
    • Hỗ trợ OptiX chỉ có trên Linux và không có trên Windows
    • Trạng thái triển khai là “buggy, unoptimized and incomplete”
    • ZLUDA-OptiX không nằm trong bản phân phối dựng sẵn nên phải tự biên dịch
  • Khả năng chạy các ứng dụng CG khác dựa trên CUDA rất khó đánh giá nếu không có thử nghiệm từ người dùng

Tính bền vững của dự án và các ràng buộc giấy phép

  • Janik cho rằng nếu không có hỗ trợ từ Intel hoặc AMD, ZLUDA ở trạng thái “realistically now abandoned”
    • Ông vẫn để ngỏ các đề xuất có thể giúp dự án tiến triển
    • Nếu không, nhiều khả năng ông chỉ bổ sung hỗ trợ cho các công nghệ NVIDIA mà cá nhân quan tâm như DLSS
    • Mã hiện tại cũng có thể hữu ích cho các nhà phát triển phần mềm đang thực hiện porting dần dần từ CUDA sang HIP
  • Theo cập nhật ngày 14/03/2024, Tom’s Hardware chỉ ra rằng điều khoản giấy phép SDK của NVIDIA cấm dùng các đầu ra SDK, bao gồm CUDA Toolkit, để phát triển công nghệ chuyển đổi cho nền tảng không phải NVIDIA
  • Phiên bản biên dịch sẵn của ZLUDA 3 được cung cấp cho Windows và Linux, còn mã nguồn được phát hành theo Apache 2.0 hoặc MIT license
  • Có thể tải ZLUDA 3 từ kho GitHub của dự án

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-03-06
Ý kiến trên Hacker News

  • 22 ngày trước cũng đã có một thảo luận liên quan: bài viết [0] nói rằng AMD đã tài trợ cho một triển khai thay thế trực tiếp CUDA dựa trên ROCm, rồi sau đó được công bố mã nguồn mở, đã nhận 400 bình luận
    Bình luận cấp cao đáng chú ý trong luồng đó nói rằng việc công bố này thực ra là kết quả của việc AMD ngừng tài trợ: “Sau 2 năm phát triển và rà soát, AMD kết luận rằng việc chạy các ứng dụng CUDA trên GPU AMD không có tính khả thi về mặt kinh doanh. Một trong các điều khoản trong hợp đồng với AMD là nếu AMD cho rằng nó không phù hợp để phát triển thêm, tôi có thể công bố nó. Và thế là có ngày hôm nay.” Nguồn: https://github.com/vosen/ZLUDA?tab=readme-ov-file#faq
    [0] https://news.ycombinator.com/item?id=39344815

  • Việc AMD cắt tài trợ cho dự án này thật sự vô lý. Vì ngay khi được công bố mã nguồn mở, nó đã bắt đầu tạo giá trị cho người dùng AMD
    Những việc như thế này lẽ ra phải là ưu tiên hàng đầu của AMD, vậy mà họ lại loay hoay suốt nhiều năm với hai, giờ là ba thì phải, API thay thế được hỗ trợ rất hạn chế

    • Ngay khi thứ này trở thành một lựa chọn đáng tin cậy, Nvidia sẽ lập tức gửi lệnh ngừng và chấm dứt rồi kiện. Với tư cách một giải pháp nghiêm túc thì đây là ngõ cụt, nên xét trong bối cảnh đó thì cũng có thể hiểu được
    • Cũng có thể là vì họ muốn khiến mọi người dùng HIP
      “HIP rất mỏng, nên hầu như không có hoặc hoàn toàn không có tác động hiệu năng so với việc viết trực tiếp ở chế độ CUDA”
      “Công cụ HIPIFY tự động chuyển đổi mã nguồn CUDA sang HIP”
      1. https://github.com/ROCm/HIP
    • Nếu nghĩ về mặt chiến lược, khó có thể nói đây là lựa chọn tốt nhất cho AMD. Nếu nó không ở cấp độ sản phẩm và chưa được kiểm chứng về pháp lý, thì nó chỉ trở thành công cụ để lập trình viên tạo ứng dụng trên AMD rồi triển khai trên Nvidia
      Ở mảng card đồ họa tiêu dùng, nó có thể mang lại lợi ích ngắn hạn, nhưng về dài hạn thì gần như là một nước đi tự hại, tiếp tục củng cố vị thế của Nvidia trong trung tâm dữ liệu
    • Rất có thể họ đã nhận được thông tin trước về thông báo của NVIDIA và thả nhà thầu này ra. Theo điều khoản hợp đồng, dự án sẽ trở thành mã nguồn mở
    • Ở đây đang có giả định rằng AMD đã chọn bỏ cuộc. Biết đâu họ đang làm một thứ tốt hơn thì sao?

  • Trong cuộc thảo luận này, bài viết “Nvidia cấm sử dụng lớp chuyển đổi để chạy phần mềm CUDA trên các chip khác” cũng có vẻ liên quan [1]

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

    • Nếu không dùng phần cứng Nvidia, không dùng driver Nvidia, và cũng chưa từng đồng ý với EULA của Nvidia, thì tôi không hiểu vì sao phải bận tâm
      Emulation được bảo vệ về mặt pháp lý cả trong văn bản lẫn án lệ. Việc sao chép API nhằm mục đích tương thích đã lên tới Tòa án Tối cao Mỹ và từng được phán quyết là không thuộc đối tượng bản quyền. Ít nhất là trong một phạm vi khá rộng, tôi nghĩ vậy
      Tôi không phải luật sư, nhưng không thấy rõ Nvidia kỳ vọng dựa vào cơ sở pháp lý nào. Nếu là cá nhân hay công ty hoàn toàn không có phần cứng Nvidia, đây có vẻ là một vấn đề vô nghĩa. Nếu là công ty đã có phần cứng Nvidia thì họ có thể đưa ra lập luận ở mức nào đó, nhưng như thế chẳng phải lại đi thẳng vào phạm vi hành vi phản cạnh tranh sao?
    • Tôi không hiểu chuyện này khác gì Wine/Proton. EULA của Microsoft chắc cũng có điều khoản tương tự, và nếu có thể thực thi thì chẳng phải Microsoft đã gửi lệnh ngừng và chấm dứt tương tự cho các nhà phát triển Wine rồi sao?
    • Cần nhấn mạnh lại rằng điều khoản đó, trái với tuyên bố trong bài báo, đã có trong CUDA EULA từ tháng 1/2022, và trái với phần cập nhật của bài báo, nó cũng đã được bao gồm trong bản tải xuống
    • Điều đó có ý nghĩa gì không? Không cần xin phép ai để triển khai một hệ thống có giao diện tương thích với hệ thống khác
      Dù có vi phạm EULA, nhưng miễn là không tải phần mềm CUDA thì cũng không cần đồng ý với EULA, và các tác giả ZLUDA có lẽ đã có thể tránh được chuyện đó
    • NVIDIA không có quyền làm vậy. Ở đây không có NVIDIA SDK nào tham gia

  • “Rốt cuộc Intel cũng kết luận rằng ‘việc chạy các ứng dụng CUDA trên GPU Intel không có tính khả thi về mặt kinh doanh’”, nghe thật khó xử

    • Nói ngắn gọn, mọi công ty đạt đến một quy mô và độ tuổi nhất định đều bắt đầu mơ làm kẻ độc quyền hơn là mơ cạnh tranh
    • Mảng đồ họa của Intel tệ đến mức vì ấn tượng xấu còn đọng lại trong miệng mọi người, họ đã phải ngừng dùng tên Intel HD

  • Một sự thật mà bất kỳ ai từng đụng đến GPGPU của AMD dù chỉ một lần đều biết đã được xác nhận. Thứ duy nhất ngăn AMD trở thành công ty trị giá 2 nghìn tỷ USD thật sự là phần mềm tệ hại
    Tôi nhớ mình từng tìm ra lỗi trong trình biên dịch OpenCL của AMD [1], và việc làm trình biên dịch OpenCL chết vì lỗi segmentation cũng rất dễ. Lỗi đó cuối cùng không được sửa nên tôi bỏ cuộc, không báo cáo nữa
    Việc AMD không phát triển một đối thủ của CUDA là quyết định thiển cận nhất mà tôi từng thấy. Tôi không hiểu vì sao hội đồng quản trị chưa bị thay thế bằng những người hiểu rằng dù có làm ra phần cứng tốt nhất, nếu phần mềm dùng nó — nói nhẹ nhàng nhất — là thảm họa, thì sẽ chẳng ai mua hay dùng cả
    Là khách hàng, chúng ta buộc phải mua card Nvidia đắt đỏ vì hội đồng quản trị AMD quá giàu để bận tâm đến khoảng 1 nghìn tỷ USD giá trị mà họ đã bỏ lại trên bàn. Nếu bạn sở hữu cổ phiếu AMD, bạn nên đặt câu hỏi. Hội đồng đó nên bị cuốn xuống cái cống gần nhất
    [1] https://github.com/msoos/amdmiscompile -- cuối cùng lỗi này đã được sửa

    • Có thể giải thích GPGPU là gì như thể đang giải thích cho JavaScript không?
      Theo cách hiểu ngây thơ của tôi, card đồ họa là một cái máy tính kỳ lạ mà ta có thể nạp lệnh và dữ liệu lên rồi để nó tự tính toán
      Tôi không hiểu vì sao CUDA lại là chuyện lớn đến vậy. AMD không thể cho phép truy cập trực tiếp GPU của họ như một mảng gồm 4096 bo Arduino sao?
    • Đúng vậy. Ngược lại, AMD nói chung thân thiện với mã nguồn mở hơn Nvidia. Nvidia từng chủ động thù địch trong một thời gian, chỉ cần xem video Linus nói “F* you!” là đủ
      Các công ty phát triển phần cứng thường kém về phần mềm. Có ngoại lệ, nhưng không nhiều, và những công ty đó thực sự đã được thị trường chứng khoán tưởng thưởng. Tôi không biết văn hóa bộ phận phần mềm của AMD ra sao, nhưng thường muốn sửa những chuyện như thế này cần thay đổi khá lớn
      Chỉ thay hội đồng quản trị có lẽ khó mà giải quyết được. Nếu chỉ đạo của ban điều hành cấp cao không phải là yếu tố duy nhất kéo công ty đi xuống, thì cần thay đổi nhiều tầng quản lý hơn rất nhiều, và cũng phải thay khá nhiều quản lý cấp trung. Nếu tuyển dụng phần mềm không tốt, đôi khi còn phải thay cả những người đóng góp cá nhân
    • Tôi không hiểu vì sao AMD không hợp tác với Intel để thúc đẩy SYCL thành cách lập trình GPGPU và lập trình dị thể tiêu chuẩn
      Intel giỏi phần mềm, SYCL là tiêu chuẩn mở nên cả hai công ty đều có thể hưởng lợi từ cùng một mã nguồn, và khách hàng nếu muốn cũng có thể chạy mã SYCL trên Threadripper. Một số Threadripper ngày nay thậm chí nhanh ngang vài GPU
      AMD đang muốn tạo hệ sinh thái khóa độc quyền của riêng mình à? Tôi không hiểu vì sao họ không cam kết với một tiêu chuẩn mở đa nền tảng
    • Bản thân tôi khá thích AMD Software. Khi game hoặc phần mềm không hỗ trợ sẵn, việc giới hạn tốc độ khung hình ở 60 để ngăn GPU chạy hết công suất rất dễ, và cũng có thể gán phím tắt cho tính năng phát lại tức thì luôn ghi lại vài phút gần nhất, giống Shadowplay
      Khi UPS không tốt, tôi cũng có thể giới hạn điện năng GPU, và có thể tự động ép xung để cố dùng RX 580 thêm khoảng một năm nữa
      Tuy nhiên phần mềm/driver từ khoảng sau năm 2020 làm các tựa VR bị crash chưa đầy một giờ. Cũng không có gói phần mềm cho Linux, còn CoreCtrl thì không tốt bằng. Tính năng phát lại tức thì đôi khi đơn giản là không hoạt động. Tôi chưa từng kết nối ROCm với LLM cục bộ một cách ổn thỏa trên cả Windows lẫn Linux, và DKMS thì cứ mỗi lần apt upgrade lại thích biên dịch vô số thứ vô ích
      Tôi đang phân vân GPU tiếp theo sẽ là Intel Arc vì tò mò, hay cứ quay lại Nvidia. Các ứng viên khoảng A580, RX 6600, RTX 3050, và cũng có thể tôi sẽ cố cầm cự đến khi giá các linh kiện khác giảm

  • Có ngôn ngữ lập trình nào biên dịch ra nhiều ngôn ngữ kernel như Metal, CUDA, hay thứ gì đó phía AMD không? Nếu không thì vì sao chưa có?
    Trình biên dịch C biên dịch sang nhiều kiến trúc CPU khác nhau. Chẳng phải cũng nên có trình biên dịch sang các kiến trúc GPU sao? Có thể chỉ là chưa ai làm thôi

    • Tính cả OpenCL vào thì được không?
      https://www.khronos.org/api/opencl
    • OpenMP 5 đã nêu rõ hỗ trợ GPU. Tìm sơ qua thì có vẻ một số trình biên dịch hiện đã hỗ trợ ít nhất một phần

  • Có ai đã thử dùng cái này để chạy các công cụ đo ảnh mã nguồn mở như Meshroom chưa? Bài viết có nhắc tới vài công cụ độc quyền, nhưng nhu cầu của tôi khá nhỏ

  • Chuyện này trông gần như y hệt vụ Oracle kiện Google xoay quanh việc dùng bytecode JVM

    • Tôi không thấy giống vậy. Vấn đề không phải là chuyển đổi bytecode, mà là buộc sở hữu trí tuệ của thư viện ở mức cao hơn phải gắn với phần cứng
      Nó giống việc Google nói “ứng dụng Android của chúng tôi chỉ có thể chạy trên điện thoại được Google phê duyệt” hơn. Theo tôi hiểu thì Google thực sự đang làm vậy với những thứ như framework Play hay Maps

  • Gần đây tôi nghe một tin đồn thú vị rằng người phụ trách CUDA ở NVIDIA đã phải đấu tranh suốt nhiều năm để có được nguồn lực và thuyết phục công ty nghiêm túc với dự án này
    Nếu không có CUDA, NVIDIA tuyệt đối sẽ không thể trở thành công ty gần 1 nghìn tỷ USD như ngày nay

  • Việc geohot liên tục vật lộn với GPU AMD đắt tiền cũng có liên quan: https://twitter.com/tinygrad/status/1764734675002810622