السلام عليكم :

* أعتذر من أصحاب الموقع .. ومن الأعضاء .. أعرف أنكم تنتظرون أسئلة عن shaders .. لكن بالفعل هذه النقطة بودّي لو أعرفها .. بالرغم من أنها لا تدخل مباشرة بصناعة الألعاب .

كنت أكتب بعض المقالات عن OpenGL .. للمبتدئين طبعا .. وقلت أن OpenGL تعتمد على كرت الشاشة .. وأنها تستمد قدرتها من قدرة كرت الشاشة وتحديث drivers ..(ولدي تصوّر شبه واضح عن كيفية اتصال OpenGL بكرت الشاشة) .. وعندها توقفت كثيرا عند هذه النقطة وظهر السؤال .. كيف يعمل كرت الشاشة ..

لا أريد أن أترك السؤال مطّاطا أو ممطوطا .. بهذه الطريقة .. أريد أن اظهر بعض ما أفقهه .. لعلّ ذلك يخفف صدمة القارئ☺ .. وانتظر منكم تعليقات على بعض هذه النقاط أو كلها☺ ..

* هل يمكن رسم بكسل على الشاشة دون الاستعانة بكرت الشاشة ؟

- درسنا في اسمبلي 16-بت .. قليلا عن  مقاطاعات ... وقرأت عن مقاطعة خاصة بالرسوم والألوان .. وفهمت أن المعالج هو من يقوم بالرسم .. لذلك كان الاستنتاج ..

هل هذا صحيح .

* النقطة الثانية .. وهي نتيجة للنقطة الأولى .. , لو اعتمدنا على  مكتبة مثل GDI  و GDI32 ..فعندئذ .. محركنا سيدعم Render من نوع Software ,, وسنضمن عمل لعبتنا على جميع الكروت ..ولكن ببطء .. من هنا نريد أن نعرف ماذا  نعني بأن ال Graphics API  لهذه المكتبة هي Software ؟

هل يعني هذا أن GDI لاتعتمد على كرت الشاشة .. أو هل يعني هذا أن 90% من مهام المكتبة GDI يمكن تأديتها بالعتماد على الذاكرة والمعالج فقط .


* النقطة الثالثة .. هي عن OpenGL و DirectX وعلاقتهما بكرت الشاشة .

أسمع عن Drivers الخاصة بكرت الشاشة .. بالتالي عندما أحدث Drivers أجد أن دعم OpenGL صار أحسن .. بالرغم من أني لم أغيّر كرت الشاشة .. فما الذي يحصل بالظبط .. دعوني أخبركم بما فهمته :

OpenGL هي أولا مجرد Specifications  .. قامت microsoft بعمل implementation  لها .. كما قامت SGI ..
لذلك ATI  و انفيديا .. لها أيضا implementation  .. بناء على كرت شاشتها ..

فلو فرضنا أننا نريد دعم ميزة Anisotropic في OpenGL .. فأنه يوجد خوارزمية لذلك .. ولكن قد تكون بطيئة .. لذلك تم اضافة ( قطعة hardware ) أو سمها ما شئت الى كرت الشاشة لتسرع العملية ..

وبالتالي OpenGL تستطيع أن تعمل وتستغل قدرة كرت الشاشة لتطبق علمية Anisotropic .

* النقطة الرابعة .. أيهما يخرج أولا .. هل يتم اطلاق اصدار جديد من OpenGL و DirectX يدعم أمور جديدة .. ثم يتم اصدار كرت شاشة يدعم هذه الميزات ..
أو يتم اصدار كرت شاشة جديد .. ثم تتهافت OpenGL و DirectX على دعم هذه الميزات الجديدة .

* النقطة الخامسة .. دائما محبوا OpenGL ساخطون على Microsoft لانها لاتقدم تحديث جديد لOpenGL  .. فهي فقط تدعم OpenGL1.1 ... وبالتالي يجب أن نحمّل تحديثات خاصة من شركة كرت شاشتنا ..

فالسؤال .. هو ما علاقة microsoft بالأمر .. اذا كان كرت شاشتي سيئا فكيف ستعمل drivers المقدمة من MS.. واذا كان كرت شاشتي جيدا .. فأكيد أنه سيأتي معه drivers تدعم اصدارات متقدمة من OpenGL .. فلماذا نطالب MS أن تحدّث OpenGL ..؟


