البنية التحتية للعرض المباشر

📅 آخر تحديث: ٢٧ يوليو ٢٠٢٦
✍️ نُشر في: ٢٧ يوليو ٢٠٢٦
📷 يحتوي على 8 صور
الموسوعة الحرة
يوجد نوعان من برامج تشغيل معالجات الرسوميات: أحدهما موجود داخل خادم عرض X. وقد طُورت عدة نسخ من هذا البرنامج. النسخة الحالية تقسمه إلى جزأين: DIX (X المستقل عن الجهاز) وDDX (X المعتمد على الجهاز).
سيعمل Glamor على تبسيط خادم X ، و libGL-fglrx-glxيمكن استخدام مكتبة libDRM الخاصة ببرنامج تشغيل radeon مفتوح المصدر بدلاً من الملف الثنائي الاحتكاري .
تُسند عمليات حساب العرض إلى وحدة معالجة الرسومات (GPU) عبر OpenGL ليتم تنفيذها في الوقت الفعلي. ويتولى نظام إدارة العرض الرقمي (DRI) تنظيم الوصول إلى هذه العمليات وحفظ سجلاتها.

تُعدّ بنية العرض المباشر ( DRI ) الإطار الذي يتألف منه نظام الرسومات الحديث في لينكس، والذي يسمح لبرامج مساحة المستخدم غير المُرخّصة بإصدار أوامر إلى وحدة معالجة الرسومات دون تعارض مع البرامج الأخرى. [ 6 ] يتمثل الاستخدام الرئيسي لـ DRI في توفير تسريع الأجهزة لتطبيق Mesa لـ OpenGL . كما تمّ تكييف DRI لتوفير تسريع OpenGL على وحدة تحكم إطار العرض دون تشغيل خادم عرض . [ 7 ]

تتوزع تقنية DRI عبر خادم X ومكتبات العميل المرتبطة به، و Mesa 3D ، ونظام إدارة العرض المباشر (Direct Rendering Manager) الفرعي في نواة النظام. [ 6 ] جميع شفرتها المصدرية مفتوحة المصدر .

ملخص

في بنية نظام X Window الكلاسيكية، يُعد خادم X العملية الوحيدة التي تتمتع بوصول حصري إلى وحدة معالجة الرسومات ، وبالتالي فهو المسؤول عن عملية العرض الفعلية على مخزن الإطارات . كل ما تفعله عملاء X هو التواصل مع خادم X لإرسال أوامر العرض. هذه الأوامر مستقلة عن نوع العتاد، مما يعني أن بروتوكول X11 يوفر واجهة برمجة تطبيقات (API) تُجرّد جهاز الرسومات بحيث لا يحتاج عملاء X إلى معرفة تفاصيل العتاد الأساسي أو القلق بشأنها. أي كود خاص بالعتاد موجود داخل X المعتمد على الجهاز ، وهو جزء من خادم X يُدير كل نوع من بطاقات الفيديو أو محولات الرسومات، والذي يُطلق عليه أيضًا غالبًا برنامج تشغيل الفيديو أو الرسومات .

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

لا يوجد ما يمنع استخدام تقنية DRI لتنفيذ تسريع العرض المباشر ثنائي الأبعاد ضمن عميل X. [ 3 ] ببساطة، لم تكن هناك حاجة لذلك لأن أداء العرض غير المباشر ثنائي الأبعاد كان كافيًا.

هندسة البرمجيات

