دستورالعمل های طراحی ولکان، دستورالعمل های طراحی ولکان

Vulkan بر خلاف APIهای گرافیکی قبلی است که درایورها بهینه سازی خاصی مانند استفاده مجدد از خط لوله را برای برنامه ها انجام نمی دهند. در عوض، برنامه‌هایی که از Vulkan استفاده می‌کنند باید خودشان چنین بهینه‌سازی‌هایی را پیاده‌سازی کنند. اگر این کار را نکنند، ممکن است عملکرد بدتری نسبت به برنامه‌هایی که OpenGL ES دارند از خود نشان دهند.

وقتی برنامه‌ها خودشان این بهینه‌سازی‌ها را پیاده‌سازی می‌کنند، این پتانسیل را دارند که این کار را با موفقیت بیشتر از راننده انجام دهند، زیرا به اطلاعات خاص‌تری برای یک مورد استفاده خاص دسترسی دارند. در نتیجه، بهینه‌سازی ماهرانه برنامه‌ای که از Vulkan استفاده می‌کند، می‌تواند عملکرد بهتری نسبت به زمانی که برنامه از OpenGL ES استفاده می‌کرد، داشته باشد.

این صفحه چندین بهینه سازی را معرفی می کند که برنامه اندروید شما می تواند برای افزایش عملکرد Vulkan پیاده سازی کند.

شتاب سخت افزاری

اکثر دستگاه‌ها از Vulkan 1.1 از طریق شتاب سخت‌افزاری پشتیبانی می‌کنند در حالی که زیرمجموعه کوچکی از طریق شبیه‌سازی نرم‌افزاری آن را پشتیبانی می‌کنند. برنامه ها می توانند یک دستگاه Vulkan مبتنی بر نرم افزار را با استفاده از vkGetPhysicalDeviceProperties و بررسی فیلد deviceType ساختار برگشتی شناسایی کنند. SwiftShader و سایر پیاده سازی های مبتنی بر CPU دارای مقدار VK_PHYSICAL_DEVICE_TYPE_CPU هستند. برنامه‌ها می‌توانند به‌طور خاص SwiftShader را با بررسی فیلدهای vendorID و deviceID همین ساختار برای مقادیر خاص SwiftShader بررسی کنند.

برنامه‌های مهم عملکرد باید از پیاده‌سازی‌های Vulkan شبیه‌سازی‌شده با نرم‌افزار اجتناب کنند و در عوض به OpenGL ES برگردند.

چرخش نمایشگر را در حین رندر اعمال کنید

هنگامی که جهت رو به بالا یک برنامه با جهت نمایش دستگاه مطابقت ندارد، سازنده تصاویر swapchain برنامه را می چرخاند تا مطابقت داشته باشد. این چرخش را در حین نمایش تصاویر انجام می دهد، که منجر به مصرف انرژی بیشتر - گاه به طور قابل توجهی بیشتر - نسبت به عدم چرخش آنها می شود.

در مقابل، چرخش تصاویر swapchain در حین تولید آنها منجر به مصرف انرژی کمی و در صورت وجود ندارد. فیلد VkSurfaceCapabilitiesKHR::currentTransform چرخشی را که کامپوزیتور روی پنجره اعمال می کند نشان می دهد. پس از اینکه یک برنامه این چرخش را در حین رندر اعمال کرد، برنامه از فیلد VkSwapchainCreateInfoKHR::preTransform استفاده می کند تا گزارش دهد که چرخش کامل شده است.

گذرهای رندر در هر فریم را به حداقل برسانید

در اکثر معماری‌های GPU موبایل، شروع و پایان دادن به رندر پاس یک عملیات گران قیمت است. برنامه شما می‌تواند با سازماندهی عملیات رندر به کمترین میزان ممکن، عملکرد را بهبود بخشد.

آپشن های مختلف بارگیری پیوست و فروشگاه پیوست سطوح مختلف عملکرد را ارائه می دهند. برای مثال، اگر نیازی به حفظ محتوای یک پیوست ندارید، می‌توانید به جای VK_ATTACHMENT_LOAD_OP_LOAD از VK_ATTACHMENT_LOAD_OP_CLEAR یا VK_ATTACHMENT_LOAD_OP_DONT_CARE بسیار سریع‌تر استفاده کنید. به طور مشابه، اگر برای استفاده بعدی نیازی به نوشتن مقادیر نهایی پیوست در حافظه ندارید، می‌توانید از VK_ATTACHMENT_STORE_OP_DONT_CARE برای دستیابی به عملکرد بسیار بهتر از VK_ATTACHMENT_STORE_OP_STORE استفاده کنید.

