abshammeri

GPU و GPGPU و OpenCL و OpenGL و CUDA و ما إلى ذلك .

8 ردود في هذا الموضوع

لا أعرف ما تقصد بالمكتبة الثالثة و لكني توقعت أنك تقصد DirectCompute و التي ظهرت مع ظهور DirectX 11 و هذه مجموعة دروس فيديو من Channel9 لشرح استخدامها

http://channel9.msdn.com/tags/DirectCompute/

2

شارك هذا الرد


رابط المشاركة
شارك الرد من خلال المواقع ادناه

@motamayez

الopenclتحتوى ايضاء نفس الاسلوب

OpenCL includes a language (based on C99) for writing kernels (functions that execute on OpenCL devices), plus APIs that are used to define and then control the platforms. OpenCL provides parallel computing using task-based and data-based parallelism. Its architecture shares a range of computational interfaces with two competitors, NVidia's Compute Unified Device Architecture and Microsoft's DirectCompute.

اذا اردتم معرفة بعض قدرات opencl فهناك بعض فيديوهات luxrender المعروف انة من الممكن ترك الجهاز يرندر فى صورة بسيطة ليومين متتالين

اذهب للدقيقة 3:20 لروية التصيير فى الوقت الحقيقى بعد تحسينة لopencl

وايضاء من التطبيقات الحسابية التى تنوى استغلال المكتبة هى مكتبة bullet الفيزيائية .

عموما اتوقع انتشار اكبر لتقنية التسريع تلك فى المستقبل والعمل بتوازى مع الcpu وترك الاعمال المناسبة لكل منهم .اى صداع اخر كالذى القتنا فية شركات المعالجات بmulti core وجعلتنا تنفكر فى كيفية توزيع وتنظيم العمل مع كل تلك الthreads (فى خلال شهور سينزل معالج 32 نواة) بل ايضاء سيضيفوا الى معادلة التسريع وللحاق باستغلال العتاد الحديث متغير اخر يزيد الامور تعقيد (نظرة تشائمية :unsure: )

تم تعديل بواسطه apex
0

شارك هذا الرد


رابط المشاركة
شارك الرد من خلال المواقع ادناه

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

موضوع جميل :)

لم أشارك في النقاش الذي دار في موضوع آخر في الحقيقة, و لكن يبدو أن النظرة للـ gpgpu على أنه المستقبل تحتاج إلى توسيع النقاش. ربما, كقدرة حسابية يعتبر أي gpgpu بمثابة supercomputer منزلي! و لكن هناك نقاط لابد من التعرض لها, قبل أن يفكر أي شخص باستخدام الـ gpgpu "لتسريع" برامجه.

أولاً, أكثر من 99% إن لم يكن أكثر من البرامج ليست Computationally Bounded. بمعنى آخر, البطئ الحاصل في أداء البرنامج ليس سببه المعالج, و إنما عمليات الـ I/O. لذلك, لو أراد شخص تطوير جهازه المنزلي فأفضل ما يقوم به هو تركيب SSD hard disk بدلاً من أي معالج من النوع الصاروخي. هذه النقطة تعني أن الغالبية العظمى من البرامج لن تستفيد من الـ gpgpu.

بالنسبة لباقي البرامج التي تستفيد حقاً من هذه التكنلوجيا, فهناك عدة نقاط.

أولاً, لو نظرنا إلى الفروق في أداء المعالجات cpu فلن تجد فرقاً شاسعاً في أدائها إلا لو خرجت من دائرة الحواسيب المنزلية و الحواسيب المحمولة إلى المنصات التي تعمل على عدة معالجات. أما بالنسبة للـ gpgpu فهناك مدى واسع جداً, من الـ integrated graphics cards الهزيلة, إلى تقنيات SLI و CrossFire باستخدام أحدث زوج من الـ graphics cards و كل هذا موجود لدى هواة الألعاب في المنازل! اسألوا هيثم عن الموضوع :P لهذا, لا يمكنك افتراض توفر أداء متوسط للحواسيب الشخصية كماهو الحال بالنسبة للمعالجات العادية.

الأمر الآخر, هو الـ Compatibility بين أنواع الـ gpgpu, ربما يكون OpenCL هو الحل و لكن يحتاج إلى وقت بالطبع.

حتى لو توفرت كل تلك الشروط, لكي تكون العملية أسرع على gpgpu منها على cpu, فلابد أن تكون الحسابات كثيرة. طبعاً كلام عام, و لكن قرأت في أماكن عدة عن طرق تقريبية لمعرفة متى ينصح باستخدام gpgpu و متى لا ينصح. فمثلاً, تصور أن لدينا مصفوفتان كل واحد منهما عبارة عن مليون عنصر(عدد). الآن لو أدرنا جمع المصفوفتين في مصفوفة ثالثة باستخدام gpgpu فسنحتاج إلى إحضار عنصر من المصفوفة الأولى و عنصر من المصفوفة الثانية و إعادة الناتج. و هذا يعني أن هناك ثلاث عمليات نقل من الذاكرة إلى ذاكرة الـ gpgpu و كل ما قمنا به هو عملية جمع واحدة. لذلك ستكون هذه العملية - قطعاً - أسرع على cpu. بالطبع هناك حالات يكون فيها كم الحسابات هائل مقارنة بعمليات الإحضار و الإعادة من الذاكرة الرئيسية و هنا يكون الـ gpgpu أسرع.

