OpenGL ES: چیست، معماری و کاربرد

OpenGL ES چیست؟

OpenGL ES (Open Graphics Library for Embedded Systems) — زیرمجموعه‌ای از API دسکتاپ OpenGL است که برای دستگاه‌های موبایل، کنسول‌های بازی و سیستم‌های嵌入 شده تطبیق داده شده است. مشخصات توسط کنسرسیوم Khronos Group توسعه می‌یابد و برای همه تولیدکنندگان رایگان در دسترس است. برخلاف OpenGL دسکتاپ، OpenGL ES توابع منسوخ خط لوله ثابت را حذف می‌کند و فقط خط لوله قابل برنامه‌ریزی شیدر را باقی می‌گذارد — این کار مصرف انرژی را کاهش داده و درایورها را ساده‌تر می‌کند.

حوزه اصلی کاربرد OpenGL ES — رندرینگ گرافیک در زمان واقعی است. این API در بازی‌های موبایل (Unity، Unreal Engine)، برنامه‌های ناوبری، راه‌حل‌های AR مبتنی بر ARCore و ARKit، و همچنین در رابط‌های سیستمی Android و iOS استفاده می‌شود. بر اساس داده‌های StatCounter, 2026، سهم دستگاه‌هایی که از OpenGL ES 3.0+ پشتیبانی می‌کنند در بین گوشی‌های هوشمند فعال بیش از 92% است.

مزیت کلیدی OpenGL ES — چندسکویی بودن است. یک برنامه نوشته شده با OpenGL ES می‌تواند با حداقل تغییرات روی Android، iOS، Linux و Windows اجرا شود. این باعث می‌شود API انتخاب بهینه‌ای برای پروژه‌هایی باشد که روی پلتفرم‌های متعدد بدون بازنویسی موتور گرافیکی هدف‌گیری می‌کنند.

خط لوله ثابت در مقابل قابل برنامه‌ریزی

نسخه‌های اولیه OpenGL (قبل از 2.0) از خط لوله ثابت استفاده می‌کردند — مجموعه‌ای از مراحل از پیش تعریف‌شده پردازش رئوس و پیکسل‌ها. توسعه‌دهنده فقط می‌توانست پارامترها را تنظیم کند: موقعیت منابع نور، ویژگی‌های مواد، ماتریس‌های تبدیل. خط لوله قابل برنامه‌ریزی که در OpenGL ES 2.0 معرفی شد، مراحل ثابت را با شیدرها — برنامه‌های کوچکی که روی GPU اجرا می‌شوند — جایگزین کرد. این به توسعه‌دهندگان کنترل کامل بر نمایش هندسه داد.

انتقال به خط لوله قابل برنامه‌ریزی یک انقلاب برای گرافیک موبایل بود. توسعه‌دهندگان توانایی پیاده‌سازی جلوه‌های پیچیده را به دست آوردند: PBR (Physically Based Rendering)، سایه‌های پویا، پس‌پردازش و HDR. خط لوله ثابت به کد کمتری نیاز داشت اما اجازه ایجاد سبک‌های بصری منحصر‌به‌فرد را نمی‌داد. بازی‌های مدرن موبایل کاملاً روی خط لوله قابل برنامه‌ریزی کار می‌کنند.

معماری OpenGL ES: خط لوله رندرینگ

خط لوله گرافیکی OpenGL ES از چند مرحله متوالی تشکیل شده است که هر یک داده‌های ورودی را در مسیر از رئوس به پیکسل‌های روی صفحه تبدیل می‌کند. درک معماری خط لوله برای بهینه‌سازی عملکرد رندرینگ در دستگاه‌های موبایل با بودجه محدود انرژی و حرارت حیاتی است.

اولین مرحله — شیدر رأس — هر رأس را به طور مستقل پردازش می‌کند. در این مرحله تبدیل‌ها اعمال می‌شوند: از فضای محلی مدل به فضای جهان، سپس به فضای دوربین و در نهایت به فضای برش (clip space). تبدیل‌ها از طریق ماتریس‌های uniform MVP (Model-View-Projection) داده می‌شوند که در هر فریم با حرکت دوربین یا اشیاء به‌روز می‌شوند.