همچنین، در اکثر پاس های رندر، برنامه شما نیازی به بارگیری یا ذخیره پیوست عمق/استنسیل ندارد. در چنین مواردی، می‌توانید با استفاده از پرچم VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT هنگام ایجاد تصویر پیوست، از تخصیص حافظه فیزیکی برای پیوست اجتناب کنید. این بیت همان مزایایی را ارائه می دهد که glFramebufferDiscard در OpenGL ES دارد.

انواع حافظه مناسب را انتخاب کنید

هنگام تخصیص حافظه دستگاه، برنامه ها باید نوع حافظه را انتخاب کنند. نوع حافظه تعیین می کند که یک برنامه چگونه می تواند از حافظه استفاده کند و همچنین ویژگی های کش و انسجام حافظه را توصیف می کند. دستگاه های مختلف دارای انواع حافظه های مختلف هستند. انواع مختلف حافظه ویژگی های عملکرد متفاوتی را نشان می دهند.

یک برنامه می تواند از یک الگوریتم ساده برای انتخاب بهترین نوع حافظه برای یک کاربرد خاص استفاده کند. این الگوریتم اولین نوع حافظه را در آرایه VkPhysicalDeviceMemoryProperties::memoryTypes انتخاب می‌کند که دو معیار را برآورده می‌کند: نوع حافظه باید برای بافر یا تصویر مجاز باشد و باید حداقل ویژگی‌های مورد نیاز برنامه را داشته باشد.

سیستم‌های موبایل معمولاً حافظه فیزیکی جداگانه برای CPU و GPU ندارند. در چنین سیستم‌هایی، VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT به اندازه سیستم‌هایی که پردازنده‌های گرافیکی مجزا با حافظه اختصاصی خود دارند، مهم نیست. یک برنامه نباید این ویژگی را مورد نیاز فرض کند.

مجموعه های توصیفگر گروه بر اساس فرکانس

اگر پیوندهای منابعی دارید که در فرکانس‌های مختلف تغییر می‌کنند، به جای اینکه همه منابع را برای هر قرعه‌کشی مجدداً پیوند دهید، از چندین مجموعه توصیفگر در هر خط لوله استفاده کنید. به عنوان مثال، شما می توانید یک مجموعه از توصیفگرها برای اتصالات در هر صحنه، مجموعه دیگری برای اتصالات هر ماده و مجموعه سومی برای اتصالات در هر مش داشته باشید.

از ثابت های فوری برای تغییرات با بالاترین فرکانس، مانند تغییراتی که با هر فراخوانی انجام می شود، استفاده کنید.

،

Vulkan بر خلاف APIهای گرافیکی قبلی است که درایورها بهینه سازی خاصی مانند استفاده مجدد از خط لوله را برای برنامه ها انجام نمی دهند. در عوض، برنامه‌هایی که از Vulkan استفاده می‌کنند باید خودشان چنین بهینه‌سازی‌هایی را پیاده‌سازی کنند. اگر این کار را نکنند، ممکن است عملکرد بدتری نسبت به برنامه‌هایی که OpenGL ES دارند از خود نشان دهند.

وقتی برنامه‌ها خودشان این بهینه‌سازی‌ها را پیاده‌سازی می‌کنند، این پتانسیل را دارند که این کار را با موفقیت بیشتر از راننده انجام دهند، زیرا به اطلاعات خاص‌تری برای یک مورد استفاده خاص دسترسی دارند. در نتیجه، بهینه‌سازی ماهرانه برنامه‌ای که از Vulkan استفاده می‌کند، می‌تواند عملکرد بهتری نسبت به زمانی که برنامه از OpenGL ES استفاده می‌کرد، داشته باشد.

این صفحه چندین بهینه سازی را معرفی می کند که برنامه اندروید شما می تواند برای افزایش عملکرد Vulkan پیاده سازی کند.

شتاب سخت افزاری

اکثر دستگاه‌ها از Vulkan 1.1 از طریق شتاب سخت‌افزاری پشتیبانی می‌کنند در حالی که زیرمجموعه کوچکی از طریق شبیه‌سازی نرم‌افزاری آن را پشتیبانی می‌کنند. برنامه ها می توانند یک دستگاه Vulkan مبتنی بر نرم افزار را با استفاده از vkGetPhysicalDeviceProperties و بررسی فیلد deviceType ساختار برگشتی شناسایی کنند. SwiftShader و سایر پیاده سازی های مبتنی بر CPU دارای مقدار VK_PHYSICAL_DEVICE_TYPE_CPU هستند. برنامه‌ها می‌توانند به‌طور خاص SwiftShader را با بررسی فیلدهای vendorID و deviceID همین ساختار برای مقادیر خاص SwiftShader بررسی کنند.

برنامه‌های مهم عملکرد باید از پیاده‌سازی‌های Vulkan شبیه‌سازی‌شده با نرم‌افزار اجتناب کنند و در عوض به OpenGL ES برگردند.