تتضمن البنية الأساسية للبنية التحتية للعرض المباشر ثلاثة مكونات رئيسية: [ 8 ]

  • يحتاج عميل DRI - على سبيل المثال، عميل X الذي يقوم بـ "الرسم المباشر" - إلى "برنامج تشغيل" خاص بالأجهزة قادر على إدارة بطاقة الفيديو أو محول الرسومات الحالي لكي يتمكن من الرسم عليها. تُقدم برامج تشغيل DRI هذه عادةً كمكتبات مشتركة يرتبط بها العميل ديناميكيًا . ولأن تقنية DRI صُممت للاستفادة من أجهزة الرسومات ثلاثية الأبعاد، تُقدم المكتبات عادةً للعملاء كتطبيقات مُسرّعة بواسطة الأجهزة لواجهة برمجة تطبيقات ثلاثية الأبعاد مثل OpenGL ، والتي يُوفرها إما مُصنّع أجهزة الرسومات ثلاثية الأبعاد نفسه أو طرف ثالث مثل مشروع Mesa 3D للبرمجيات الحرة .
  • يُوفّر خادم X امتدادًا لبروتوكول X11 ، وهو امتداد DRI ، الذي تستخدمه عملاء DRI للتنسيق مع كلٍّ من نظام النوافذ وبرنامج تشغيل DDX. [ 9 ] وكجزء من برنامج تشغيل DDX، من الشائع أن يرتبط خادم X ديناميكيًا ببرنامج تشغيل DRI نفسه الذي تستخدمه عملاء DRI، وذلك لتوفير عرض ثلاثي الأبعاد مُسرّع بواسطة الأجهزة لعملاء X الذين يستخدمون امتداد GLX للعرض غير المباشر (على سبيل المثال، عملاء X البعيدون الذين لا يمكنهم استخدام العرض المباشر). أما بالنسبة للعرض ثنائي الأبعاد، فيجب أن يأخذ برنامج تشغيل DDX في الاعتبار أيضًا عملاء DRI الذين يستخدمون نفس جهاز الرسومات.
  • يتم تنظيم الوصول إلى بطاقة الفيديو أو محول الرسومات بواسطة مكون في نواة النظام يُسمى مدير العرض المباشر (DRM). [ 10 ] يجب على كل من برنامج تشغيل DDX الخاص بخادم X وبرنامج تشغيل DRI الخاص بكل عميل X استخدام DRM للوصول إلى وحدة معالجة الرسومات. يوفر DRM مزامنة للموارد المشتركة لوحدة معالجة الرسومات - موارد مثل قائمة الأوامر، وسجلات البطاقة، وذاكرة الفيديو، ومحركات DMA، ... - مما يضمن عدم تداخل الوصول المتزامن لجميع عمليات مساحة المستخدم المتنافسة. كما يعمل DRM كآلية أمان أساسية تمنع أي عميل X من الوصول إلى وحدة معالجة الرسومات بما يتجاوز ما يحتاجه لتنفيذ عملية العرض ثلاثي الأبعاد.

DRI1

في بنية DRI الأصلية، ونظرًا لحجم ذاكرة بطاقات الفيديو آنذاك، كان هناك نسخة واحدة من مخزن الشاشة الأمامي ومخزن الشاشة الخلفي (وكذلك مخزن العمق ومخزن الاستنسل )، مشتركة بين جميع عملاء DRI وخادم X. [ 11 ] [ 12 ] وكانت جميعها تُعرض مباشرةً على المخزن الخلفي، الذي كان يُستبدل بالمخزن الأمامي عند فترات التعتيم الرأسي . [ 11 ] ولكي تُعرض الصورة على المخزن الخلفي، كان على عملية DRI التأكد من أن العرض محصور في المنطقة المخصصة لنافذتها . [ 11 ] [ 12 ]

تمت المزامنة مع خادم X عبر الإشارات ومخزن مؤقت للذاكرة المشتركة يُسمى SAREA. [ 12 ] كان الوصول إلى جهاز إدارة الحقوق الرقمية (DRM) حصريًا، لذا كان على أي عميل DRI قفله في بداية عملية العرض . في هذه الأثناء، كان مستخدمو الجهاز الآخرون - بما في ذلك خادم X - محظورين، وكان عليهم الانتظار حتى يتم تحرير القفل في نهاية عملية العرض الحالية، حتى لو لم يكن هناك أي تعارض بين العمليتين. [ 12 ] من العيوب الأخرى أن العمليات لم تحتفظ بتخصيصات الذاكرة بعد أن حرر عميل DRI الحالي قفله على الجهاز، لذا فقدت أي بيانات تم تحميلها إلى ذاكرة الرسومات، مثل الصور النسيجية ، للعمليات اللاحقة، مما أثر بشكل كبير على أداء الرسومات.

في الوقت الحاضر، يعتبر DRI1 قديمًا تمامًا ويجب عدم استخدامه.

DRI2