يبدو أن الصورة عندي  مشوشة فعلا

و عليكم السلام


سأحاول الإجابة عن بعض الأسئلة حسب معرفتي المتواضعة في هذا الموضوع.



نعم و لا! نعم لأنه قبل إعتماد كرت الشاشة في أجهزة الحاسوب, كان هناك (و لا زالت في بعض الأحيان)  وحدة تدعى ب الFramebuffer , و مسؤوليتها إخراج الرسومات إلى وحدة العرض. ومبدأها هو تخصيص جزء من ال CPU Memory map لهذه الوحدة و تدعى بال Video memory ليقوم المبرمج بوضع البيانات في هذه الذاكرة المخصصة و يتم إخراجها و رسمها على الشاشة.
 لا لأنه في هذه الأيام, الFramebuffer و الVideo memory هي أجزاء من كرت الشاشة و معظم أنظمة التشغيل تمنعك من التعامل معها بشكل مباشر, و يتم استخدام المكتبات المعروفة و التي بدورها تتعامل مع ال Kernel و driver كرت الشاشة. بالطبع الأمور أكثر تعقيدا على أرض الواقع و هي تختلف باختلاف الأجهزة و استخدامها لأنظمة التشغيل.





 OpenGL implementation هو جزئين, Hardware and Software. يتم استخدام الsoftware implementation عند استخدام خصائص غير مدعومة في كرت الشاشة, أو ليس لها hardware implementation بعد من قبل الdriver. لذلك فإن وجود software implementation مهم جدا ليكون البرنامج portable و قابل للعمل على معظم الأجهزة. (لاحظ هنا أني أتكلم عن الportability حتى على نفس نظام التشغيل)
وعدم وجود implementation كامل سيحدد الخصائص الحديثة و الممكن الإستفادة منها في البرنامج. لذلك, فإن معظم البرامج تقوم باستدعاء الدوال الغير متوفرة في OpenGL 1.1 مباشرة من ال driver باستخدام wglGetProcAddress والتي تقوم بإرجاع الدالة المطلوبة (إن وجدت).


محمد خشاشنة

لنفكر بالأمر من زاوية أخرى. هل يمكنك أن تظهر شيئاً على شاشة الحاسب دون أن توصلها بالحاسب نفسه؟ وبالتحديد بمأخذ كرت الشاشة؟ لا أعتقد ذلك. مهمة كرت الشاشة الأساسية هي تحويل القيم اللونية (في الـ frame buffer أو غيره) إلى قيم تحكم بالشاشة (سواءً كان ذلك تحكماً "بالمسدس اللوني" في شاشات الـ CRT أو شدة الـ voltage المطبقة على السائل في شاشات الـ LCD) في الأيام القديمة كان المبرمج يقوم بنفسه ببرمجة كافة مزايا الرسم بدايةَ من الشفافية وإنتهاءً بالظلال. طبعاً كان التنفيذ هنا يتم باستخدام المعالج الأساسي (CPU) مما أدى لانشغال هذا المعالج بأمور الرسم عن الأمور الأخرى (صوت، ذكاء صنعي... إلخ) هنا تم تضمين معالج خاص وذاكرة خاصة  بالرسوميات، بالإضافة إلى كون كثير من التعليمات المستخدمة بكثرة في الرسم منفذة بشكل hard-wired أي باستخدام البوابات الفيزيائية بدلاً من تعلميات عديدة (كمثال غلى ذلك ضرب المصفوفات الذي يتم بتعليمة واحدة على الـ GPU إذا كنت تكتب shaders). مما أدى لتسريع الأداء.

كما قلت فإن الــ GDI لا تستطيع ألا تعتمد على كرت الشاشة فعلى الأقل يجب أن تستخدم خدمات كرت الشاشة في تحديد القيمة اللونية لبيكسل معين. يمكن أن نقول أنه لا يوجد كرت لا يقدم هذه الخدمة. أي أنك إذا لم تعتمد على غيرها فإن برنامجك مضمون بأن يعمل على معظم أجهرة التي تحتوي على كرت شاشة و شاشة (بعضها لا يحوي). طبعاً المستخدم الذي تكلّف مئات الدراهم على كرته سيشعر بأنه "انغبن" لأنك لا تستفيد من الميزات التي يتيحها كرت الشاشة لك وبالتالي فأنك تضيع دراهمه.
 