پس از مونتاژ primitives (نقاط، خطوط، مثلث‌ها)، rasterization انجام می‌شود — فرآیند تعیین اینکه هر primitive کدام پیکسل‌های صفحه را پوشش می‌دهد. Rasterizer fragmentها — پیکسل‌های بالقوه با ویژگی‌های درون‌یابی شده (رنگ، نرمال، مختصات UV) — تولید می‌کند. تعداد fragmentها مستقیماً به وضوح صفحه و مساحت پروجکشن primitive بستگی دارد.

شیدر fragment برای هر fragment تولید شده اجرا می‌شود. این شیدر رنگ نهایی پیکسل را با در نظر گرفتن بافت‌ها، منابع نور و مواد محاسبه می‌کند. در خروجی شیدر fragment، یک سری تست‌های per-fragment انجام می‌شود: depth test مشخص می‌کند که fragment قابل مشاهده است یا خیر؛ stencil test رندرینگ را بر اساس ماسک محدود می‌کند؛ blending رنگ fragment را با رنگی که قبلاً در بافر فریم نوشته شده است مخلوط می‌کند.

حالت‌های زمینه OpenGL ES

OpenGL ES به عنوان ماشین حالت (state machine) کار می‌کند: همه تنظیمات — شیدر فعلی، بافت‌های متصل، تست‌های فعال — در حالت سراسری زمینه ذخیره می‌شوند. تغییر حالت از طریق glEnable، glBindTexture یا glUseProgram بر تمام دستورات بعدی ترسیم تأثیر می‌گذارد. هر تغییر حالت باعث سربار در درایور می‌شود، بنابراین گروه‌بندی فراخوانی‌های draw بر اساس حالت — تکنیک اصلی بهینه‌سازی است.

نسخه‌های OpenGL ES و قابلیت‌های آنها

OpenGL ES 1.0 و 1.1 (منتشر شده در 2003–2004) بر اساس خط لوله ثابت بودند. آنها از تبدیل‌ها، بافت‌دهی، نورپردازی و blending پشتیبانی می‌کردند اما اجازه برنامه‌نویسی شیدر را نمی‌دادند. این API در تلفن‌های همراه اولیه و دستگاه‌های مبتنی بر Symbian و Windows Mobile استفاده می‌شد. امروزه این نسخه‌ها منسوخ محسوب می‌شوند — دستگاه‌های مدرن از آنها پشتیبانی نمی‌کنند.

OpenGL ES 2.0 (2007) خط لوله قابل برنامه‌ریزی را با شیدرهای رأس و fragment به زبان GLSL ES معرفی کرد. این نسخه به استانداردی برای Android 2.2+ و iOS 5+ تبدیل شد و تا به امروز توسط اکثریت قریب به اتفاق دستگاه‌ها پشتیبانی می‌شود. OpenGL ES 2.0 — حداقل نسخه مورد نیاز برای اجرای Unity، Unreal Engine و Cocos2d-x بر روی پلتفرم‌های موبایل است.

OpenGL ES 3.0 (2012) چند قابلیت حیاتی اضافه کرد: اهداف رندرینگ چندگانه (MRT)، transform feedback، instancing، بافت‌های با فرمت دلخواه از طریق ETC2/EAC. عملکرد رندرینگ در مقایسه با نسخه 2.0 به دلیل کاهش تعداد فراخوانی‌های draw 30–50% افزایش یافت. OpenGL ES 3.1 (2014) شیدرهای محاسباتی (compute shaders) و عملیات اتمی روی بافرها را معرفی کرد — این امکان را فراهم کرد که روی GPU نه تنها وظایف گرافیکی، بلکه محاسباتی (پس‌پردازش، شبیه‌سازی پارچه، محاسبات فیزیک) نیز انجام شود.

OpenGL ES 3.2 (2015) — آخرین نسخه مشخصات — شیدرهای tesselation و هندسه و همچنین مجموعه گسترده‌ای از بافت‌های float و حالت‌های blend را اضافه کرد. علی‌رغم انتشار Vulkan مدرن‌تر در سال 2016، OpenGL ES 3.2 به دلیل پایگاه عظیم کد موجود و سادگی انتقال برنامه‌ها بین پلتفرم‌ها یک API فعلی باقی مانده است.

شیدرها در OpenGL ES: GLSL و خط لوله قابل برنامه‌ریزی