نظراً لتزايد شعبية برامج إدارة النوافذ المركبة مثل Compiz ، كان لا بد من إعادة تصميم بنية العرض المباشر (DRI) لتمكين عملاء X من دعم إعادة التوجيه إلى "خرائط البكسل خارج الشاشة" أثناء عملية العرض المباشر. كانت عملاء X العادية تدعم بالفعل إعادة التوجيه إلى خريطة بكسل منفصلة يوفرها خادم X كهدف للعرض - ما يُعرف بخريطة البكسل خارج الشاشة - ، لكن عملاء DRI استمروا في إجراء العرض مباشرةً في المخزن المؤقت الخلفي المشترك، متجاوزين بذلك برنامج إدارة النوافذ المركبة. [ 11 ] [ 13 ] كان الحل الأمثل هو تغيير طريقة تعامل DRI مع مخازن العرض المؤقتة، مما أدى إلى ظهور امتداد DRI مختلف تماماً بمجموعة جديدة من العمليات، بالإضافة إلى تغييرات جذرية في مدير العرض المباشر . [ 3 ] أُطلق على الامتداد الجديد اسم "DRI2"، على الرغم من أنه ليس إصداراً أحدث، بل امتداد مختلف غير متوافق حتى مع DRI الأصلي - في الواقع، تعايش كلاهما داخل خادم X لفترة طويلة.

في DRI2، بدلاً من مخزن مؤقت خلفي مشترك واحد، يحصل كل عميل DRI على مخزن مؤقت خلفي خاص به [ 11 ] [ 12 ] - بالإضافة إلى مخازن العمق والاستنسل المرتبطة به - لعرض محتوى نافذته باستخدام تسريع الأجهزة . ثم يقوم عميل DRI باستبداله بمخزن مؤقت أمامي وهمي [ 12 ] ، والذي يستخدمه مدير نافذة التركيب كأحد المصادر لتكوين (بناء) المخزن المؤقت الخلفي النهائي للشاشة ليتم استبداله بفاصل VBLANK مع المخزن المؤقت الأمامي الحقيقي.

للتعامل مع كل هذه المخازن المؤقتة الجديدة، كان على مدير العرض المباشر (DRI2) دمج وظائف جديدة، وتحديدًا مدير ذاكرة الرسومات . طُوّر DRI2 في البداية باستخدام مدير ذاكرة TTM التجريبي ، [ 11 ] [ 13 ] ولكن أُعيدت كتابته لاحقًا لاستخدام GEM بعد اختياره كمدير ذاكرة DRM نهائي. [ 14 ] كما حلّ نموذج إدارة المخازن المؤقتة الداخلية الجديد في DRI2 مشكلتين رئيسيتين في الأداء كانتا موجودتين في تطبيق DRI الأصلي:

  • لم يعد عملاء DRI2 يقومون بقفل جهاز إدارة الحقوق الرقمية بالكامل أثناء استخدامه للعرض، حيث يحصل كل عميل الآن على مخزن مؤقت منفصل للعرض مستقل عن العمليات الأخرى. [ 12 ]
  • يمكن لعملاء DRI2 تخصيص مخازن مؤقتة خاصة بهم (مع القوام وقوائم الرؤوس وما إلى ذلك) في ذاكرة الفيديو والاحتفاظ بها طالما أرادوا، مما يقلل بشكل كبير من استهلاك عرض النطاق الترددي لذاكرة الفيديو .

