السلام عليكم ورحمة الله،
حتى الآن في هذه السلسلة تحدثنا عن أداء معالج الرسوميات وكيفية تحسينه وتفادي تخريبه، لكننا لم نظهر ادعاءاتنا من خلال أمثلة عملية تعطينا أرقاماً محسوسة. باختصار، نحتاج لمعرفة طريقة قياس أداء معالج الرسوميات وباستخدام هذه الطريقة، نستطيع قياس الفرق في الأداء بين أسلوب رسم وأسلوب آخر، فتظهر لنا عندها الفائدة من اتباع أحدهم بدلاً من غيره.
هناك بعض البديهيات في أمور الأداء، لكن العديد من المسائل المتعلقة بالأداء (خاصة أداء المظللات) لا يمكن معرفة حلها المثالي بطريقة نظرية، وإنما فقط عن طريق القياس ومن ثم انتقاء الأفضل. حتى النصيحة التي قدمناها في الحلقة الماضية تنتمي إلى هذه الفئة، فاستخدام الجمل الشرطية في مظلل البكسلات أحياناً يسرع الأداء وفي حالات أخرى يتسبب بإبطائه. فالقول الفصل هنا هو: قـِـس الأداء وانتق الأفضل. وفي هذه الحلقة سنتحدث عن كيفية تنفيذ فعل الأمر الأول (قس).
في أغلب الأحيان عند الحديث عن الأداء في الألعاب أو تطبيقات الرسوميات الفورية يُرجأ إلى ذكر ما يسمى بعدّاد FPS (اختصاراً لـ Frames Per Second أو لقطة-في-الثانية). وهو مقياس أداء مشهور في أوساط اللاعبين وبرامج تقييم الأداء. لكن يجب أن نعلم أن عداد FPS هو فقط واحد من عدة أساليب قياس ضرورية، وهو كذلك الأكثر غموضاً بينهم. مبرمج الرسوميات الجاد لا يقصر اعتماده على هذا المقياس فقط، أما بالنسبة للاعبين فعداد FPS هو كل ما يهمهم. الجدول التالي يخبرنا بالمقاييس الأكثر شيوعاً في تحسين الأداء.
| نوع المقياس |
الوحدة |
الاستخدام |
الفوائد |
القيمة المثالية |
| CPU Time |
ميللي ثانية |
معرفة الوقت المستهلك لتنفيذ مجموعة متسلسلة من التعليمات على المعالج المركزي |
أساسي في قياس وتحسين الأداء على المعالج المركزي |
أصغر ما يمكن. 16.6 ميلي ثانية أو أقل لإظهار 60 لقطة في الثانية. |
| GPU Time |
ميللي ثانية |
معرفة الوقت المستهلك لتنفيذ مجموعة متسلسلة من التعليمات على معالج الرسوميات |
أساسي في قياس وتحسين الأداء على معالج الرسوميات |
أصغر ما يمكن. 16.6 ميلي ثانية أو أقل لإظهار 60 لقطة في الثانية. |
| FPS |
هيرتز |
عدد اللقطات التي تم تنفيذها خلال الثانية السابقة |
للتباهي فقط – لا فائدة منه مقابل المقياسين السابقين |
أكبر ما يمكن |
| FPS VSync |
هيرتز |
عدد اللقطات التي تم إظهارها على الشاشة خلال الثانية السابقة |
مؤشر عام للأداء وتوافق تزمين العرض على الشاشة مع حسابات اللعبة |
تطابق تردد الشاشة. 60 بالضبط للشاشات التي تعمل بتردد 60 هيرتز. |
معروف أن الألعاب وتطبيقات الرسوميات الفورية (من الآن فصاعداً سأعني كليهما بمجرد ذكر الألعاب فقط) تعتمد على رسم اللقطات تباعاً وبسرعة لتظهر للاعب الحركات الناعمة. في أغلب الألعاب الحديثة يطالب اللاعبون برؤية 30 لقطة في الثانية على الأقل. 60 لقطة تعتبر عدداً مثالياً لكنه أقل انتشاراً من 30. أجهزة العرض المعاصرة تستطيع عرض ما بين 60 (شاشات عرض الحاسوب) إلى 240 لقطة في الثانية (تلفزيونات الدقة العالية الحديثة)، ومسؤوليتنا كمبرمجين هي إظهار رسوميات ألعابنا على هذه الشاشات.
تستطيع أجهزة الحاسوب حساب لقطات (frames) بسرعة أحياناً تفوق سرعة عرض شاشة العرض بكثير (مثلاً 1000 لقطة في الثانية)، وذلك يعتمد على طبيعة المشاهد المرسومة ومواصفات الجهاز. في هذه الحالة نكون قد أهدرنا أداء الحاسوب في حساب لقطات أغلبها لن يظهر للمشاهد أبداً. لذلك يجب أن نتفادى الرسم بالسرعة القصوى إن كان هذا يؤدي إلى تجاوز سرعة عرض الشاشة، وأن نلتزم فقط بحساب اللقطات التي ستتمكن الشاشة من عرضها للمشاهد. هذه العملية تدعى التزمين العامودي أو Vertical Synchronization أو اختصاراً VSync (كلمة “العامودي” في المصطلح ترجع لأسباب تاريخية معنية بطريقة مسح الصورة على الشاشة ولكن الأمور بدأت تختلف هذه الأيام مع الشاشات الحديثة).
في المقابل، بعض المشاهد المعقدة أو الأجهزة الضعيفة لا تملك القدرة حتى على رسم 15 لقطة في الثانية (جهازي الصغير الذي أكتب عليه الآن لا يستطيع تشغيل لعبتي Hyper Void بأسرع من 7 لقطات في الثانية). هنا يجب على المبرمج تقصي المسببات الرئيسية لبطء الأداء وإيجاد حلول لها. تدعى هذه العملية بالمجمل بعملية التحسين (optimization). وفي هذه العملية من الخطأ الاعتماد على مقياس FPS لتحديد مصدر البطء. فهو في الحقيقة لا يخبرنا بأي شيء عن المسبب، وإنما فقط عن سرعة عرض اللقطات. فمصدر البطء قد يكون من إحدى العمليات على المعالج المركزي أو ربما على معالج الرسوميات. إن لم نستطع تحديد مصدر البطء بالضبط، فكيف لنا أن نحل المشكلة بدقة ودون إضاعة الجهد في محاولات لا فائدة منها؟
هنا يأتي دور المقياسين CPU Time و GPU Time. فهما يخبرانا بالضبط كم من الوقت يستغرق كلاً من المعالجين لأداء مهامه في تجهيز اللقطة القادمة من اللعبة. فلو تبين لنا مثلاً أن المعالج المركزي يستغرق 5 ميلي ثانية ومعالج الرسوميات يستغرق 25 ميلي ثانية، عندها نستنتج أن لدينا مشكلة أداء على معالج الرسوميات، وبالتالي تنصب جهودنا على تحديد العملية التي تستهلك الحيز الأكبر من وقت ذاك المعالج ومن ثمّ تحسين أداءها بشتى الوسائل المتاحة.
بالمناسبة، يمكننا استخدام المقياسين CPU Time و GPU Time لقياس زمن أية مجموعة محددة من التعليمات، وليس بالضرورة زمن كامل اللقطة. فمثلاً، يمكننا وضع مقياس CPU Time على حسابات الذكاء الصناعي، وآخر على حسابات الرسوميات وآخر على كامل اللقطة، وهكذا نستطيع بمجرد النظر إلى هذه الأرقام معرفة مجموعة الحسابات التي يبعثر المعالج وقته فيها. طبعاً نفس الكلام ينطبق على معالج الرسوميات. لكني أحب التنويه بأن طريقة قياس الزمن على هذا المعالج تختلف عن الطريقة المتبعة في المعالج المركزي (لمستُ موضوع قياس زمن المعالج المركزي في إحدى مقالاتي في مجلة ترونيكس – للدقة في المكالمة الثالثة: 23/6/2001 – 8:02 مساءً ضمن المقالة).
لمعرفة كيفية قياس الزمن في معالج الرسوميات، أدعوك للاطلاع على هذا الموضوع في الشبكة العربية لمطوري الألعاب.
الحديث عن تحسين الأداء ممتع وشيق ويشعرك بأنك الرائد نور الدين محمود في إحدى مهامه لكشف غموض لغز علمي ما من ألغاز ملف المستقبل إياها. وبالتأكيد سنتحدث أكثر إن شاء الله عن هذا الموضوع (عن تحسين الأداء وليس الرائد نور طبعاً)، لكن هذا في حلقة أخرى…
والسلام عليكم ورحمة الله…