الفريق العربي للبرمجةأرشيف المنتديات · 2000 – 2023
نسخة أرشيفية للقراءة فقط — التسجيل والمشاركة مغلقان، والمحتوى محفوظ كما كان.

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

بدأه Abdullah.Alshammeri في 3 أكتوبر 2010 · 7 رد · 11,651 مشاهدة · في المقالات العلمية و التقنية
مشاركة: واتساب X فيسبوك تيليجرام
#1 صاحب الموضوع

السلام عليكم ،

مقدمة :

اشتريت قبل يومين " لوحة مفاتيح " Microsoft الأصلية ، الغالية الثمن ( سبعين ريال ) ، وهي متميزة وتثير لديك شهوة الكتابة عن أشياء لا تعرف عنها الكثير ، وهذا المقال من هذه الأشياء.

المرحلة الأولى - الحياة بسيطة :

قام الحاسوب على مفهوم Turing Machine ، وهو تصوّر جائنا من زميل المهنة Turing لجهاز الكمبيوتر .. خلاصته أن البيانات تنتقل من القرص الصلب Hard-desk إلى الذاكرة ، ومن يقوم بمعالجة تلك البيانات شيء اسمه معالج واختصاره هو CPU .. مرّت ثلاثين سنة على هذه الفكرة والتي أصبحت هي المعتمدة في كل جهاز حاسوب تقريباً في مطلع ثمانينات القرن الماضي .

بعد ولادتي بسنتين .. وقع حدثُ هام ( بالإضافة لحدث ظهوري على وجه البسيطة) ، حيث ظهرت مكتبة ( أصبحت قياسية ) ، تحمل اسم OpenGL وذلك في عام 1990 تقريباً . المكتبة الرسومية استفادت لاحقاً من " كونها قياسية " ، وصار كل صانع من صنّاع البطاقات الرسومية Graphics Card ، يعمل implementation خاص به ، يستفيد من قدرات Hardware لتسريع عملية الرسوم . المبرمج في ذلك الوقت وجد أمامه مجموعة من " الدوال " APIs ، التي يستدعيها ليقوم بتغيير حالة متغيرات معينة ، فتقوم " بطاقة الرسوميات " بالاستجابة لهذه التغييرات.. مثال :

	void display()
	{
		// Tell the Graphics Card to clear the color buffer.
		clearTheBuffer()

		// Load Data Into the main memory
		loadData()

		// Do Some Math Calculations
		Matrix result = modelMatrix * viewMatrix * projectionMatrix

		// Tell the Graphics Card to change the alpha state to " Enabled " 
		enableAlphaTesting(1,LessThan)

		// Draw
		drawMesh(data);

		disableAlphaTesting()

	}

- لاحظ أن أغلب البيانات ، سنجدها في الذاكرة الرئيسية Main Memory ، حسب نصيحة زميل المهنة Turing .

- لاحظ أن عملية ضرب المصفوفات تحتاج إلى CPU ، وهو المسؤول عنها .

- لاحظ أنك تطلب من البطاقة الرسومية تفعيل " الشفافية " ومن ثم رسم المجسم ومن ثم ايقاف الشفافية حتى لا تتأثر بقية الأجسام .

البرامج الرسومية و الألعاب تصيب المعالج بإجهاد كبير ، وعملية نقل البيانات من المعالج إلى الذاكرة الرئيسية إلى البطاقة الرسومية ، تستهلك وقت وجهد ، بل أن النموذج السابق يحمل اسم Fixed-pipeline ، ويعني أن OpenGL كمكتبة رسومية قائمة على أمور ثابتة ومبرمجة مسبقاً ، بحيث تطلب من البطاقة الرسومية تغيير حالة ما .. فيظهر هذا على الشاشة .. فلا تستطيع مثلاً أن تتحكم بالمعادلة المسؤولة عن الشفافية .. فكل ما عليك أن تقوله هو : فعّل أو لا تفعّل .. Enable Or Disable .

المرحلة الثانية - : GPU

بعد 12 سنة من ولادتي ، وتحديداً عندما انتهيت من الصف السادس الابتدائي ، ظهرت أفكار جديدة لعلاج مشاكل البرامج الرسومية و الألعاب ، وتتمحور حول مبدأ أساسي :