أخيراً, كم عدد المبرمجين الذي لديهم فكرة عن الـ Multiprocessing بشكل عملي يسمح لهم بكتابة خوارزمية مهمة في برنامج! (أنا لست منهم :lol: )

صحيح أنه سيكون هناك abstractions و لكن الأساسيات لابد أن تكون موجودة.

تحياتي...

5

شارك هذا الرد


رابط المشاركة
شارك الرد من خلال المواقع ادناه

بالنسبة لـ Direct Compute ، فستكون حكراً على تطبيقات شركة Microsoft تقريباً ( أعتقد أنها ستسوّق المنتج في بيئة الدوت نت ، وفي بعض تطبيقاتها ) ، ولكن الأمر مختلف كثيراً ..

فالأمر مختلف ، وليس مثل قصة OpenGL و Direct3D ..

فأي جهاز يستطيع تشغيل Direct Compute ، فشيء طبيعي أن يتمكن من تشغيل OpenCL ( في الغالب مواصفات OpenCL يتم حديثها بسرعة بفضل الجهة المشرفة عليها ) ،

أيضاً OpenCL يعمل على أكثر من نظام تشغيل يما فيها Windows XP ، بينما DirectCompute لا يعمل إلا على Vista و XP .

و OpenCL له Binding لعدة لغات بما فيها بيئة الدوت نت ..

بل حتى أن OpenCL مصمّمة بحيث يمكن أن تتخاطب مع Direct3D !

ولا أظن أن مؤلفي الكتب و لا المبرمجين ولا دكاترة الجامعات .. سيتعبون أنفسهم بتعلم تقنية في مجال محدود ، ويوجد تقنية بنفس المستوى أو أفضل وتوجد في كل مكان .. وهذا كفيل بانتشار OpenCL .

عموماً هذا متوقع .. فلا أظن أن Mictosoft ستتنازل و تعتمد OpenCL ، ومن يحمل حقوق الفكرة هي Apple ( التي أتاحتها لمجموعة Khronos ) .

==

الأخ خالد أشار لنقطة مهمة ، وهي مسألة أن المشكلة في I/O أكثر من قصة سرعة المعالجة ..

أولاً, أكثر من 99% إن لم يكن أكثر من البرامج ليست Computationally Bounded. بمعنى آخر, البطئ الحاصل في أداء البرنامج ليس سببه المعالج, و إنما عمليات الـ I/O. لذلك, لو أراد شخص تطوير جهازه المنزلي فأفضل ما يقوم به هو تركيب SSD hard disk بدلاً من أي معالج من النوع الصاروخي. هذه النقطة تعني أن الغالبية العظمى من البرامج لن تستفيد من الـ gpgpu.

الكلام صحيح " وفاتتني " هذه النقطة بصراحة ..

لكن في الغالب ، التطبيقات التي تعتمد على عمليات القراءة و الكتابة من و إلى القرص الصلب ، تطبيقات معروفة ، مثل " قواعد البيانات " ..

لكن نسبة 99% ، أظن فيها شوي مبالغة :-) ،

خذ مثلاًً : البرامج التي تعتمد على برمجة الرسوميات بشكل أو بآخر ( برامج التصميم - المتصفحات ( عملية Rendering ) -- الخ .. ) ، برامج الملتيميديا ، الأوفيس ، تطبيقات الذكاء الاصطناعي و الخوارزميات بشكل عام ( خذ مثلاً عملية البحث في الشجرة .. البحث بطريقة Depth First Search ) .. والكثيييير ..

حتى Apple ، قرأت أنها تستخدم OpenCL في كل مكتباتها الرسومية والملتيميديا ( في آخر إصداراتها من MAC ) ،

أخيراً, كم عدد المبرمجين الذي لديهم فكرة عن الـ Multiprocessing بشكل عملي يسمح لهم بكتابة خوارزمية مهمة في برنامج!

طبعاً معلوماتي ضحلة في هذا المجال ، ولكن لا مانع من أن نبدأ من High level مثل ما بيقولوا .. ولا يجب أن نفهم كل شيء دفعة واحدة ،

ولكن مميزات OpenCL مشوّقة بصراحة :-) .. يعني أفكر الآن بتطبيق خوازمية من خوارزميات البحث في الأشجار Trees ، بالاستفادة من هذا العتاد الجديد .. وحينها أظن أنه يمكن أن نتغلّب على "Deep Blue " ، بسرعة :-) ... بدلاً من الاعتماد على خوارزميات معقدة .

لكن الأمر يحتاج وقت وجهد حتى يمكن تطوير تطبيقات باستخدام OpenCL .

- http://labs.qt.nokia.com/2010/04/07/using-opencl-with-qt/

2

شارك هذا الرد


رابط المشاركة
شارك الرد من خلال المواقع ادناه