چرخش نمایشگر را در حین رندر اعمال کنید

هنگامی که جهت رو به بالا یک برنامه با جهت نمایش دستگاه مطابقت ندارد، سازنده تصاویر swapchain برنامه را می چرخاند تا مطابقت داشته باشد. این چرخش را در حین نمایش تصاویر انجام می دهد، که منجر به مصرف انرژی بیشتر - گاه به طور قابل توجهی بیشتر - نسبت به عدم چرخش آنها می شود.

در مقابل، چرخش تصاویر swapchain در حین تولید آنها منجر به مصرف انرژی کمی و در صورت وجود ندارد. فیلد VkSurfaceCapabilitiesKHR::currentTransform چرخشی را که کامپوزیتور روی پنجره اعمال می کند نشان می دهد. پس از اینکه یک برنامه این چرخش را در حین رندر اعمال کرد، برنامه از فیلد VkSwapchainCreateInfoKHR::preTransform استفاده می کند تا گزارش دهد که چرخش کامل شده است.

گذرهای رندر در هر فریم را به حداقل برسانید

در اکثر معماری‌های GPU موبایل، شروع و پایان دادن به رندر پاس یک عملیات گران قیمت است. برنامه شما می‌تواند با سازماندهی عملیات رندر به کمترین میزان ممکن، عملکرد را بهبود بخشد.

آپشن های مختلف بارگیری پیوست و فروشگاه پیوست سطوح مختلف عملکرد را ارائه می دهند. برای مثال، اگر نیازی به حفظ محتوای یک پیوست ندارید، می‌توانید به جای VK_ATTACHMENT_LOAD_OP_LOAD از VK_ATTACHMENT_LOAD_OP_CLEAR یا VK_ATTACHMENT_LOAD_OP_DONT_CARE بسیار سریع‌تر استفاده کنید. به طور مشابه، اگر برای استفاده بعدی نیازی به نوشتن مقادیر نهایی پیوست در حافظه ندارید، می‌توانید از VK_ATTACHMENT_STORE_OP_DONT_CARE برای دستیابی به عملکرد بسیار بهتر از VK_ATTACHMENT_STORE_OP_STORE استفاده کنید.

همچنین، در اکثر پاس های رندر، برنامه شما نیازی به بارگیری یا ذخیره پیوست عمق/استنسیل ندارد. در چنین مواردی، می‌توانید با استفاده از پرچم VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT هنگام ایجاد تصویر پیوست، از تخصیص حافظه فیزیکی برای پیوست اجتناب کنید. این بیت همان مزایایی را ارائه می دهد که glFramebufferDiscard در OpenGL ES دارد.

انواع حافظه مناسب را انتخاب کنید

هنگام تخصیص حافظه دستگاه، برنامه ها باید نوع حافظه را انتخاب کنند. نوع حافظه تعیین می کند که یک برنامه چگونه می تواند از حافظه استفاده کند و همچنین ویژگی های کش و انسجام حافظه را توصیف می کند. دستگاه های مختلف دارای انواع حافظه های مختلف هستند. انواع مختلف حافظه ویژگی های عملکرد متفاوتی را نشان می دهند.

یک برنامه می تواند از یک الگوریتم ساده برای انتخاب بهترین نوع حافظه برای یک کاربرد خاص استفاده کند. این الگوریتم اولین نوع حافظه را در آرایه VkPhysicalDeviceMemoryProperties::memoryTypes انتخاب می‌کند که دو معیار را برآورده می‌کند: نوع حافظه باید برای بافر یا تصویر مجاز باشد و باید حداقل ویژگی‌های مورد نیاز برنامه را داشته باشد.

سیستم‌های موبایل معمولاً حافظه فیزیکی جداگانه برای CPU و GPU ندارند. در چنین سیستم‌هایی، VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT به اندازه سیستم‌هایی که پردازنده‌های گرافیکی مجزا با حافظه اختصاصی خود دارند، مهم نیست. یک برنامه نباید این ویژگی را مورد نیاز فرض کند.

مجموعه های توصیفگر گروه بر اساس فرکانس

اگر پیوندهای منابعی دارید که در فرکانس‌های مختلف تغییر می‌کنند، به جای اینکه همه منابع را برای هر قرعه‌کشی مجدداً پیوند دهید، از چندین مجموعه توصیفگر در هر خط لوله استفاده کنید. به عنوان مثال، شما می توانید یک مجموعه از توصیفگرها برای اتصالات در هر صحنه، مجموعه دیگری برای اتصالات هر ماده و مجموعه سومی برای اتصالات در هر مش داشته باشید.

از ثابت های فوری برای تغییرات با بالاترین فرکانس، مانند تغییراتی که با هر فراخوانی انجام می شود، استفاده کنید.