كيفية التحقق من أن وحدة معالجة الرسومات المدمجة لا تزال متاحة بعد تحديث النواة

تظل وحدة معالجة الرسومات المدمجة متاحة فقط عندما تكتشفها النواة الجديدة، وتربط برنامج التشغيل الصحيح بها، وتنشئ عقد العرض، وتتيحها لحِمل العمل.

بعد تحديث نواة خادم منزلي، قد يعود تطبيق الوسائط إلى المعالجة البرمجية رغم بقاء خيار تسريع الأجهزة مفعّلًا. قد يحدث الفشل أثناء اكتشاف PCI، أو ربط وحدة النواة، أو تحميل البرامج الثابتة، أو إنشاء جهاز DRM، أو تهيئة VA-API، أو ضبط أذونات الجهاز، أو تعيين الأجهزة في Docker، أو مسار FFmpeg الخاص بخادم الوسائط. تحقّق من هذه الطبقات بالترتيب، وقارنها بعملية الإقلاع السابقة قبل تغيير إعدادات التطبيق.

سجّل النواة الجديدة وتحقّق من وحدة iGPU على ناقل PCI

سجّل إصدار النواة قيد التشغيل، والنوى السابقة المثبتة، ومعلمات الإقلاع، ووقت التحديث. ثم اعرض أجهزة PCI من فئة العرض مع المعرّفات الرقمية وبرنامج تشغيل النواة المرتبط حاليًا بوحدة GPU المدمجة.

إذا كانت وحدة iGPU غائبة عن تعداد PCI، فتحقّق من إعدادات البرامج الثابتة أو BIOS قبل تصحيح أخطاء VA-API. قد لا يعرض الخادم سوى وحدة GPU منفصلة عند تعطيل خيار iGPU أو تعدد الشاشات، كما ظهر في حالة اختفاء iGPU من Linux.

قارن معرّف الجهاز وبرنامج التشغيل المرتبط بآخر عملية إقلاع معروفة بأنها سليمة. في أنظمة Intel يكون البرنامج غالبًا i915 أو، في المسارات الأحدث المدعومة، xe؛ استخدم برنامج التشغيل المقصود فعليًا للأجهزة والتوزيعة، بدل فرض اسم وحدة من منصة أخرى.

اقرأ سجلات النواة بحثًا عن تهيئة برنامج التشغيل والبرامج الثابتة

ابحث في سجل الإقلاع الحالي عن برنامج تشغيل GPU، وDRM، والبرامج الثابتة GuC أو HuC، وتهيئة العرض، وفشل الاكتشاف، وانتهاء المهلات، والقوائم السوداء للوحدات. قارن الرسائل نفسها من النواة السابقة إذا كانت السجلات الدائمة متاحة.

قد يفشل برنامج تشغيل الوسائط حتى عند ظهور الأجهزة في القائمة. توثّق إحدى مشكلات Intel فشل تهيئة VA-API على وحدة GPU مدمجة من نوع Xe-LPG بعد تغيّر حزمة البرامج المحيطة، ما يوضح أن اكتشاف العتاد وحده لا يكفي.

تأكّد من بقاء حزم البرامج الثابتة المطلوبة ومن عدم حظر الوحدة بواسطة معلمة نواة جديدة أو قائمة سوداء أو سياسة الإقلاع الآمن. لا تُعد تثبيت خادم الوسائط قبل تهيئة برنامج تشغيل المضيف بنجاح ونظافة.

تأكّد من استمرار وجود عقدة عرض DRM

افحص /dev/dri وسجّل الأرقام الرئيسية والفرعية، والمالكين، والمجموعات، وأهداف الروابط الرمزية لكل بطاقة وعقدة عرض. لا تفترض أن وحدة iGPU ستظل دائمًا renderD128 عند وجود وحدة GPU أخرى.

يفشل تسريع الأجهزة عندما يستهدف FFmpeg عقدة موجودة لكنها لم تعد توفر شاشة VA صالحة. يعرض تقرير Jellyfin الخطأ الحاسم: لا توجد شاشة VA لجهاز العرض.

اربط عقدة العرض بجهاز PCI المقابل لها عبر sysfs، ثم حدّث إعدادات الحاوية أو التطبيق فقط إذا تغيّرت هوية العقدة فعلًا. تجنّب الأذونات الواسعة مثل الوضع 777؛ وحافظ على نموذج مجموعة العرض، وتحقّق من عضوية حساب الخدمة فيها.

-15% OFF

ZimaBoard 2 - خادم منزلي صغير لأفكارك الكبيرة

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

اختبر VA-API أو Quick Sync على المضيف قبل Docker