لماذا لا نضع معالج خاص + ذاكرة خاصة للبرامج الرسومية المبنية على OpenGL و أشباهها ؟

لماذا لا نسمح للمبرمج بكتابة معادلاته التي يريد تطبيقها على كل بكسل وعلى كل رأس Vertex ؟

بدأت الأفكار تطبخ وتطبخ حتى وصلت للنضوج مع دخولي للمرحلة الثانوية . فظهر أمامنا مفهوم GPU ( عفواً .. ليس مفهوم ، إنما Hardware وهو عبارة عن معالج مركزي خاص للمكتبات الرسومية مثل CG و OpenGL و Direct3D ) .

GPU : اختصار لمصطلح Graphics Processing Unit و الذي حصل باختصار ، أن عمليات المعالجة انتقلت من CPU إلى GPU ( طبعاً لا يعني هذا الاستغناء عن CPU ) ، فمثلاً علمية ضرب المصفوفات ، وعملية معالجة كل بكسل ، وعمليات أخرى تجري على وحدة GPU ومابين ذاكرة ومعالج البطاقة الرسومية .. فوصلنا لسرعة وقدرة عالية مع نتائج مبهرة .. وذلك لأنك أمام معالج رسومي عملاق و قوي .

المرحلة الثالثة - GPGPU :

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

من هنا ظهر مفهوم GPGPU : وهو اختصاراً لـ General Purpose Graphics Processing Unit .. يعني " الغايات العامّة من وحدة المعالجة الرسومية " .. فظهرت مقالات وتطبيقات تستفيد فعلاً من إمكانية GPU ، لم ننتظر طويلاً حتى ظهرت CUDA و OpenCL و مكتبة ثالثة لا أريد أن أعمل لها دعاية دون مقابل :/ .

نسيت أن أخبركم أن مفهوم GPGPU بد أ يتبلور عندما وطأت قدماي أرض الجامعة .

المرحلة الرابعة - OpenCL و CUDA :

ظهرت الحاجة لمكتبة قياسية تستفيد من العدد الضخم من الأنوية cores وبالتالي تطبيق مبدأ البرمجة المتوازية ، بل والاستفادة من قدرات GPU الحسابية السريعة و الدقيقة ، حتى لو لم يكن التطبيق رسومي .

لم أنتهي من المرحلة الجامعية إلا و مصنعوا البطاقات الرسومية قد طوّروا من قدرات GPU ، ليخدم قطاعات أخرى ، ولعل خطوة شركة انفيديا في هذا المجال هي الأبرز من حيث تطوير CUDA وهي معمارية ظهرت على يد شركة انفيديا وتعمل على بطاقات انفيديا الرسومية ، و يمكن من خلالها تطوير تطبيقات لا علاقة لها بالرسوميات ( ويمكن استخدامها طبعاً مع التطبيقات الرسومية ) ، وطبعاً يمكن الاستفادة من هذه المعمارية من خلال لغة C ولغات أخرى .

ومن ثم ظهرت مكتبة OpenCL من مختبرات Apple والتي أصبحت الآن تحت عهدة Khronos ( نفس الجهة التي تشرف على مواصفات OpenGL ) ، وبالتالي أصبحت مكتبة قياسية يشارك في وضع قياساتها ومن ثم عمل implementation لها ، عدة شركات ضخمة AMD, IBM, Intel, و Nvidia بالاضافة لـ Apple طبعاً .

تتميز OpenCL بقدرتها على العمل على أي قطعة hardware ,التي تسمى Device ، فهي قد تعمل على CPU وتستفيد من ,multi-core CPU .. وقد تعمل على GPU (لو كنت تملك واحداً ) . علماً أن عدد " أنوية " المعالج المركزي CPU قد تصل لثمانية أنوية أو أقل من هذا ( مثل Intel i7 ) .. أما في حالة GPU فأنت أمام عشرات الأنوية التي تتسابق لخدمتك ( قد تصل لمئات ) .

OpenCL و CUDA لهما نفس الهدف تقريباً .. ولكن التوجه الآن هو بدعم OpenCL بشكل كامل ، باعتبارها قياسية وستعمل على أكثر من بطاقة رسومية وعلى أكثر من نظام تشغيل ، بل وحتى على أكثر من لغة برمجية .بالتالي أصبحنا بغنى عن التطفل على مبرمجي الرسوميات واستخدام أدواتهم مثل لغة GLSL أو HLSL لاستغلال قوّة GPU في أمور غير رسومية ، بل هناك ما يسمّى بـ kernel في OpenCL وهي لغة خاصة صممّت لهذا الغرض ( مبنية على مواصفات لغة سي ) .

