پیشرفت ZLUDA در اجرای CUDA

پیشرفت ZLUDA در اجرای CUDA بر روی پردازنده‌های گرافیکی AMD

در این مقاله به پیشرفت ZLUDA در اجرای CUDA میپردازیم. ZLUDA، یک لایه ترجمه CUDA که سال گذشته نزدیک بود تعطیل شود، اما توسط یک شخص ناشناس نجات یافت، این هفته به‌روزرسانی‌ای را در مورد پیشرفت فنی مداوم و توسعه تیم خود در طول فصل گذشته به اشتراک گذاشت.

این پروژه به ساخت قابلیت‌های خود برای اجرای حجم‌های کاری CUDA بر روی پردازنده‌های گرافیکی غیرNvidia ادامه می‌دهد؛ در حال حاضر، بیشتر بر هوش مصنوعی تمرکز دارد تا موارد دیگر. با این حال، کار بر روی فعال کردن پشتیبانی از PhysX 32 بیتی نیز آغاز شده است که برای سازگاری با بازی‌های قدیمی مبتنی بر CUDA مورد نیاز است.

شاید مهم‌ترین چیز برای پروژه ZLUDA این باشد که تیم توسعه آن از یک به دو توسعه‌دهنده تمام‌وقت که روی این پروژه کار می‌کنند، افزایش یافته است. توسعه‌دهنده دوم، Violet، کمتر از یک ماه پیش به این تیم ملحق شده و طبق این به‌روزرسانی، پیشرفت‌های مهمی را به ویژه در پیشبرد پشتیبانی از حجم‌های کاری مدل زبان بزرگ (LLM) از طریق پروژه llm.c ارائه کرده است.

یکی از اعضای انجمن به نام Groowy کار اولیه را برای فعال کردن پشتیبانی PhysX 32 بیتی در ZLUDA با جمع‌آوری گزارش‌های دقیق CUDA آغاز کرد که به سرعت چندین باگ را آشکار کرد. از آنجایی که برخی از این مشکلات میتوانند بر عملکرد CUDA 64 بیتی نیز تأثیر بگذارند، رفع آن‌ها به نقشه راه رسمی اضافه شد. با این حال، تکمیل پشتیبانی کامل PhysX 32 بیتی همچنان به کمک بیشتر از سوی مشارکت‌کنندگان متن‌باز متکی خواهد بود.

توسعه‌دهندگان ZLUDA روی یک پروژه آزمایشی به نام llm.c کار میکنند که یک برنامه نمونه کوچک است و سعی میکند یک مدل GPT2 را با استفاده از CUDA اجرا کند. اگرچه این آزمایش بزرگ نیست، اما مهم است زیرا این اولین بار است که ZLUDA سعی میکند هم توابع CUDA معمولی و هم کتابخانه‌های خاص مانند cuBLAS (عملیات ریاضی سریع) را مدیریت کند.

این برنامه آزمایشی 8186 فراخوانی جداگانه به توابع CUDA انجام میدهد که در 44 API مختلف پخش شده‌اند. در ابتدا، ZLUDA بلافاصله در اولین تماس خراب میشد. به لطف به‌روزرسانی‌های بسیاری که توسط Violet ارائه شده است.

اکنون میتواند تا 552‌اُمین تماس پیش رود و سپس با خطا مواجه شود. این تیم قبلاً پشتیبانی از 16 مورد از 44 عملکرد مورد نیاز را تکمیل کرده است، بنابراین به اجرای موفقیت‌آمیز کل آزمایش نزدیک‌تر میشوند. هنگامی که این کار انجام شود، به ZLUDA کمک میکند تا از نرم‌افزارهای بزرگ‌تری مانند PyTorch در آینده پشتیبانی کند.