سؤال سريع: كيف "تجد" أن دعم OpenGL صار أحسن؟ 

صحيح. 

ملاحظة خارج الموضوع: إذا كانت "الخوارزمية" بطيئة حقاً فإن استخدام الـ hardware لن يزيد في سرعة العملية بشكل كاف. فكر مثلاً بخوارزمية من تعقيد O(2^n) إن أي نوع من الـ hardware تضيفه لن يجعل هذه الخوارزمية سريعة. لا أتكلم هنا عن الـ realtime ولكن عن ساعات و أيام و سنين. 
إلا أنه يمكن الاستفادة من الـ hardware في تسريع عمليات تستخدم بكثرة (كضرب المصفوفات أو دمج الألوان أو الـ wrapping... إلخ) هنا يقوم مصممو كروت الشاشة بإضافة هذه الميزة إلى كرتهم ليتم تنفيذها بشكل مباشر على معالج كرت الشاشة وبشكل أسرع. ثم يقوم هؤلاء بطرح driver يقوم بتقديم هذه الميزة إلى المبرمجين بشكل خفيض المستوى. ثم يقوم مبرمجو المكتبات (كـ OpenGL و DirectX) بتقديم interfaces أو functions أعلى مستوىً لدعم هذه الميزة. أخيراً يقوم المبرمجون باستخدام هذه المكتبات المحثة للاستفادة من الميزات الجديدة. طبعاً هذه الحلقة لا تحدث دائماً. فقد يقوم مصممو المكتبات بطرح ميزة غير منفذة أو منفذة باستخدام الـ software (إي على الـ CPU) فيقوم مصممو كروت الشاشة بدعمها على الـ hardware وهنا نجد أنه يمكن الاستفادة من مزايا لم تنفذ بعد.
 

أعتقد أني أجبت على سؤالك. لمزيد من المعلومات انظر: وسام☺




يجب أن تفرق بين الـ driver و المكتبة التي تسخدم هذا الـ driver كـ OpenGL. حتى لو أن كرتي و تعريفه يدعم أصدارأ متقدماً من OpenGL (أي أن هذا الأصدار يستخدم مزايا متقدمة من كرت الشاشة) فأن عدم وجود أصدار جديد من OpenGL سيؤدي إلى عدم الاستفادة من هذه المزايا و هذا الدعم.
أرجو أن أكون قد أجبت عن بعض تساؤلاتك

بارك الله فيكم .. محمد + عبداللطيف ,,

معلومات دسمة .. ومفيدة ان شاء الله ..




 زادت عدد الامتدادات المدعومة .. قبل التحديث كانت الامتدادات المدعومة للاصدار GL 2.0   تمثل 50% .. بعد التحديث صار 100% ... مثلا ,

وهذا بالاستفادة من احد البرامج الصغيرة ..






لم أفهم حقيقة ما المقصود " بعدم وجود اصدار جديد من OpenGL " .. في الوقت الحالي صارت driver == opengl .. بمعنى أن  implementation  الوحيد هو يأتي من driver الخاصة بكروت الشاشة ..  أليس كذلك .. هذا أيضا ما فهمته من كلام الاخ محمد ..




فقط بقي النقطة الخامسة .. لازال لدي تشويش ...

* لماذا لا تقوم sgi .. أو أي شركة بتطوير مكتبة OpenGL .. لتعمل على Software .. واذا كان driver مدعوم فانها تستفيد من hardware..

يعني مثل ماهو موجود في dx .. يوجد HAL و REF على ما أذكر ..ومثل ماهو موجود بمكتبة MESA  .

 لماذا نعتمد على MS .. لتقوم بما قاله الأخ محمد :

"" يتم
استخدام الsoftware implementation عند استخدام خصائص غير مدعومة في كرت
الشاشة, أو ليس لها hardware implementation بعد من قبل الdriver. ""

سأفترض أن "driver == opengl" هو سؤال وأقول لك أن نتيجته هي false☺
الـ driver شيء والـ OpenGL شيء آخر. كما أنني بحثت الآن ووجدت هذه الصفحة: http://www.opengl.org/documentation/implementations/
والتي لا تتحدث عن أي implementation لـ OpenGL من قبل أي شركة لكروت الشاشة (ممم... ربما يجب أن نستخدم المصطلح: بطاقات الإظهار)
نستطيع أن نقول أن OpenGL هو عبارة عن واجهة موحدة لجميع الـ drivers. تخفي التعقيد المصاحب لاستخدامها.
 