مالذي يمكنك أن تفعله باستخدام OpenCL ؟

OpenCL : هدفها الأساسي هو تسريع تنفيذ الخوارزميات ( معظمها ولكن ليس كلها ) ، فخذ مثلاً :

- لو حاولت إيجاد القيمة المطلقة abs لمجموعة أعداد موجودة في مصفوفة ،

يمكنك الاستفادة من Parallel programming التي تدعمها OpenCL ( البرمجة المتوازية أو المعالجة المتوازية Parallel Processing ) ، لتنفيذ هذه الفكرة ، وبالتالي تنفيذ هذه الخوارزمية على عشرات الأنوية ( Multi-core ) ، بدلاً من معالج واحد .. وبدلاً من البحث عن لغة برمجية مستقلة تدعم مفهوم البرمجة المتوازية ..

- يمكن أيضاً أن تتكامل OpenCL مع OpenGL أو Direct3D .. حيث البيانات يمكن تبادلها فيما بينهما ، أي أنه يمكن أن تخبر OpenCL بتغيير قيم مصفوفة بيانات ما .. وستتأثر OpenGL بشكل مباشر دون تدخل منك ، بمجرد أن تطلب من OpenCL ذلك عند إنشاء Context .

وهناك مسائل كثيرة ( تخيّل كثير من الخوارزميات فقط ) ،

ولإزالة اللبس الذي قد يحصل .. أقول :

OpenCL ليست مكتبة رسومية .. فقد تشاهد مثلاً تطبيق رسومي خلاّب تم تسريعه باستخدام OpenCL .. مثل عملية Raytracingالمعروفة ببطئها الشديد في السنوات الماضية ( تنتظر ساعات لترى النتيجة ) ، لذلك عملية الرسم هي من مسؤولية OpenGL ونحوها .. ولكن عملية تسريع الرسوميات ( وتطبيق مفهوم البرمجة المتوازية مثلاً ) يمكن تنفيذه باستخدام OpenCL أو CUDA ..

روابط قد تفيدنا :

مقطع فيديو متميز لشرح مبدأ عمل OpenCL والهدف منها

http://developer.apple.com/library/mac/#documentation/Performance/Conceptual/OpenCL_MacProgGuide/Introduction/Introduction.html

http://cmsoft.com.br/index.php?option=com_content&view=category&layout=blog&id=99&Itemid=150

الخلاصة :

" لوحة مفاتيح " Microsoft رائعة جداً ، وكما ترى .. استطعت إنهاء المقالة والتحدث عن أشياء لها ثقلها دون أن أتوقف .. السر يكمن في لوحة مفاتيح Microsoft ، ولكن التحذير بشأن الصحة الذي يظهر خلف الكيبورد .. يجبرني على أن أتوقف هنا .

المقال : مكتوب بشكل سريع و دون مراجعة علمية ، وهو يفترض أن القارئ " يحب قراءة الجرائد " ، لذلك لا تعتمد عليه كثيراً في بعض النقاط العلمية الدقيقة .

18

logo1.png تطبيق طمأنينة ، نسخة بيتا على أندرويد

عبدالله الشمّري - Al-Shammari

CodingAlone.com

twitter @abshammeri

abshammeri AT gmail.com

github : abshammeri

#2

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

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

2

مصري في بلاد الفرنجة.

قريباً اقرأ مقالاتي على It-scoop

#3

@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 في 4 أكتوبر 2010 في 01:25

name : mohamedyosry

#4

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

موضوع جميل :)

لم أشارك في النقاش الذي دار في موضوع آخر في الحقيقة, و لكن يبدو أن النظرة للـ 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
#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

logo1.png تطبيق طمأنينة ، نسخة بيتا على أندرويد

عبدالله الشمّري - Al-Shammari

CodingAlone.com

twitter @abshammeri

abshammeri AT gmail.com

github : abshammeri

#6

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

2
forum-signature-01.gif
#7
اقتباس

أولاً, أكثر من 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
#8

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

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

مواضيع مشابهة