مقال ممتاز و فتح عيني على أشياء كنت أتجاهلها كثيراً حتى أنني لم أكتفي بالمقال و بحثت هنا و هناك عن أي مقال أخر يتكلم عن الموضوع و من ضمن البحث كنت أبحث في اليوتيوب و وجدت هذا الفيديو الذي يوضح الفرق فعلا

2

شارك هذا الرد


رابط المشاركة
شارك الرد من خلال المواقع ادناه

أولاً, أكثر من 99% إن لم يكن أكثر من البرامج ليست Computationally Bounded. بمعنى آخر, البطئ الحاصل في أداء البرنامج ليس سببه المعالج, و إنما عمليات الـ I/O. لذلك, لو أراد شخص تطوير جهازه المنزلي فأفضل ما يقوم به هو تركيب SSD hard disk بدلاً من أي معالج من النوع الصاروخي. هذه النقطة تعني أن الغالبية العظمى من البرامج لن تستفيد من الـ gpgpu

امم هذا عندما نتكلم عن برنامج الصيدليه مثلا ,, او البرامج المرتبطه بالجهاز نفسه (مثلا Windowing System أو Interpreter )

ولكن عندما نتكلم عن الحسابات العلميه والمجالات الاخرى المستفيده من الكمبيوتر ك number cruncher ,, فكلها Computationally Bound بشكل بشع ,, ولولا هذا لما كان ال Supercomputer مثلا

الفكره ان فعلا غالبا المستخدم العادى لن يستفيد او يحس بشكل مباشر (مثلا واحد كل علاقته هى ال Office وال IE ) ولكن اخرون ك هواه الالعاب او برامج المحاكاه وبالطبع من يستخدمونه فى حسابات ذات هدف سيستفيدون بشده

مازالت البرمجه صعبه وال Abstractions سيئه جدا ,ولكننا مازلنا فى البدايه

صور أن لدينا مصفوفتان كل واحد منهما عبارة عن مليون عنصر(عدد). الآن لو أدرنا جمع المصفوفتين في مصفوفة ثالثة باستخدام gpgpu فسنحتاج إلى إحضار عنصر من المصفوفة الأولى و عنصر من المصفوفة الثانية و إعادة الناتج

بالعكس هذا المثال بالذات من اهم مميزاتها ,, ببساطه لن ترسل البيانات لل gpu فى كل مره عنصر عنصر ,, وانما سترسل المصفوفه كلها او جزء كبير منها وتبدأ فى ال Reduction وترى الفرق البشع مع ال cpu

النقطه الحقيقيه هنا هى ان اهم مشكله تبدأ من اداء اى خوارزم على ال gpu هو ال I/O لان السرعه بين الكرت وال main memory بطيئه (مقارنه مثلا بسرعه تواصله مع الذامره الداخليه له )

لهذا تجد كروت عملاقه من نفيديا بدأت فى الظهور (اخرها على ما اعرف ذاكرته 6 جيجا :D )

التكامل بين ال Ogl وال Ocl او غيرها يعطى نتائج جميله جدا من اشهرها ال real time rendering

اجمل شىء ان الكروت نفسها ليست غاليه الثمن (على الاقل الضعيف منها :P ) وتستطيع التجربه بسهوله على اى كرت GeForce 8800 من فجر التاريخ (الحصول على الكروت الحديثه على فكره مكلف جدا ,, ستجدهم مثلا يحسبون الدولار ب 8 جنيه واكثر <بدل من 5.6 السعر الرسمى فى مصر> )

لا أظن أن مؤلفي الكتب و لا المبرمجين ولا دكاترة الجامعات .. سيتعبون أنفسهم بتعلم تقنية في مجال محدود ، ويوجد تقنية بنفس المستوى أو أفضل وتوجد في كل مكان .. وهذا كفيل بانتشار OpenCL .

بالعكس ,, عن بحث و كما ذكرت سابقا هنا فعلا دعم ال Ocl سىء جدا مقارنه بال CUDA

Nvidia تقدم دعم و tools ضخمه لل CUDA لا يوجد الا عشر هذا الاهتمام لل Ocl ,, فعلا اخذت الاحساس وانا استعملها انى اعامل معامله مبرمجى الاسمبلى :P

وحتى تصدقنى ابحث فى google scholar مثلا عن عدد ال papers التى تستخدم ال Ocl وقارنها بالتى تستخدم ال CUDA (طبعا ال DC تبع ميكو حاجه كده غريبه ,, اظن غالبا اما ستموت فريبا او ميكو ستقوم بجهد ضخم لتسويقها )

2

شارك هذا الرد


رابط المشاركة
شارك الرد من خلال المواقع ادناه

موضوع مميز بارك الله فيكم

اتعامل حاليا مع OpenCL هي مذهلة فعلا

0

شارك هذا الرد


رابط المشاركة
شارك الرد من خلال المواقع ادناه

من فضلك سجل دخول لتتمكن من التعليق

ستتمكن من اضافه تعليقات بعد التسجيل



سجل دخولك الان

  • يستعرض القسم حالياً   0 members

    لا يوجد أعضاء مسجلين يشاهدون هذه الصفحة .