لا أدري حقاً. لكن Microsoft لن تكون سعيدة بهكذا مكتبة. لأنها ستفتح مجالات جديدة في OpenGL لتجعلها بديلاً عن DirectX على أنظمة تشغيل Windows 

REF mode لا يستخدم حين لا يكون هناك دعم من الـ hardware. فقط يستخدم REF mode عند الـ debugging.

نحن ننتظر أسئلة عن أي شيء أخي الشمري 😄
 



بشكل عام نعم، تستطيع رسم بكسل على الشاشة دون المرور بمعالج كرت الشاشة ☺ . عموماً، فإن أجهزة الحاسب تملك دائماً ذاكرة خاصة تحمل القيم اللونية التي يتم مسحها وإظهارها على الشاشة. لذلك فإن كل ما تحتاجه هو الوصول لهذه الذاكرة وتعديل القيم فيها.. هنا يختلف الوضع بين معمارية وأخرى، ففي حالة ويندوز فإنك تستطيع فعل ذلك عن طريق DirectDraw، وفي الأجهزة المحدودة فإنك غالباً تملك عنوان ذاكرة الإظهار (video ram) ويمكنك الكتابة عليها فوراً. 
 


مكتبة GDI مجهزة للرسم ثنائي البعد فقط، وهي المكتبة التي اعتمد عليها ويندوز منذ أول إصداراته للرسم 😒 ، وهي تملك دائماً خط عودة يعمل على الـ CPU في حال كون كرت الشاشة غير قادر على دعم تعليمة معينة (مثلاً رسم منحنيات). لكنها في نفس الوقت تحاول الاستفادة من أي عمليات يدعمها كرت الشاشة مباشرة 😲 . لذلك لا أرى أنها مكتبة "software" بمعنى الكلمة، لكن ما تقوله صحيح ☺ ... فهي تستطيع العمل بغض النظر عن دعم كرت الشاشة، وكما تفضل عبد اللطيف وذكر، فإنها تفرض حد أدنى من المواصفات الواجب توفرها في كرت الشاشة. 



الـ driver يقوم باستقبال التعليمات التي يستلمها من OpenGL و Direct3D. بعض هذه التعليمات يتم إرسالها للمعالج، وبعضها في الحقيقة يتم معالجته ضمن الدرايفر نفسه على الـ CPU 😒 . مثلاً، عندما يستقبل الدرايفر تعليمات glVertexf متكررة فإنه يكدسها ضمن مصفوفة مؤقتة حتى يستقبل تعليمة glEnd، ومن ثم يقوم بإرسال المصفوفة كاملة للمعالجة على الـ GPU. أما لو قام بإرسال التعليمات أولاً بأول، فإن الأداء سينحدر بشكل كبير 😖 ! 
من ضمن التحسينات التي يستطيع الدرايفر عملها مثلاً تنظيم ذاكرة كرت الشاشة VRAM بشكل أفضل، مما يزيد من الذاكرة المتاحة للبرامج، أو مثلاً فلترة التعليمات الزائدة (مثلاً تفعيل حالة الـ alpha blending مع أنها مفعلة من قبل). في ويندوز، الانتقال بين طبقتي الـ user والـ kernel يستهلك وقتاً كبيراً 😖 ، لذلك فإن طبقة الـ user من الـ driver تحاول تفادي الاتصال مع الطبقة السفلى قدر المستطاع، وتعمل على تكديس الأوامر حتى يحين الوقت المناسب لتسليمها كلها دفعة واحدة.
 
كما ترى، مثل هذه التحسينات تحدث دون علم البرامج، إلا أنها عملياً تزيد من سرعة الأداء! 😄
 
 