هدف اصلی ZLUDA اجرای برنامه‌های استاندارد CUDA بر روی پردازنده‌های گرافیکی غیرNvidia است، در حالی که رفتار سخت‌افزار Nvidia را تا حد امکان دقیق مطابقت میدهد. این بدان معناست که هر دستورالعمل باید نتایج یکسانی را تا آخرین بیت ارائه دهد یا در مقایسه با سخت‌افزار Nvidia در محدوده‌های عددی دقیقی باقی بماند. ورژن‌های قبلی ZLUDA، قبل از بازنشانی اصلی کد، اغلب با صرف نظر کردن از اصلاح‌کننده‌های دستورالعمل خاص یا عدم حفظ دقت کامل، دقت را به خطر می‌انداختند.

پیاده‌سازی فعلی پیشرفت‌های چشمگیری در رفع این مشکل داشته است. برای اطمینان از دقت، تست‌های ‘sweep’ PTX را اجرا میکند بررسی‌های سیستماتیک با استفاده از زبان GPU میدرنج Nvidia تا تأیید کند که هر دستورالعمل و ترکیب اصلاح‌کننده نتایج درستی را در همه ورودی‌ها تولید می‌کند، چیزی که قبلاً هرگز استفاده نشده بود.

اجرای این بررسی‌ها چندین نقص کامپایلر را آشکار کرد که بعداً برطرف شدند. ZLUDA اعتراف میکند که هنوز هر دستورالعملی این اعتبارسنجی دقیق را به پایان نرسانده است، اما تأکید کرد که برخی از پیچیده‌ترین موارد مانند دستورالعمل cvt اکنون تأیید شده‌اند که از نظر بیتی دقیق هستند.

پایه و اساس برای به کار انداختن هر نرم‌افزار مبتنی بر CUDA بر روی ZLUDA چه یک بازی، چه یک برنامه سه بعدی یا یک چارچوب ML داشتن گزارش‌هایی از نحوه ارتباط برنامه با CUDA است، که شامل ردیابی تماس‌های مستقیم API، بخش‌های مستند نشده زمان اجرای CUDA (یا درایورها) و هرگونه استفاده از کتابخانه‌های عملکرد تخصصی است.

با به‌روزرسانی اخیر، سیستم ثبت ZLUDA به طور قابل توجهی ارتقا یافته است. پیاده‌سازی جدید طیف گسترده‌تری از فعالیت‌ها را که قبلاً قابل مشاهده نبودند، ثبت می‌کند، از جمله ردیابی دقیق رفتار داخلی، مانند زمانی که cuBLAS به cuBLASLt متکی است یا نحوه تعامل cuDNN با Driver API سطح پایین‌تر.

چارچوب‌های GPU مدرن مانند CUDA، ROCm/HIP، ZLUDA و OpenCL همگی نیاز دارند که کد دستگاه را به صورت پویا در حین اجرای برنامه‌ها کامپایل کند تا اطمینان حاصل شود که برنامه‌های GPU قدیمی‌تر همچنان میتوانند به درستی بر روی نسل‌های سخت‌افزاری جدیدتر بدون تغییر در کد اصلی ساخته و اجرا شوند.

در اکوسیستم ROCm/HIP AMD، این کامپایل درجا به کتابخانه comgr (مخفف ROCmCompilerSupport) بستگی دارد، یک کتابخانه فشرده با قابلیت‌های گسترده برای انجام وظایفی مانند کامپایل، پیوند و جداسازی کد، که هم در لینوکس و هم در ویندوز موجود است.

با ROCm/HIP ورژن 6.4، یک تغییر رابط باینری برنامه (ABI) مهم رخ داد: کدهای عددی نشان‌دهنده اقدامات در یک ABI v3 جدید مرتب شدند. این امر باعث شد که ZLUDA به طور تصادفی عملیات اشتباه را فراخوانی کند به عنوان مثال، تلاش برای پیوند به جای کامپایل، که منجر به خطا شد. وضعیت در ویندوز بدتر بود، جایی که کتابخانه ادعا می‌کرد ورژن 2.9 است اما به طور داخلی از ABI v3 استفاده می‌کرد و رفتارها را مخلوط می‌کرد. این مشکلات نیز اخیراً توسط تیم ZLUDA برطرف شده‌اند.