GLSL ES (OpenGL Shading Language for Embedded Systems) — زبان برنامه‌نویسی شیدر بر اساس syntax C با انواع اضافی برای کار با بردارها و ماتریس‌ها. هر شیدر برنامه‌ای است که در مرحله مقداردهی اولیه برنامه به کد ماشین GPU کامپایل می‌شود. برخلاف کد CPU، شیدرها به صورت موازی انبوه اجرا می‌شوند: هزاران رأس یا fragment به طور همزمان پردازش می‌شوند.

شیدرهای رأس

شیدر رأس هر رأس مش را پردازش می‌کند. وظیفه اصلی آن محاسبه موقعیت نهایی رأس در clip space با ضرب موقعیت ورودی در ماتریس MVP است. علاوه بر این، شیدر رأس می‌تواند نرمال‌ها، مختصات UV، رنگ‌ها را محاسبه کرده و آنها را از طریق متغیرهای varying به شیدر fragment منتقل کند. هر فراخوانی شیدر رأس به طور مستقل کار می‌کند که به GPU اجازه می‌دهد میلیون‌ها رأس را در یک فریم پردازش کند.

// شیدر ساده رأس برای OpenGL ES 3.0
#version 300 es
layout(location = 0) in vec4 a_position;
layout(location = 1) in vec3 a_normal;
layout(location = 2) in vec2 a_texCoord;

uniform mat4 u_mvpMatrix;

out vec3 v_normal;
out vec2 v_texCoord;

void main() {
    gl_Position = u_mvpMatrix * a_position;
    v_normal = mat3(u_mvpMatrix) * a_normal;
    v_texCoord = a_texCoord;
}

شیدرهای fragment

شیدر fragment رنگ هر پیکسل روی صفحه را تعیین می‌کند. این شیدر مقادیر درون‌یابی شده varying را از شیدر رأس دریافت می‌کند، texelها را از بافت‌های متصل انتخاب کرده و نورپردازی را اعمال می‌کند. برای نورپردازی صحیح از مدل Phong یا Blinn-Phong با محاسبه مؤلفه‌های diffuse، specular و ambient استفاده می‌شود. هر فراخوانی شیدر fragment معادل یک پیکسل است، بنابراین تعداد کل فراخوانی‌ها برابر مساحت پروجکشن شیء روی صفحه است.

// شیدر ساده fragment با بافت و نورپردازی
#version 300 es
precision mediump float;

in vec3 v_normal;
in vec2 v_texCoord;

uniform sampler2D u_texture;
uniform vec3 u_lightDir;

out vec4 fragColor;

void main() {
    vec4 texel = texture(u_texture, v_texCoord);
    vec3 normal = normalize(v_normal);
    float diffuse = max(dot(normal, u_lightDir), 0.0);
    fragColor = vec4(texel.rgb * diffuse, texel.a);
}

در مثال بالا، شیدر fragment یک texel را از بافت 2D بر اساس مختصات UV انتخاب می‌کند، نورپردازی diffuse را به عنوان حاصل ضرب اسکالر نرمال و جهت نور محاسبه کرده و رنگ texel را در شدت نور ضرب می‌کند. Mediump — دقت توصیه‌شده برای شیدرهای fragment در GPUهای موبایل: کیفیت کافی را با حداقل مصرف انرژی فراهم می‌کند.

چگونه کار با OpenGL ES را در پروژه‌های موبایل شروع کنیم

برای کار با OpenGL ES در Android باید یک زمینه EGL ایجاد کرد — سطحی که گرافیک روی آن نمایش داده می‌شود. در iOS از لایه EGL-مانند EAGL استفاده می‌شود که توسط فریمورک GLKit ارائه می‌شود. در هر دو مورد، فرآیند مقداردهی اولیه شامل ایجاد سطح پنجره، پیکربندی ویژگی‌های زمینه و اتصال به رشته رندرینگ فعلی است.

// مقداردهی اولیه OpenGL ES 3.0 در Android
class MyGLRenderer : GLSurfaceView.Renderer {

    private val vertexShaderCode = "#version 300 es\n..."
    private val fragmentShaderCode = "#version 300 es\n..."