شغّل أداة تشخيص VA-API الخاصة بالتوزيعة على عقدة العرض التي تم التحقق منها، وسجّل اسم برنامج التشغيل، وإصدار VA-API، وملفات فك الترميز المدعومة، ونقاط إدخال الترميز، وإمكانات معالجة الفيديو.

يجب أن يتوافق برنامج تشغيل الوسائط في مساحة المستخدم مع جيل الأجهزة وواجهة النواة. تؤكد حالة Linux محلولة أن وحدات DRM الخاصة بالنواة وبرامج تشغيل DRI أو VA في مساحة المستخدم طبقتان منفصلتان؛ وقد يؤدي الخلط بينهما إلى ترك برنامج تشغيل مساحة المستخدم الخاطئ قيد الاستخدام.

إذا فشل VA-API على المضيف، فقارن حزم media-driver والبرامج الثابتة الحالية بإصدارات ما قبل التحديث. وإذا نجح VA-API على المضيف، فأبقِ النواة وبرنامج التشغيل دون تغيير أثناء الانتقال إلى حدود الحاوية.

تحقّق من الجهاز والمجموعات نفسيهما داخل الحاوية

افحص الأجهزة ومعرّفات المجموعات وإمكانية الوصول إلى عقدة العرض المختارة داخل الحاوية قيد التشغيل. شغّل أداة تشخيص VA-API المضمّنة في خادم الوسائط أو إصدار FFmpeg داخله، لأن نجاح المضيف لا يثبت نجاح الحاوية.

قد تتلقى الحاوية /dev/dri/renderD128 ومع ذلك تفشل لأن العملية لا تملك إذن مجموعة العرض المطابق. يوضح تقرير عن حاوية Jellyfin أن كلاً من تعيين الجهاز والوصول إلى المجموعة يجب التحقق منه.

قارن معرّفات المجموعات الرقمية على المضيف وداخل الحاوية، ثم أعد إنشاء الخدمة مع إعدادات صريحة للجهاز والمجموعة عند الحاجة. يقدّم دليل ZimaSpace حول التحقق من تحويل الترميز العتادي الدليل التالي على مستوى التطبيق.

أجرِ اختبارًا صغيرًا لبرنامج ترميز وراقب محركات GPU الفعلية

استخدم عينة H.264 أو HEVC معروفة بسلامتها، وفرض تحويل ترميز للفيديو من دون ترجمة أو تحويل للمدى الديناميكي العالي. سجّل حالة لوحة المعلومات، وأمر FFmpeg، وسرعة التحويل، واستخدام CPU، ونشاط محرك فك الترميز أو الترميز في GPU.

قد يبلّغ خادم الوسائط عن دعم الأجهزة، لكنه يختار جهاز VA-API الخطأ تلقائيًا. توثّق إحدى مشكلات Jellyfin حالة غيّر فيها تحديد الجهاز صراحةً ما إذا كان FFmpeg يكتشف مسار التسريع.

اختبر فك الترميز والترميز كلًّا على حدة متى أمكن. إذا فشل أحد برامج الترميز بينما عمل برنامج أساسي، فهذا يعني أن iGPU متاحة، لكن ملف التعريف أو ميزة البرامج الثابتة أو مسار برنامج التشغيل أو المرشح غير مدعوم. لا تعتبر GPU بأكملها مفقودة بسبب فشل واحد متقدم في تحويل المدى الديناميكي.

استخدم النواة السابقة للمقارنة المنضبطة

إذا فشل اكتشاف PCI أو عقد العرض أو VA-API على المضيف فقط مع النواة الجديدة، فأقلِع باستخدام النواة السابقة المثبتة من دون تغيير صورة الحاوية أو إصدار خادم الوسائط أو إعدادات مساحة المستخدم.

توصي إحدى حالات استكشاف أخطاء Jellyfin بالرجوع إلى النواة باعتباره أبسط وسيلة للتمييز عندما يُشتبه في ارتباط الفشل بتغيير في النواة. وتكمن القيمة في مقارنة منضبطة بين النواتين، لا في اعتبار الرجوع إلى إصدار سابق حلًا دائمًا.

يكتمل التحقق عندما تعرض النواة الحالية iGPU على PCI، وتربط برنامج التشغيل المقصود، وتنشئ عقدة العرض الصحيحة، وتهيّئ VA-API، وتتيح الجهاز داخل الحاوية، وتسرّع اختبارًا فعليًا لبرنامج ترميز. إذا كانت النواة السابقة وحدها تنجح، فأبقِها خيار إقلاع مؤقتًا إلى أن تُعزل المشكلة في النواة أو البرامج الثابتة أو media-driver.