في DRI2، يتولى خادم X نفسه تخصيص المخازن المؤقتة الخاصة خارج الشاشة (المخزن المؤقت الخلفي، والمخزن المؤقت الأمامي الوهمي، ومخزن العمق، ومخزن الاستنسل، إلخ) لنافذة العرض. [ 15 ] [ 16 ] تسترجع عملاء DRI هذه المخازن المؤقتة لإجراء عملية العرض في النافذة عن طريق استدعاء عمليات مثل DRI2GetBuffers و DRI2GetBuffersWithFormat المتوفرة في امتداد DRI2. [ 3 ] داخليًا، يستخدم DRI2 أسماء GEM - وهو نوع من المعرفات العامة التي توفرها واجهة برمجة تطبيقات GEM والتي تسمح لعمليتين تصلان إلى جهاز DRM بالإشارة إلى المخزن المؤقت نفسه - لتمرير "مراجع" إلى هذه المخازن المؤقتة عبر بروتوكول X11 . [ 16 ] والسبب في أن خادم X مسؤول عن تخصيص مخازن العرض لنافذة العرض هو أن امتداد GLX يسمح لعدة عملاء X بإجراء عملية عرض OpenGL بشكل تعاوني في نفس النافذة. [ 15 ] بهذه الطريقة، يدير خادم X دورة حياة مخازن العرض بالكامل طوال عملية العرض، ويعرف متى يمكنه إعادة تدويرها أو التخلص منها بأمان. عند تغيير حجم النافذة، يكون خادم X مسؤولاً أيضاً عن تخصيص مخازن عرض جديدة تتناسب مع حجم النافذة الجديد، وإخطار عميل (عملاء) DRI الذي يعرض في النافذة بهذا التغيير باستخدام حدث InvalidateBuffers، حتى يتمكن من استرداد أسماء GEM للمخازن الجديدة. [ 15 ]

يُوفر امتداد DRI2 عمليات أساسية أخرى لعملاء DRI، مثل تحديد جهاز إدارة الحقوق الرقمية (DRM) وبرنامج التشغيل المناسبين ( DRI2Connect )، أو المصادقة من قِبل خادم X لاستخدام إمكانيات العرض والتخزين المؤقت لجهاز إدارة الحقوق الرقمية ( DRI2Authenticate ). [ 3 ] يتم عرض المخازن المؤقتة المُعالجة على الشاشة باستخدام طلبات DRI2CopyRegion و DRI2SwapBuffers . يُمكن استخدام DRI2CopyRegion لنسخ المخزن المؤقت الأمامي الوهمي إلى المخزن المؤقت الأمامي الحقيقي، ولكنه لا يُوفر أي تزامن مع فاصل التعتيم الرأسي، مما قد يُسبب تشويشًا في الصورة . أما DRI2SwapBuffers ، فيُجري تبديلًا مُتزامنًا مع فاصل التعتيم الرأسي بين المخزن المؤقت الخلفي والأمامي، إذا كان ذلك مدعومًا وكان كلا المخزنين بنفس الحجم، أو نسخًا ( blit ) في غير ذلك. [ 3 ] [ 15 ]

DRI3

على الرغم من أن DRI2 مثّلت تحسينًا ملحوظًا عن DRI الأصلية، إلا أن الإضافة الجديدة أدخلت بعض المشكلات الجديدة. [ 15 ] [ 16 ] في عام 2013، طُوّرت نسخة ثالثة من بنية العرض المباشر، تُعرف باسم DRI3، بهدف معالجة تلك المشكلات. [ 17 ]

تتمثل الاختلافات الرئيسية بين DRI3 و DRI2 فيما يلي:

  • يقوم عملاء DRI3 بتخصيص مخازن العرض الخاصة بهم، بدلاً من الاعتماد على خادم X للقيام بالتخصيص، وهي الطريقة التي كان يدعمها DRI2. [ 15 ] [ 16 ]
  • يتخلص بروتوكول DRI3 من آلية مشاركة المخزن المؤقت GEM القديمة غير الآمنة، والتي تعتمد على أسماء GEM (معرّفات GEM العامة) لتمرير كائنات المخزن المؤقت بين عميل DRI وخادم X، لصالح آلية أكثر أمانًا وتعددًا تعتمد على PRIME DMA-BUFs ، والتي تستخدم واصفات الملفات بدلاً من ذلك. [ 15 ] [ 16 ]

