چطوری با GPU صحبت کنیم؟ آموزش و یادگیری چطوری با GPU صحبت کنیم؟ به صورت رایگان
میتونیم ارتباط برناممون رو با کارت گرافیک، اینطوری تصور کنیم:
Application → Graphics API → Driver → GPU
هر کدوم از این لایهها وظیفهی خودشون رو دارن.
Application | برنامهی ما
اولین لایه، برنامه خودمونه.
ممکنه با ++C یک Renderer یا یک Game Engine نوشته باشیم.
ما داخل برنامهمون تصمیم میگیریم:
- چه چیزی Render بشه.
- چه دادهای به GPU فرستاده بشه.
- از چه Shader هایی استفاده کنیم.
- چه Textureهایی استفاده بشن.
- و چه عملیات Graphics ای انجام بشه.
اما برنامهی ما مستقیماً با سختافزار GPU صحبت نمیکنه.
برای این کار به یک رابط نیاز داریم.
Graphics API | رابط برنامهنویسی گرافیکی
اینجا Graphics API وارد میشه.
Graphics API مجموعهای از توابع، قوانین و مفاهیمیه که به برنامهی ما اجازه میده با قابلیتهای Graphics سیستم کار کنه.
مثلاً میتونیم از طریق API به GPU بگیم:
«این Buffer رو بساز.»
«این Texture رو استفاده کن.»
«این Shader رو اجرا کن.»
«این Geometry رو Render کن.»
اما خود Graphics API هم مستقیماً سختافزار GPU رو کنترل نمیکنه.
Graphics Driver | درایور گرافیکی
اینجا پای Graphics Driver وسط میاد.
درایور، نرمافزاریه که بین Graphics API و سختافزار GPU قرار میگیره.
وقتی برنامهی ما از طریق API درخواستی رو ارسال میکنه، Driver وظیفه داره این درخواست رو متناسب با GPU و سیستم آماده و مدیریت کنه.
چرا این لایه ها بوجود اومدن؟
چون کارت های گرافیک، معماری مختلف و قابلیتهای متفاوتی دارن.
اگر قرار بود برنامهنویس، برای هر GPU، مستقیماً با سختافزار صحبت کنه، نوشتن یک برنامهی گرافیکی قابلانتقال، تقریباً غیرممکن میشد.
Graphics API و Driver بخش بزرگی از این پیچیدگی رو از برنامهنویس پنهان میکنن.
در نتیجه ما میتونیم با یک رابط مشخص با سیستم Graphics کار کنیم، بدون اینکه لازم باشه جزئیات سختافزار هر GPU رو بشناسیم.
حالا یک سؤال دیگه به وجود میاد:
این Graphics API ها دقیقا چی هستن؟
احتمالاً اسمهایی مثل OpenGL، Vulkan، DirectX و Metal رو شنیدید.
همهی اینها API های گرافیکی هستن، اما رویکرد و سطح انتزاعشون با هم فرق داره.
توی تِرِد بعدی خیلی کوتاه با این API ها آشنا میشیم و بعدا، برای بخش عملی دوره، یعنی بخش ۳، با OpenGL کار میکنیم.
تِرد بعدی: API های گرافیکی