كلاهما يحدث 😄 . إذا وضعنا OpenGL جانباً (لأن له وضع خاص)، فإن ما تقوم به مايكروسوفت عادة هو الحديث مع شركات تصنيع بطاقات الإظهار، ومعرفة أحدث الأبحاث التي ينوون نشرها في منتجاتهم على مدى السنوات القادمة، ومن ثم يقومون بتصميم API يقدم للمبرمجين إمكانية الاستفادة من هذه المزايا بشكل موحد على جميع بطاقات الإظهار ☺ . بعد أن يتم طرح هذه التعديلات للمبرمجين، فإن شركات التصنيع مثل AMD و nVidia تقوم بإتمام دعم المزايا الجديدة عن طريق الـ drivers التي ستخبر D3D بأن هذه الميزة الآن مدعومة في هذا الكرت. 
أما بالنسبة لـ OpenGL، فإنه قليلاً ما يحتاج إلى فعل ذلك 😒 ، لأنه يقدم جانباً مفتوحاً عن طريق الامتدادات extensions التي يمكن للـ driver أن يدعمها متى يحلو له. أما D3D فلا يقدم هذه المرونة 😢 ، لذلك فهو مضطر لمتابعة الأمور بشكل مستمر كي لا يبقى في الوراء.
 
 



كما وضح عبد اللطيف، هناك فرق بين OpenGL كمكتبة، والـ driver الخاص ببطاقة الإظهار. إن OpenGL منذ إصداره الأول يسمح لك باستعمال جميع مزايا كرت الشاشة الحديثة والتي لم تكن موجودة أثناء وضع مواصفات OpenGL، وذلك عن طريق الامتدادات كما ذكرنا ☺ . 
أما إصدارات OpenGL الجديدة فإنها تشمل إجراءات جديدة موحدة على كل الأجهزة 😄 ، دون الحاجة لاستخدام امتدادات (سواء من nVidia أو ATI أو حتى الـ ARB نفسها)... مثلاً، في حالة الإكساء المتعدد (multi-texturing)، فقد بدأ الأمر كامتداد من nVidia 😨 ، ومن ثم أصبح امتداداً رسمياً من قبل الـ ARB، وأخيراً دخل في مواصفات OpenGL الفعلية في الإصدار 1.3 ☺
 
أعتقد أن السبب الذي يجعل مستخدمي OpenGL غاضبين هو أن تحديث OpenGL بالفعل بطيء ، مما يعني أنني كمبرمج ألعاب مضطر دائماً للتعامل مع الامتدادات بدلاً من إجراءات موحدة دائماً  😢 ، مما يعني كتابة كود أكثر، ومجال خطأ أكبر 😭 ...
 
بالنسبة لمبرمجي الألعاب التجارية فإنهم يفضلون D3D لأنه يوفر عليهم عناء التجريب بشكل كبير.

أود أن أعقب على هذا الكلام, نعم هما مختلفين في حالة الإعتماد على ال OpenbGL library و التي هي بمثابة الSoftware implementation, و لكن في حال ال Hardware implementation, الdriver يقوم بعمل Implementation كامل لل OpenGL pipeline ضمنيا. و على جميع البرامج أن تقوم بlink مع الOpenGL library كخطوة أولى, و من ثم هي مسؤولة (أي الlibrary) عن مخاطبة ال driver. و كما أشار وسام, يقوم المبرمج بالتعامل مع ال Extensions لاستخدام أي خاصية غير موجودة في ال library ولكنها موجودة في ال driver OpenGL implementation.

سؤال الأخ الشمري يكمن في امكانية استخدام library أخرى غير الموجودة مع Windows, مثل Mesa 3D و الكف عن المطالبة بإصدار تحديث جديد.
الجواب ربما (لست متأكدا) أن هذه المكتبة هي جزء أساسي في Windows, و هي البوابة الوحيدة للتخاطب مع الWindows kernel.
وكما قال الأخ عبد اللطيف,  " Microsoft لن تكون سعيدة بهكذا مكتبة. لأنها ستفتح مجالات جديدة في OpenGL لتجعلها بديلاً عن DirectX على أنظمة تشغيل Windows"
بالمناسبة, Vista يوفر 3 implementations مختلفة ل OpenGL, واحدة تدعم 1.4, وواحدة تقووم بمحاكاة الOpenGL commands وتحويلها إلى مثيلها في ال D3D, و أخرى غير مستخدمة حاليا وهي تدعم 2.0.



هذا على Windows فقط يا وسام 😄

معلومات قيمة ورائعة أخواني .. وأشبعت فضولي 😏   ..

نلتقي في أسئلة أخرى .. ;)