۲۴ ثانیه در مقابل ۶ ثانیه؛ این تمام چیزی است که برای درک جهش سرعت در رندرینگ تصاویر سه-بعدی نیاز دارید. اگر امروز برای ثبت اسکرینشات از صفحات WebGL سنگین زمان زیادی منتظر میمانید، یک تغییر ساده در تنظیمات مرورگر میتواند بازی را عوض کند. در ۲۹ ژوئن ۲۰۲۶، شرکت Microlink جزئیات فنی روشی را منتشر کرد که با آن زمان رندرینگ را ۷۵٪ کاهش داده و اسکرینشاتهای ناپایدار سه-بعدی را به داراییهای قابل اتکا تبدیل کرده است.
موضوع اصلی این است که امروزه WebGL در همه جا حضور دارد و قدرتبخش نقشههای سه-بعدی، پیکربازهای محصول (Product Configurators)، نمودارهای صندلی هواپیما و صفحات فرود با هنرهای مبتنی بر شیدر (shader-art) است. با این حال، این صفحات از نظر تاریخی کندترین اهداف برای ثبت اسکرینشات در Microlink بودهاند. ریشه مشکل در محیط رندرینگ است: ناوگان مرورگرهای Microlink روی گرههای لینوکسی معمولی اجرا میشوند که برای بهرهوری هزینه طراحی شدهاند. این گرهها هیچ کارت گرافیک اختصاصی (GPU) ندارند و رابط /dev/dri در آنها وجود ندارد. چون سختافزار گرافیکی در دسترس نیست، سیستم مجبور است از CPU برای شبیهسازی APIهای WebGL که مبتنی بر GPU هستند استفاده کند.
کروم مستقیماً WebGL را رندر نمیکند، بلکه این فراخوانیها را به ANGLE میسپارد. ANGLE به عنوان یک لایه ترجمه عمل میکند و WebGL را به بکاندی تبدیل میکند که پلتفرم بفهمد؛ مانند Direct3D، Metal، Vulkan یا OpenGL بومی. در یک محیط بدون GPU، ANGLE به یک رندرکننده نرمافزاری متکی است. کروم دو گزینه ارائه میدهد: گزینه پیشفرض و同梱شده یعنی SwiftShader، یا استک OpenGL سیستم که در گرههای لینوکسی همان Mesa llvmpipe است.
شکاف سرعت: SwiftShader در مقابل llvmpipe
تیم Microlink دریافت که SwiftShader بیش از حد محافظهکار است و برای هدفی به نام «رندر درست در هر جای ممکن» بهینهسازی شده است. در حالی که این رویکرد قابل اعتماد است، اما بسیار کند است. طبق دادههای آنها، یک صحنه سه-بعدی سنگین معمولاً حدود ۲۴ ثانیه زمان میبرد تا از طریق SwiftShader رندر شود، در حالی که صفحات دوبعدی مجاور تنها ۲ تا ۳ ثانیه زمان میبرند.
در مقابل، Mesa llvmpipe از نظر معماری کاملاً متفاوت است:
- کامپایل JIT: این موتور با استفاده از LLVM، شیدرهای زنده و وضعیت GL را مستقیماً به کد native x86-64 تبدیل میکند و بدین ترتیب حلقه تفسیرکننده (interpreter loop) را حذف میکند.
- پردازش موازی: ساختار آن تایلبندی شده و چندرشتهای (multi-threaded) است، که اجازه میدهد از تمام هستههای CPU موجود استفاده کند.
- بهینهسازی SIMD: با بهرهگیری از
simdWidth: 256-، llvmpipe از دستورات AVX2 استفاده میکند که بخش قابل توجهی از افزایش سرعت را تامین میکند.
این تغییر منجر به افزایش ۴ برابری سرعت رندر در حالت ایزوله شد. تحت بار واقعی تولید، جایی که کپچرها در استفاده از هستهها با هم رقابت میکنند، این فاصله کمتر میشود اما همچنان معنادار است: در حالی که SwiftShader روی عدد ثابت ۲۴ ثانیه میماند، llvmpipe تنها ۷ تا ۱۴ ثانیه زمان میبرد.
مکانیسم پیادهسازی
برای دستیابی به این بهینهسازی، Microlink تنها یک خط از پیکربندی را تغییر داد: جایگزینی --use-angle=swiftshader با --use-angle=gl. با این حال، تیم فنی هشدار میدهد که دو تله رایج در آموزشهای Headless را به کار نبرید:
- عدم استفاده از
--disable-gpu: این پرچم در بسیاری از آموزشها کپی شده است اما بهطور خاموش مرورگر را به SwiftShader باز میگرداند. - عدم استفاده از
--in-process-gpu: این گزینه باعث نابودی سطح GL (GL surface) میشود که ANGLE برای عملکرد صحیح به آن نیاز دارد.
از آنجا که پرچم --use-angle=gl باید به یک سطح GL متصل شود، حتی در حالت Headless به یک نمایشگر X نیاز دارد. بدون آن، WebGL بهطور خاموش به یک «جایگزین دوبعدی تخت» (flat 2D fallback) تنزل مییابد. در این حالت، درخواست همچنان پاسخ ۲۰۰ OK میدهد و اسکرینشات گرفته میشود، اما خروجی اشتباه است. برای حل این مشکل، هر کانتینر قبل از شروع کروم، یک نمایشگر مجازی از طریق Xvfb بوت میکند و متغیر محیطی LIBGL_ALWAYS_SOFTWARE=1 برای تثبیت Mesa روی llvmpipe تنظیم میشود.
حل مشکل وابستگیها
بستههای استاندارد Ubuntu Jammy برای Mesa برای این بهینهسازی بیش از حد قدیمی بودند و PPAهای لازم برای بکپورت کردن نیز از بین رفته بودند. برای دور زدن این مشکل، Microlink اقدام به کامپایل Mesa از سورس-کد در یک Dockerfile چندمرحلهای کرد.
این بیلد از یک تولچین عظیم شامل LLVM، clang، Rust و تقریباً ۱۶۰ بسته -dev استفاده میکند. پیکربندی دقیق مورد استفاده به این صورت است:meson setup build \ -Dbuildtype=release -Dgallium-drivers=llvmpipe -Dvulkan-drivers= \ -Dllvm=enabled -Dshared-llvm=enabled
آنها با کامپایل تنها llvmpipe و LLVM مشترک (که سرعت JIT در آن نهفته است) و حذف درایورهای Vulkan، حجم تصویر نهایی را از ۴.۵ گیگابایت به ۲.۶۵ گیگابایت کاهش دادند، زیرا فقط آرتیفکتهای ضروری را به یک تصویر پاک منتقل کردند.
تایید مسیر سریع (Fast Path)
رندرینگ نرمافزاری اغلب بهطور خاموش شکست میخورد. از آنجا که گزارشهای apt list هنگام نصب دستی Mesa غیرقابل اعتماد هستند، Microlink ابزاری به نام browserless.report() را برای کوئری مستقیم از کانتکست زنده GL طراحی کرد.
- تحلیل بلوک GPU: گزارش مقدار
gpu.type(که بایدsoftwareباشد) وgpu.device(که حتماً بایدllvmpipeباشد) را بررسی میکند. اگرswiftshaderنشان داده شود، سیستم به حالت پیشفرض بازگشته و اگرhardwareباشد، یک GPU ظاهر شده است. - نسخهبندی Mesa: نسخه از طریق فایل
libgallium-<ver>.soبارگذاری شده خوانده میشود، نه ازdpkg؛ تا اطمینان حاصل شود نسخه نصب شده دستی فعال است. - بنچمارک قطعی: استفاده از
report({ benchmark: true })یک بنچمارک شیدر ثابت را اجرا میکند. این کار در llvmpipe حدود ۳۰۰ میلیثانیه زمان میبرد و عددی پایدار برای مقایسه گرهها فراهم میکند.
این گزارش به عنوان یک گیت در CI عمل میکند. اگر gpu.type یا gpu.device تغییر کند، بیلد فوراً شکست میخورد تا خروجی دوبعدی تخت به تولید نرود.
اندازهگیری و نتایج
تیم هفتهها با بنچمارکهای «دروغین» مبارزه کرد. ماشینهای توسعه با GPUهای واقعی در محیط تولید باعث ایجاد صفحات سیاه میشدند و تک-اجراها توسط Cold JIT یا رقابتهای First-paint منحرف میشدند. آنها کشف کردند که «جایگزین تخت» در واقع حدود ۱ ثانیه سریعتر از یک رندر صحیح ارسال میشود، که همین موضوع بنچمارکهای قطعی را ضروری کرد.
نتایج تولید (همین نمودار سه-بعدی، سختافزار بدون GPU):
| معیار | SwiftShader (قبل) | Mesa llvmpipe (بعد) |
|---|---|---|
| زمان رندر (ایزوله) | ~۲۴ ثانیه | ~۶ ثانیه (۴ برابر سریعتر) |
| زمان رندر (زیر بار) | ~۲۴ ثانیه | ۷-۱۴ ثانیه (۲ برابر سریعتر) |
| درخواستهای شکستخورده | Timeout $\rightarrow$ خطا | هیچ |
| رندرکننده فعال | SwiftShader | llvmpipe (تایید شده در CI) |
مثالهای عملی API
برای مشاهده این سازوکار در عمل، میتوانید محتوای سه-بعدی مانند مثال skinning و blending در Three.js را با استفاده از API Microlink و پارامتر screenshot.animated هدف قرار دهید:
CLI:microlink https://threejs.org/examples/webgl_animation_skinning_blending&screenshot.animated
cURL:curl -G "https://api.microlink.io" -d "url=https://threejs.org/examples/webgl_animation_skinning_blending" -d "screenshot.animated=true"
JavaScript:import mql from '@microlink/mql' \nconst { data } = await mql('https://threejs.org/examples/webgl_animation_skinning_blending', { screenshot: { animated: true } })
Python:import requests \nurl = "https://api.microlink.io/" \nquerystring = { "url": "https://threejs.org/examples/webgl_animation_skinning_blending", "screenshot.animated": "true" } \nresponse = requests.get(url, params=querystring) \nprint(response.json())
محدودیتهای OpenGL نرمافزاری
حتی با llvmpipe، رندرینگ نرمافزاری نمیتواند همه چیز را حل کند. برخی صحنههای سنگین fragment-shader ممکن است همچنان تصویر سیاه برگردانند، زیرا اسکرینشات قبل از پایان رنگآمیزی بوم (canvas) گرفته میشود. این یک مشکل زمانبندی است، نه مشکل رندرکننده.
طبق پست وبلاگی Microlink، تنها راه حلهای واقعی، گیت کردن کپچرها بر اساس رویداد اولین رنگآمیزی (First paint event) یا استقرار GPUهای واقعی است. برای هر مورد دیگری، انتقال از SwiftShader به llvmpipe، کندترین و ناپایدارترین درخواستها را به درخواستهای معمولی تبدیل کرد.
گام بعدی شما
- اگر از مرورگرهای Headless برای اسکرینشات استفاده میکنید، پرچم
--use-angle=glرا تست کنید. - برای محیطهای لینوکسی، حتماً از Xvfb برای ایجاد نمایشگر مجازی استفاده کنید.
- در صورت تجربه کندی، نسخه Mesa خود را بررسی و در صورت نیاز از نسخههای جدیدتر کامپایل شده استفاده کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما درباره تراشههای شبیهساز GPU مراجعه کنید. این تلاشها برای بهینهسازی پردازشهای سنگین، مشابه رویکردهای بهینهسازی در سایر محیطهای پردازشی است که پیشتر ابزارهای متنباز برای بهبود استنتاج مدلهای زبانی محلی معرفی شده بودند تا بهرهوری سختافزار به حداکثر برسد.
گفتگو