منذ عامين، اتجهت نحو استخدام نظام التشغيل لينكس على جهاز الكمبيوتر الخاص بي المخصص للألعاب. لطالما سمعت آراء تفيد بأنه يمكن أن يقدم أداءً أفضل بكثير من ويندوز فيما يتعلق بمعدل الإطارات في الثانية (FPS)، واتساق أوقات الإطارات، وزمن وصول الإدخال. وعندما قمت بتجربته، شعرت بفرق كبير وتحسن ملحوظ.
الإنترنت مليء بالنصائح حول تحسين لينكس للألعاب:
- وايلاند لديه تأخر إدخال سيء، استخدم X11.
- تعطيل التركيب (باستخدام وضع القلب المباشر).
- استخدام نسخة محسنة من DXVK ذات زمن وصول منخفض.
- استخدام جدولة نواة مخصصة للألعاب.
- وغير ذلك الكثير.
أنا أمارس ألعاب إطلاق النار التنافسية (FPS)، لذا فإن زمن الوصول المنخفض، واتساق أوقات الإطارات، ومعدلات الإطارات العالية (FPS) هي أمور جوهرية بالنسبة لي. في نظام لينكس، توجد مجموعة لا حصر لها من الإعدادات التي يمكن تعديلها لتحقيق ذلك، مثل المتغيرات البيئية، و Gamescope، و Gamemode، وحتى المزيد من نسخ DXVK المعدلة.
ولكن لطالما انتابني شعور بالانزعاج لعدم وجود طريقة موثوقة للتحقق مما إذا كانت هذه التحسينات قد خفضت بالفعل زمن وصول النظام أم أنها مجرد وعود فارغة، أو تأثير وهمي، أو حتى أسوأ دون أن أدرك ذلك.
الجهاز
الفكرة بسيطة: قم بتوصيل جهاز مزود بنوع من مستشعرات الضوء بالشاشة ووصله عبر منفذ USB بالكمبيوتر لمحاكاة نقرات الماوس. عند النقر، قم بقياس الوقت الفاصل بين النقرة واللحظة التي يكتشف فيها مستشعر الضوء تغييرًا على الشاشة. بهذه الطريقة، يمكنك قياس زمن وصول النظام الشامل من البداية إلى النهاية.
بينما يتوفر الآن عدد من الأجهزة مفتوحة المصدر المشابهة، مثل m2p latency أو Open-Source-LDAT، عندما بدأت هذا المشروع الجانبي، كان متوفرًا فقط OSLTT. لم أكن أعرف شيئًا عن الأجهزة، لكنني كنت سعيدًا بدراسة مخططاتها وتصميم جهازي بناءً عليها بشكل فضفاض. ولكن بعد أن أنهيت مشروعي هذا الشهر فقط، قمت بدمج العديد من الأفكار من المشروعين الآخرين أيضًا.
باختصار، تعلمت الكثير عن وحدات التحكم الدقيقة، واللحام، وتطوير البرامج الثابتة لأردوينو، ووقت التكامل، ومضخمات المعاوقة، وبرنامج KiCad (القليل منه فقط)، وتصميم العلبة.
إليكم آلية عمل الجهاز الذي طورته:
- يعمل Adafruit QT Py RP2040 كفأرة USB HID بمعدل اقتراع 1000 هرتز ويطلق نقرة.
- في اللحظة التي يتم فيها إرسال النقرة، يبدأ الجهاز في جمع العينات من الثنائي الضوئي (كل 24 ميكروثانية تقريبًا).
- يتم بث 12000 عينة لكل نقرة عبر المنفذ التسلسلي إلى المضيف وتسجيلها في ملف CSV.
- واستنادًا إلى العينات، تقوم إحدى الأدوات الموجودة على المضيف بإنشاء خط أساس لكل نقرة، ثم تبحث عن العينة الأولى التي تنحرف بمقدار معين عن خط الأساس.
- ونظرًا لأن الوقت الذي يستغرقه جمع 12 ألف عينة ثابت، يمكن الآن حساب الوقت بين إرسال النقرة واكتشاف تغيير السطوع على الشاشة.
سيناريوهات الاختبار
أردت اختبار ثلاثة جوانب مختلفة.
خادم العرض (X11 مقابل Wayland الأصلي)
لا يزال الكثير من الأشخاص يستخدمون X11 بدلاً من Wayland لأنه يُقال إن Wayland يعاني من تأخر إدخال أسوأ بكثير. يكفي البحث عنه لتجد الكثير من الشكاوى بأن Wayland يبدو غير سلس.
VRR (تشغيل مقابل إيقاف التشغيل)
معدل التحديث المتغير / G-Sync / FreeSync، أو أيًا كان ما تفضله من تسميات، هي تقنية نوقشت بشدة.
شوكة DXVK ذات زمن الوصول المنخفض (تشغيل مقابل إيقاف التشغيل)
يشار إليها باسم dxvk-low-latency أو low-latency من الآن فصاعدًا. لقد بذل المشرف على هذه النسخة، netborg، جهدًا كبيرًا لتطوير محدد سرعة الإطارات هذا، وتم دمجه مؤخرًا في حزمة Proton CachyOS الرسمية، ويمكن تمكينه عبر المتغير البيئي PROTON_DXVK_LOWLATENCY=1. كانت وعود هذه النسخة أحد العوامل الحاسمة التي دفعتني لتجربة لينكس لسطح المكتب مرة أخرى.
المكافأة: زمن الوصول المنخفض لـ DXVK مقابل DXVK الافتراضي غير المحدد
تتمثل أكبر المزايا التي يوفرها محدد سرعة الإطار مثل dxvk-low-latency في استيعاب تقلبات وقت الإطار ومنع تراكم قائمة انتظار العرض. باستخدام طريقة الاختبار التي استخدمتها (مشهد ثابت داخل اللعبة)، لم تكن هناك تقلبات ملحوظة في وقت الإطار، حيث أنتجت جميع الاختبارات سيناريوهات مرتبطة بوحدة المعالجة المركزية تمامًا. لكن هذا لا يعكس غالبًا جلسة لعب حقيقية، حيث يمكن أن تتقلب أوقات الإطارات بسبب ما يحدث داخل اللعبة أو خارجها (على سبيل المثال، العمليات الأخرى التي تستخدم الموارد). لذا لإظهار جهاز التحكم في العمل أضفت حالتين اختباريتين غير محددتين.
المكافأة: Wayland الأصلي مقابل XWayland
لقد قمت بتشغيل جميع حالات اختبار Wayland عبر Wayland الأصلي (PROTON_ENABLE_WAYLAND=1) لأنني كنت أدرك بالفعل أن XWayland سيقدم تأخرًا. ولكن من أجل المقارنة، أضفت حالتي اختبار XWayland (فقط مع إيقاف تشغيل VRR).
شروط الاختبار
تم إجراء الاختبارات على جهاز يضم المعالج AMD Ryzen 7 5800X3D، وبطاقة الرسوميات NVIDIA GeForce RTX 4070 SUPER، وذاكرة وصول عشوائي 2×8 جيجابايت DDR4 بتردد 3200 ميجاهرتز. الشاشة المستخدمة كانت MSI MAG 272QP QD-OLED X50 بدقة 2560×1440 ومعدل تحديث 500 هرتز، مع لوحة أم MSI B450 Gaming Pro Carbon AC.
تم توصيل شاشة واحدة فقط أثناء جميع الاختبارات.
بالنسبة للبرمجيات، تم استخدام نظام CachyOS مع نواة إصدار 7.1.3-2-cachyos، ومحرك نفيديا إصدار 610.43.03-1، وبيئة سطح المكتب KDE Plasma إصدار 6.7.2-1.1، وخادم Xorg إصدار 21.1.24-1.1، وإصدار Proton CachyOS الأصلي 1:11.0.20260602-3، وDXVK (عبر Proton CachyOS) إصدار 3.0. تم استخدام جدولة نواة CachyOS الافتراضية.
إعدادات النظام
- معدل تحديث 500 هرتز في إعدادات النظام.
- وضع القلب المباشر (Flip mode) على X11: تم تمكينه عبر nvidia-settings.
- وضع القلب المباشر (Flip mode) على Wayland: تم التأكد من تمكينه (للتأكد من أن اللعبة تعمل في هذا الوضع: افتح ‘KWin Debug Console’ وفي علامة التبويب ‘التأثيرات’، قم بتمكين ‘showcompositing’. ثم تأكد من أن اللعبة مركزة بالكامل وأن الشيء الوحيد الذي يظهر على الشاشة هو في وضع ملء الشاشة. إذا لم تكن هناك حدود حمراء مرئية حول حواف اللعبة، فهي في وضع القلب المباشر).
- VRR على X11: تم تمكينه عبر nvidia-settings (يتطلب تغيير هذا إعادة التشغيل).
- VRR على Wayland: تم تمكينه عبر قائمة إعدادات KDE (لا يلزم إعادة التشغيل).
إعدادات DXVK
لجعل المقارنة عادلة، تم استخدام إعدادات dxvk.conf المثلى وفقًا للسيناريو:
- إذا تم تعطيل VRR، تم ضبط dxgi.maxFrameRate=500 (تم تحديد FPS بمعدل تحديث الشاشة).
- إذا تم تمكين VRR وتم تعطيل زمن الوصول المنخفض لـ dxvk، تم ضبط dxgi.maxFrameRate=497 (تم تحديد عدد الإطارات في الثانية أقل بقليل من معدل تحديث الشاشة).
- إذا تم تمكين VRR و dxvk-low-latency، فقد تم استخدام الإعدادات التالية للاستفادة من معدل إطار VRR منخفض الاستجابة: dxgi.maxFrameRate=480، dxvk.lowLatencyOffset=70، dxvk.framePace=low-latency-vrr-500، dxvk.lowLatencyAllowCpuFramesOverlap=False.
في جميع الحالات، تم تعيين d3d11.cachedDynamicResources=c.
اللعبة والمنهجية
اللعبة التي استخدمتها هي Diabotical، وهي لعبة تعتمد على DirectX 11 وتم تشغيلها عبر Heroic باستخدام Proton.
إعدادات اللعبة
- دقة الشاشة الأصلية.
- مقياس العرض 100%.
- إيقاف تشغيل Vsync.
- كل إعدادات الفيديو الأخرى منخفضة قدر الإمكان.
يوجد أمر مخفي يخفي واجهة المستخدم لفترة قصيرة من الوقت. من خلال ربط هذا الأمر بالنقر بزر الماوس الأيسر (/bind mouse_left testlatency) وإعداد شاشة HUD تعرض مربعًا أبيض كبيرًا، تمكنت من إنتاج اختلافات كبيرة في السطوع عند النقر.
المنهجية
- إغلاق البرامج غير الضرورية.
- تشغيل اللعبة.
- بدء خادم مباراة محلي (نفس الوضع والخريطة في كل مرة).
- الانتقال إلى مكان محدد، ووضع الماوس على معلم محدد.
- تشغيل تكرار حالة الاختبار (100 نقرة، لمدة دقيقتين تقريبًا).
- بمجرد الانتهاء من الاختبار، بدء تكرار حالة الاختبار التالية (3 تكرارات في المجموع).
- شروط داخل اللعبة: لا يوجد روبوتات، ولا يوجد لاعبون آخرون، ولا حركة، ولا إعادة تشغيل للجولة. إنه في الأساس مجرد مشهد ثابت سيبقى هكذا إلى أجل غير مسمى.
- شروط النظام: أثناء الاختبار، لا ينبغي تشغيل أي عمليات هامة أخرى على النظام.
- بقي جهاز القياس في نفس الوضع خلال جميع الاختبارات.
النتائج
حافظت كل حالة اختبار محددة على ثبات الحد الأقصى لمعدل الإطارات أثناء الاختبار وظلت اللعبة مرتبطة بوحدة المعالجة المركزية طوال الوقت. تبدو البيانات نظيفة: لم تنتج أي حالة اختبار قيمًا متطرفة جامحة، وكل حالة أنتجت توزيعًا على شكل جرس تقريبًا بعرض 2 إلى 3 مللي ثانية بين النسبة المئوية 5 (p5) والنسبة المئوية 95 (p95).
ثلاثة أمور رئيسية تبرز من النتائج:
- الحالات الثماني الرئيسية كلها تقع ضمن 0.72 مللي ثانية لبعضها البعض (المتوسطات تتراوح من 4.21 مللي ثانية إلى 4.93 مللي ثانية).
- يضيف XWayland 3.13 مللي ثانية علاوة على ما يعادله في Wayland الأصلي (متوسط 8.06 مللي ثانية مقابل 4.93 مللي ثانية).
- في الحالات غير المحددة، تمكنت نسخة DXVK المعدلة من تقليل زمن الوصول بمقدار 0.84 مللي ثانية.
كانت الحالة الأسرع هي X11، VRR، زمن الوصول المنخفض.
X11 مقابل Wayland
إذًا، هل يتمتع X11 بزمن وصول أقل من Wayland؟ نعم، ولكن ليس بالقدر الكافي لتبرير الاعتقاد السائد بأن Wayland أسوأ بكثير من X11.
يتفوق X11 في كل سيناريو، لكن الفارق لا يتجاوز 0.14 إلى 0.22 مللي ثانية.
على سبيل المثال، مقارنة بين إعدادات X11 و Wayland في سيناريوهات مختلفة أظهرت الفروق التالية (X11 أسرع):
- مع الكمون المنخفض و VRR: X11 كان أسرع بـ 0.17 مللي ثانية.
- مع الكمون المنخفض فقط: X11 كان أسرع بـ 0.19 مللي ثانية.
- مع VRR فقط: X11 كان أسرع بـ 0.22 مللي ثانية.
- الإعدادات العادية: X11 كان أسرع بـ 0.14 مللي ثانية.
التوزيع كان متشابهًا جدًا بينهما.
VRR: تشغيل أم إيقاف؟
أظهرت تقنية VRR التأثير الأكبر عبر عمليات الاقتران: تمكينها كان أسرع بمقدار 0.26 إلى 0.45 مللي ثانية من إبقائها معطلة.
على سبيل المثال، مقارنة بين تشغيل وإيقاف VRR في سيناريوهات مختلفة أظهرت الفروق التالية (مع تشغيل VRR):
- X11، الكمون المنخفض: VRR أسرع بـ 0.43 مللي ثانية.
- X11: VRR أسرع بـ 0.34 مللي ثانية.
- Wayland، الكمون المنخفض: VRR أسرع بـ 0.45 مللي ثانية.
- Wayland: VRR أسرع بـ 0.26 مللي ثانية.
كما أنها تسهم في تسطيح التوزيع: حيث كان انتشار p95-p5 من 2.1 إلى 2.2 مللي ثانية في حالات VRR مقابل 2.6 إلى 3.0 مللي ثانية بدون VRR. وهذا يتوافق مع كيفية عمل VRR: حيث يتم مسح الإطارات عندما تكون جاهزة بدلاً من انتظار فتحة المسح التالية.
DXVK ذو زمن الوصول المنخفض: أداء ممتاز
في حالات الاختبار المحددة، كان الفارق صغيرًا ولكنه ثابت، وبنفس حجم الفارق بين X11 و Wayland تقريبًا. فبينما كان متوسط الفارق بين Wayland و X11 هو 0.18 مللي ثانية، كان استخدام dxvk-low-latency أسرع بمتوسط 0.20 مللي ثانية.
أمثلة على الفارق عند استخدام dxvk-low-latency (تشغيل زمن الوصول المنخفض) مقارنة بإيقافه:
- X11، VRR: أسرع بـ 0.24 مللي ثانية.
- X11: أسرع بـ 0.15 مللي ثانية.
- Wayland، VRR: أسرع بـ 0.29 مللي ثانية.
- Wayland: أسرع بـ 0.10 مللي ثانية.
في حالات الاختبار غير المحددة، يمكننا فهم مصدر القوة الحقيقية لـ dxvk-low-latency: تسهيل سرعة الإطارات غير المتساوية ومنع تراكم قائمة انتظار العرض. يقوم هذا المتحكم بذلك عن طريق ضمان عدم استخدام وحدة معالجة الرسومات بالكامل أبدًا، وبالتالي تظل اللعبة دائمًا قريبة من وحدة معالجة الرسومات، ولكن لا تستهلكها بشكل كامل. يمكن ملاحظة ذلك في عمليات التشغيل الاختبارية، حيث كان استخدام وحدة معالجة الرسومات (GPU) عند مستوى 95-97% مع dxvk-low-latency، و 100% بدونه. يأتي هذا ببعض التكلفة على معدل الإطارات في الثانية (FPS).
مقارنة الحالات غير المحددة (X11):
- الكمون: 5.27 مللي ثانية (إيقاف الكمون المنخفض) مقابل 4.43 مللي ثانية (تشغيل الكمون المنخفض)، بفارق -0.84 مللي ثانية (أسرع).
- معدل الإطارات في الثانية (FPS): 715 (إيقاف الكمون المنخفض) مقابل 670 (تشغيل الكمون المنخفض)، بفارق -45 إطارًا في الثانية (أقل).
XWayland: أداء سيء
جميع اختبارات Wayland حتى الآن قامت بتشغيل اللعبة بشكل أصلي عبر PROTON_ENABLE_WAYLAND=1. إيقاف هذا الخيار يؤدي إلى تشغيل اللعبة عبر XWayland بدلاً من ذلك، وهنا تظهر المشكلة.
مقارنة بين Wayland الأصلي و XWayland:
- مع الكمون المنخفض: Wayland الأصلي 4.83 مللي ثانية، XWayland 5.95 مللي ثانية، بفارق +1.12 مللي ثانية (أبطأ).
- الإعدادات العادية: Wayland الأصلي 4.93 مللي ثانية، XWayland 8.06 مللي ثانية، بفارق +3.13 مللي ثانية (أبطأ).
يضيف XWayland، بدون dxvk ذي زمن الوصول المنخفض، 3.13 مللي ثانية إلى زمن الوصول المقاس. وهذا أكثر من جميع التأثيرات الأخرى التي قمت بقياسها مجتمعة. ولم يكن الأمر مجرد إطارات سيئة عرضية ترفع المتوسط؛ بل إن التوزيع بأكمله يتحول. ومن الجدير بالذكر أن إضافة dxvk ذي زمن الوصول المنخفض إلى اختبار XWayland أدى إلى خفض زمن الوصول بمقدار 2.11 مللي ثانية، وهو أكبر تحسن في جميع السيناريوهات.
ملخص النتائج
تم الحصول على هذه النتائج في ظل ظروف مثالية (معدل إطارات ثابت عند الحد الأقصى ومرتبط بوحدة المعالجة المركزية) وهي بالطبع خاصة بأجهزتي ومجموعة البرامج المختارة. ستختلف الأرقام المطلقة في الإعدادات الأخرى، ولكن المكاسب والخسائر من كل حالة اختبار يجب أن تنتقل تقريبًا. على شاشة ذات معدل تحديث أقل، من المرجح أن تكون المكاسب من VRR ومنظم السرعة المنخفض أكبر.
تجنب XWayland
يضيف 3.13 مللي ثانية من زمن الوصول، وهو ما يزيد عن جميع التأثيرات الأخرى مجتمعة.
Wayland قريب، لكن X11 لا يزال يفوز
على الرغم من ذلك، الفارق لا يتجاوز 0.14 إلى 0.22 مللي ثانية. ونظرًا لوجود جهود لتحسين KWin، فمن المرجح أن تُغلق هذه الفجوة عاجلاً وليس آجلاً. ومن يدري، قد تكون بيئات Wayland الأخرى أفضل بالفعل.
VRR له التأثير الأكبر
كان VRR أسرع في كل عملية إقران (بفارق 0.26 إلى 0.45 مللي ثانية) وقام أيضًا بتسوية توزيع زمن الوصول.
DXVK ذو زمن الوصول المنخفض: مكسب شامل
يعتبر الفارق من 0.10 إلى 0.29 مللي ثانية في السيناريوهات المحددة تعزيزًا جيدًا، ولكن القوة الحقيقية للنسخة المعدلة تظهر في حالة الاختبار غير المحددة، حيث حققت مكسبًا قدره 0.84 مللي ثانية مقارنة بـ dxvk الافتراضي. بالإضافة إلى ذلك، في السيناريوهات التي لا يمكن فيها تجنب XWayland، فقد استعادت بالكامل 2.1 مللي ثانية.
الخلاصة
مع عدم أخذ XWayland في الاعتبار، أدى تطبيق كل تحسين (X11، VRR، الكمون المنخفض) مقارنةً بالإعداد الافتراضي (الذي أفترض أنه Wayland العادي في نظام Linux الحديث) إلى خفض متوسط زمن الوصول بمقدار 0.72 مللي ثانية. قد لا يبدو هذا كثيرًا، لكن زمن الوصول الأولي لا يروي القصة بأكملها، حيث يعمل VRR أيضًا على تقليل ارتعاش زمن الوصول، ويعد جهاز ضبط سرعة dxvk-low-latency رائعًا في تسهيل سيناريوهات العالم الحقيقي حيث تحدث انخفاضات في وقت الإطار وتحدث مواقف مرتبطة بوحدة معالجة الرسومات.
جهود مماثلة
قام ديفيد راميرو ببناء جهازه m2p لقياس زمن الوصول وقارن بين X11 و Wayland في مقالته ‘إنشاء مقياس لزمن وصول الإدخال’ (لأن الشعور بأن ‘Wayland معطل’ ليس مقياسًا). وقد توصل أيضًا إلى استنتاجات مماثلة: Wayland الأصلي يتماشى مع X11 الأصلي (جميعها تدور حول 7 مللي ثانية)، بينما ضاعف XWayland زمن الوصول تقريبًا في اختباراته.
أجرى فارنوي اختبارات مكثفة باستخدام Open-Source-LDAT في منشوره ‘قياسات زمن الوصول لنظام لينكس وضبط المُركب’، وخلص أيضًا إلى ضرورة تجنب XWayland.
مقالي ‘مهمتي الجانبية هي قياس زمن وصول الإدخال باستخدام VK_EXT_present_timing’ يصف طريقة مختلفة لقياس زمن الوصول دون أي أجهزة خارجية، وذلك عن طريق حقن المدخلات عبر /dev/uinput واكتشاف التغيير الناتج في الصورة على وحدة معالجة الرسومات. هذا لا يقيس زمن استجابة النظام من طرف إلى طرف، لكنه يزيل زمن استجابة USB وزمن استجابة العرض من المعادلة، ويضيّق نطاق القياس ليقتصر على زمن وصول الكمبيوتر فقط. يمكن العثور على المشروع على GitHub.