    override fun onSurfaceCreated(gl: GL10?, config: EGLConfig?) {
        GLES30.glClearColor(0.1f, 0.1f, 0.2f, 1.0f)
        GLES30.glEnable(GLES30.GL_DEPTH_TEST)
    }

    override fun onDrawFrame(gl: GL10?) {
        GLES30.glClear(GLES30.GL_COLOR_BUFFER_BIT or GLES30.GL_DEPTH_BUFFER_BIT)
        // bind VBO, set uniforms, draw elements
    }

    override fun onSurfaceChanged(gl: GL10?, width: Int, height: Int) {
        GLES30.glViewport(0, 0, width, height)
    }
}

پس از ایجاد زمینه، توسعه‌دهنده باید بافرها را پیکربندی کند: بافر رأس (VBO) شامل مختصات رئوس، نرمال‌ها و UV است؛ بافر ایندکس (EBO) ترتیب عبور از رئوس برای تشکیل مثلث‌ها را تعیین می‌کند. VAO (Vertex Array Object) پیکربندی همه ویژگی‌ها را در یک شیء ترکیب می‌کند و تعداد فراخوانی‌های API را هنگام تغییر مش‌ها کاهش می‌دهد.

پیکربندی زمینه EGL

EGL (Native Platform Graphics Interface) — لایه میانی بین OpenGL ES و سیستم پنجره است. در Android، EGL ایجاد سطح ترسیم، انتخاب پیکربندی framebuffer (عمق رنگ، stencil، MSAA) و همگام‌سازی با vsync را مدیریت می‌کند. پیکربندی معمول RGBA8888 با بافر depth 24 بیتی و بافر stencil 8 بیتی را درخواست می‌کند. در iOS نقش EGL توسط EAGL در ترکیب با CAEAGLLayer انجام می‌شود.

بهینه‌سازی عملکرد OpenGL ES در دستگاه‌های موبایل شامل چند روش کلیدی است. برای رندرینگ اشیاء مشابه متعدد از instancing (glDrawArraysInstanced) استفاده کنید — این تعداد فراخوانی‌های draw را کاهش می‌دهد. از pool بافت استفاده کنید و از تغییر بافت بین فراخوانی‌های draw خودداری کنید. اشیاء را ابتدا بر اساس شیدر، سپس بافت و سپس مش مرتب کنید — این ترتیب تغییرات حالت زمینه را به حداقل می‌رساند.

OpenGL ES در مقابل Metal در مقابل Vulkan

Metal — API گرافیکی سطح پایین از Apple، قابل دسترس در iOS و macOS از تراشه A7. Metal دسترسی مستقیم به GPU را با حداقل سربار درایور فراهم می‌کند اما فقط روی دستگاه‌های Apple کار می‌کند. بر اساس داده‌های WWDC 2024، Metal تا 40% عملکرد بالاتر نسبت به OpenGL ES روی همان سخت‌افزار با کاهش تعداد بررسی‌های حالت در زمان اجرا ارائه می‌دهد.

Vulkan — جانشین چندسکویی OpenGL ES است که توسط Khronos Group توسعه یافته است. Vulkan از مدیریت صریح منابع استفاده می‌کند: توسعه‌دهنده خود poolهای حافظه را تخصیص می‌دهد، بافرهای فرمان ایجاد می‌کند و دسترسی به GPU را همگام‌سازی می‌کند. این حداکثر کنترل بر عملکرد را فراهم می‌کند اما کد مقداردهی اولیه Vulkan 3–4 برابر حجیم‌تر از OpenGL ES است. Vulkan برای بازی‌های AAA و برنامه‌های با گرافیک سنگین روی Android 7+ توصیه می‌شود.

انتخاب بین OpenGL ES، Metal و Vulkan به پلتفرم‌های هدف و الزامات عملکرد بستگی دارد. OpenGL ES بهترین انتخاب برای پروژه‌های چندسکویی باقی می‌ماند که سرعت توسعه مهم است. Metal برای اکوسیستم iOS/macOS با حداکثر عملکرد ترجیح داده می‌شود. Vulkan — انتخاب برای پروژه‌هایی است که هر میلی‌ثانیه فریم حیاتی است و بودجه توسعه اجازه سرمایه‌گذاری در بهینه‌سازی سطح پایین را می‌دهد.