يؤدي تخصيص المخزن المؤقت على جانب العميل إلى الإخلال بافتراضات GLX ، حيث لم يعد من الممكن لتطبيقات GLX المتعددة العمل بشكل تعاوني في نفس النافذة. من ناحية أخرى، فإن كون عميل DRI مسؤولاً عن مخازنه المؤقتة طوال فترة عملها يوفر العديد من المزايا. على سبيل المثال، يسهل على عميل DRI3 ضمان تطابق حجم مخازن العرض مع حجم النافذة الحالي، وبالتالي التخلص من التشوهات الناتجة عن عدم تزامن أحجام المخازن المؤقتة بين العميل والخادم، والتي كانت تُعيق تغيير حجم النافذة في DRI2. [ 15 ] [ 16 ] [ 18 ] كما يتحقق أداء أفضل لأن عملاء DRI3 يوفرون الآن رحلة ذهاب وإياب إضافية في انتظار إرسال خادم X لمخازن العرض. [ 16 ] يمكن لعملاء DRI3، وخاصة مديري نوافذ التركيب، الاستفادة من الاحتفاظ بالمخازن المؤقتة القديمة للإطارات السابقة وإعادة استخدامها كأساس لعرض الأجزاء التالفة فقط من النافذة، مما يُعد تحسينًا إضافيًا للأداء. [ 15 ] [ 16 ] لم يعد من الضروري تعديل امتداد DRI3 لدعم تنسيقات المخزن المؤقت الجديدة، حيث تتم معالجتها الآن مباشرةً بين برنامج تشغيل عميل DRI وبرنامج تشغيل نواة DRM. [ 15 ] من ناحية أخرى، يسمح استخدام واصفات الملفات للنواة بإجراء تنظيف آمن لأي كائن مخزن مؤقت GEM غير مستخدم - أي كائن لا يوجد مرجع إليه. [ 15 ] [ 16 ]

من الناحية التقنية، يتكون DRI3 من امتدادين مختلفين، هما امتداد "DRI3" وامتداد "Present". [ 17 ] [ 19 ] يتمثل الغرض الرئيسي من امتداد DRI3 في تنفيذ آلية مشاركة المخازن المؤقتة للعرض المباشر بين عملاء DRI وخادم X. [ 18 ] [ 19 ] [ 20 ] يقوم عملاء DRI بتخصيص واستخدام كائنات مخازن GEM المؤقتة كأهداف للعرض، بينما يُمثل خادم X هذه المخازن المؤقتة باستخدام نوع من كائنات X11 يُسمى "pixmap". يوفر DRI3 عمليتين، هما DRI3PixmapFromBuffer و DRI3BufferFromPixmap ، الأولى لإنشاء pixmap (في "مساحة خادم X") من كائن مخزن GEM المؤقت (في "مساحة عميل DRI")، والأخرى للقيام بالعكس والحصول على كائن مخزن GEM المؤقت من pixmap في X. [ 18 ] [ 19 ] [ 20 ] في عمليات DRI3 هذه، تُمرَّر كائنات مخزن GEM المؤقت كمعرّفات ملفات DMA-BUF بدلاً من أسماء GEM. كما يوفر DRI3 طريقة لمشاركة كائنات التزامن بين عميل DRI وخادم X، مما يسمح بالوصول التسلسلي إلى المخزن المؤقت المشترك. [ 19 ] على عكس DRI2، فإن عملية DRI3Open الأولية - وهي أول عملية يجب على كل عميل DRI طلبها لمعرفة جهاز DRM الذي سيستخدمه - تُعيد معرّف ملف مفتوحًا بالفعل إلى عقدة الجهاز بدلاً من اسم ملف عقدة الجهاز، مع تنفيذ أي إجراء مصادقة مطلوب مسبقًا بواسطة خادم X. [ 18 ] [ 19 ]

لا توفر DRI3 آلية لعرض المخازن المؤقتة المُعالجة على الشاشة، بل تعتمد على إضافة أخرى، وهي إضافة Present ، للقيام بذلك. [ 20 ] سُميت Present بهذا الاسم لأن مهمتها الرئيسية هي "عرض" المخازن المؤقتة على الشاشة، أي أنها تتولى تحديث إطار العرض باستخدام محتويات المخازن المؤقتة المُعالجة التي توفرها تطبيقات العميل. [ 19 ] يجب إجراء تحديثات الشاشة في الوقت المناسب، عادةً خلال فترة VBLANK ، لتجنب تشوهات العرض مثل التقطيع . تتولى Present أيضًا مزامنة تحديثات الشاشة مع فترة VBLANK. [ 21 ] كما أنها تُبقي عميل X على اطلاع بلحظة عرض كل مخزن مؤقت على الشاشة باستخدام الأحداث، حتى يتمكن العميل من مزامنة عملية العرض مع معدل تحديث الشاشة الحالي.

تقبل مكتبة Present أي صورة نقطية X كمصدر لتحديث الشاشة. [ 21 ] وبما أن الصور النقطية هي كائنات X قياسية، يمكن استخدام Present ليس فقط من قبل عملاء DRI3 الذين يقومون بالرسم المباشر، بل أيضًا من قبل أي عميل X يقوم بالرسم على صورة نقطية بأي طريقة. [ 18 ] على سبيل المثال، اعتادت معظم تطبيقات GTK+ و Qt الحالية غير القائمة على GL على استخدام XRender في رسم الصور النقطية باستخدام التخزين المؤقت المزدوج . ويمكن لهذه التطبيقات أيضًا استخدام امتداد Present لتحقيق تحديثات شاشة فعالة وسلسة. لهذا السبب تم تطوير Present كامتداد مستقل بدلاً من أن يكون جزءًا من DRI3. [ 18 ]

إلى جانب تمكين عملاء X غير المتوافقين مع OpenGL من المزامنة مع VBLANK، يوفر Present مزايا أخرى. يُحسّن Present أداء الرسومات في DRI3 لأنه أكثر كفاءة من DRI2 في تبديل المخازن المؤقتة. [ 19 ] كما يدعم Present الآن عددًا من امتدادات OpenGL التي لم تكن متوفرة في DRI2، وذلك بفضل الميزات الجديدة التي يوفرها. [ 19 ]

توفر مكتبة Present عمليتين رئيسيتين لعملاء X: تحديث منطقة من نافذة باستخدام جزء من محتويات خريطة بكسل أو كلها ( PresentPixmap )، وتحديد نوع أحداث العرض المتعلقة بنافذة معينة والتي يرغب العميل في تلقي إشعارات بشأنها ( PresentSelectInput ). [ 19 ] [ 21 ] هناك ثلاثة أحداث عرض يمكن للنافذة إخطار عميل X بها: عند اكتمال عملية عرض جارية - عادةً من خلال استدعاء PresentPixmap - ( PresentCompleteNotify )، وعندما تكون خريطة البكسل المستخدمة في عملية PresentPixmap جاهزة لإعادة الاستخدام ( PresentIdleNotify )، وعند تغيير إعدادات النافذة - وخاصةً حجمها ( PresentConfigureNotify ) . [ 19 ] [ 21 ] يُعدّ ما إذا كانت عملية PresentPixmap تُجري نسخًا مباشرًا ( blit ) إلى المخزن المؤقت الأمامي أو تبديلًا للمخزن المؤقت الخلفي بالكامل مع المخزن المؤقت الأمامي تفصيلاً داخليًا في تطبيق امتداد Present، بدلاً من كونه خيارًا صريحًا من عميل X كما كان الحال في DRI2.

التبني

تم تطوير العديد من برامج تشغيل DRI مفتوحة المصدر، بما في ذلك برامج تشغيل لبطاقات الرسومات ATI Mach64 وATI Rage128 وATI Radeon و3dfx Voodoo3 إلى Voodoo5 و Matrox G200 إلى G400 وSiS 300-series و Intel i810 إلى i965 و S3 Savage و VIA UniChrome، بالإضافة إلى برنامج nouveau لبطاقات Nvidia . في المقابل، قام بعض موردي بطاقات الرسومات بتطوير برامج تشغيل DRI مغلقة المصدر، مثل ATI و PowerVR Kyro.

تم تطبيق الإصدارات المختلفة من DRI بواسطة أنظمة تشغيل مختلفة، من بينها نواة لينكس ، و FreeBSD ، و NetBSD ، و OpenBSD ، و OpenSolaris .

تاريخ

بدأ المشروع كلٌ من ينس أوين وكيفن إي. مارتن من شركة بريسيجن إنسايت (بتمويل من شركتي سيليكون غرافيكس وريد هات ). [ 1 ] [ 22 ] وقد أُتيح المشروع لأول مرة على نطاق واسع كجزء من XFree86 4.0 [ 1 ] [ 23 ] وهو الآن جزء من خادم X.Org . ويتولى مجتمع البرمجيات الحرة صيانته حاليًا .

بدأ العمل على DRI2 في قمة مطوري X لعام 2007 بناءً على اقتراح من كريستيان هوغسبيرغ . [ 24 ] [ 25 ] قام هوغسبيرغ نفسه بكتابة امتداد DRI2 الجديد والتعديلات على Mesa و GLX . [ 26 ] في مارس 2008، كان بروتوكول DRI2 جاهزًا إلى حد كبير، [ 27 ] [ 28 ] [ 29 ] ولكنه لم يُدرج في الإصدار 1.5 من خادم X.Org [ 14 ] ، واضطر إلى الانتظار حتى الإصدار 1.6 في فبراير 2009. [ 30 ] أُدرجت إضافة DRI2 رسميًا في إصدار X11R7.5 في أكتوبر 2009. [ 31 ] أُعلن عن أول إصدار عام من بروتوكول DRI2 (2.0) في أبريل 2009. [ 32 ] ومنذ ذلك الحين، صدرت عدة مراجعات، كان آخرها الإصدار 2.8 في يوليو 2012. [ 4 ]

نظراً لعدة قيود في بروتوكول DRI2، اقترح كيث باكارد وإيما أنهولت إضافة جديدة تُسمى DRI-Next في مؤتمر مطوري X.Org لعام 2012. [ 15 ] ثم أُعيد اقتراح هذه الإضافة باسم DRI3000 في مؤتمر Linux.conf.au لعام 2013. [ 16 ] [ 17 ] وتم تطوير إضافتي DRI3 وPresent خلال عام 2013، ثم دُمجتا في إصدار X.Org Server 1.15 ابتداءً من ديسمبر 2013. [ 33 ] [ 34 ] وصدر الإصدار الأول والوحيد من بروتوكول DRI3 (1.0) في نوفمبر 2013. [ 5 ]

انظر أيضاً

مراجع

  1. 1 2 3 أوين، ينس. "تاريخ مشروع DRI" . ويكي مشروع DRI . تم الاطلاع عليه بتاريخ 16 أبريل 2016 .
  2. 1 2 3 معلومات ترخيص /حقوق النشر لمكتبة ميسا للرسومات ثلاثية الأبعاد
  3. 1 2 3 4 5 6 هوغسبيرغ، كريستيان (4 سبتمبر 2008). "امتداد DRI2 - الإصدار 2.0" . X.Org . تم الاسترجاع في 29 مايو 2016 .
  4. 1 2 إيرلي، ديف (11 يوليو 2012). " [ إعلان ] dri2proto 2.8" . xorg-announce (قائمة بريدية).
  5. 1 2 3 باكارد، كيث (1 نوفمبر 2013). " [ إعلان ] dri3proto 1.0" . xorg-announce (قائمة بريدية).
  6. 1 2 "ويكي بنية Mesa ثلاثية الأبعاد والعرض المباشر" . تم الاطلاع عليه بتاريخ 15 يوليو 2014 .
  7. ^ "DRI لوحدات تحكم Framebuffer" . تم الاسترجاع في 4 يناير، 2019 .
  8. ↑ مارتن، كيفن إي.؛ فيث، ريكارد إي.؛ أوين، ينس؛ أكين، ألين (11 مايو 1999). "بنية العرض المباشر، وثيقة تصميم منخفضة المستوى" . مؤرشفة من الأصل في 23 يوليو 2016. تم الاطلاع عليها في 18 مايو 2016 .
  9. ↑ أوين، ينس؛ مارتن، كيفن (11 مايو 1999). "امتداد DRI لدعم العرض المباشر - مواصفات البروتوكول" . تم الاسترجاع في 18 مايو 2016 .
  10. ↑ فيث، ريكارد إي. (11 مايو 1999). "مدير العرض المباشر: دعم النواة لبنية العرض المباشر" . مؤرشف من الأصل في 21 مايو 2024. تم الاطلاع عليه في 18 مايو 2016 .
  11. 1 2 3 4 5 6 باكارد، كيث (21 يوليو 2008). "حالة مخرجات X يوليو 2008" . تم الاسترجاع في 26 مايو 2016 .
  12. 1 2 3 4 5 6 7 باكارد، كيث (24 أبريل 2009). "تعزيز تركيز إنتل على برامج التشغيل" . تم الاطلاع عليه بتاريخ 26 مايو 2016 .
  13. 1 2 هوغسبيرغ، كريستيان (8 أغسطس 2007). "إعادة توجيه العرض المباشر" . تم الاسترجاع في 25 مايو 2016 .
  14. 1 2 هوغسبيرغ، كريستيان (4 أغسطس 2008). "نسخ DRI2 من الخادم 1.5" . xorg (القائمة البريدية).
  15. 1 2 3 4 5 6 7 8 9 10 11 12 باكارد، كيث (28 سبتمبر 2012). "أفكار حول DRI.Next" . تم الاطلاع عليه بتاريخ 26 مايو 2016 .
  16. 1 2 3 4 5 6 7 8 9 10 ويليس، ناثان (11 فبراير 2013). "LCA: رجال إكس يتحدثون" . LWN.net . تم الاطلاع عليه بتاريخ 26 مايو 2016 .
  17. 1 2 3 باكارد، كيث (19 فبراير 2013). "DRI3000 - عرض مباشر أفضل" . تم الاسترجاع في 26 مايو 2016 .
  18. 1 2 3 4 5 6 باكارد، كيث (4 يونيو 2013). "إكمال امتداد DRI3" . تم الاسترجاع في 31 مايو 2016 .
  19. 1 2 3 4 5 6 7 8 9 10 إيدج، جيك (9 أكتوبر 2013). "DRI3 والحاضر" . LWN.net . تم الاطلاع عليه بتاريخ 26 مايو 2016 .
  20. 1 2 3 باكارد، كيث (4 يونيو 2013). "امتداد DRI3 - الإصدار 1.0" . تم الاطلاع عليه في 30 مايو 2016 .
  21. 1 2 3 4 باكارد، كيث (6 يونيو 2013). "امتداد الحاضر - الإصدار 1.0" . تم الاسترجاع في 1 يونيو 2016 .
  22. ↑ أوين، ينس؛ مارتن، كيفن إي. (15 سبتمبر 1998). "بنية عرض مباشر متعددة الأنابيب للرسومات ثلاثية الأبعاد" . مؤرشف من الأصل في 3 مارس 2016. تم الاطلاع عليه في 16 أبريل 2016 .
  23. ↑ "ملاحظات الإصدار لـ XFree86 4.0" . مشروع XFree86 . 7 مارس 2000. تم الاطلاع عليه بتاريخ 16 أبريل 2016 .
  24. ↑ "قمة مطوري X لعام 2007 - ملاحظات" . X.Org . تم الاطلاع عليه في 7 مارس 2016 .
  25. ^ هوجسبيرج ، كريستيان (3 أكتوبر 2007). "صفحة ويكي تصميم DRI2" . xorg (القائمة البريدية).
  26. ^ هوجسبيرج ، كريستيان (4 فبراير 2008). "خطط لدمج عمل DRI2" . xorg (القائمة البريدية).
  27. ^ هوجسبيرج ، كريستيان (15 فبراير 2008). "ملتزم DRI2" . xorg (القائمة البريدية).
  28. ^ هوجسبيرج ، كريستيان (31 مارس 2008). "العرض المباشر DRI2" . xorg (القائمة البريدية).
  29. ^ هوجسبيرج ، كريستيان (31 مارس 2008). "العرض المباشر DRI2" . تم الاسترجاع 20 أبريل 2016 .
  30. ↑ "فرع الخادم 1.6" . X.org . تم الاطلاع عليه بتاريخ 7 فبراير 2015 .
  31. ↑ "ملاحظات الإصدار لـ X11R7.5" . X.Org . تم الاطلاع عليه بتاريخ 20 أبريل 2016 .
  32. ^ هوجسبيرج ، كريستيان (20 أبريل 2009). " [ إعلان ] dri2proto 2.0" . xorg-announce (القائمة البريدية).
  33. ↑ باكارد، كيث (نوفمبر 2013). " [ إعلان ] خادم xorg 1.14.99.901" . X.org . تم الاطلاع عليه في 9 فبراير 2015 .
  34. ↑ لارابيل، مايكل. "إصدار خادم X.Org 1.15 يتضمن العديد من الميزات الجديدة" . فورونيكس . تم الاطلاع عليه بتاريخ 9 فبراير 2015 .