בניגוד לממשקי API קודמים של גרפיקה, ב-Vulkan הדרייברים לא מבצעים אופטימיזציות מסוימות, כמו שימוש חוזר בצינורות, עבור אפליקציות. במקום זאת, אפליקציות שמשתמשות ב-Vulkan צריכות להטמיע אופטימיזציות כאלה בעצמן. אם לא, יכול להיות שהביצועים שלהן יהיו גרועים יותר מאלה של אפליקציות שמריצות OpenGL ES.
כשאפליקציות מטמיעות את האופטימיזציות האלה בעצמן, יש להן פוטנציאל לעשות זאת בצורה מוצלחת יותר מאשר מנהל ההתקנים, כי יש להן גישה למידע ספציפי יותר לתרחיש שימוש נתון. כתוצאה מכך, אופטימיזציה מיומנת של אפליקציה שמשתמשת ב-Vulkan יכולה להניב ביצועים טובים יותר מאשר אם האפליקציה הייתה משתמשת ב-OpenGL ES.
בדף הזה מוצגים כמה שיפורים שאפשר להטמיע באפליקציית Android כדי לשפר את הביצועים באמצעות Vulkan.
שיפור מהירות באמצעות חומרה
רוב המכשירים
תומכים ב-Vulkan 1.1 באמצעות האצת חומרה, בעוד שקבוצת משנה קטנה תומכת בה באמצעות אמולציית תוכנה. אפליקציות יכולות לזהות מכשיר Vulkan מבוסס תוכנה באמצעות vkGetPhysicalDeviceProperties ולבדוק את השדה deviceType של המבנה שמוחזר.
ל-SwiftShader וליישומים אחרים שמבוססים על CPU יש את הערך VK_PHYSICAL_DEVICE_TYPE_CPU.
אפליקציות יכולות לבדוק באופן ספציפי אם מותקן SwiftShader על ידי בדיקת השדות vendorID ו-deviceID
באותו מבנה, כדי לראות אם יש בהם ערכים ספציפיים ל-SwiftShader.
באפליקציות שבהן הביצועים הם קריטיים, מומלץ להימנע משימוש בהטמעות של Vulkan שמדמות תוכנה, ולחזור לשימוש ב-OpenGL ES במקום זאת.
החלת סיבוב מסך במהלך הרינדור
אם הכיוון של האפליקציה כלפי מעלה לא תואם לכיוון של המסך במכשיר, מנהל הקומפוזיציה מסובב את התמונות בשרשרת החלפה של האפליקציה כך שיהיה תואם. הסיבוב מתבצע בזמן שהתמונות מוצגות, ולכן צריכת החשמל גבוהה יותר – לפעמים באופן משמעותי – מאשר אם התמונות לא היו מסתובבות.
לעומת זאת, סיבוב של תמונות ב-swapchain בזמן היצירה שלהן מוביל לצריכת חשמל נוספת קטנה, אם בכלל. השדה VkSurfaceCapabilitiesKHR::currentTransform מציין את הסיבוב שרכיב היצירה מבצע בחלון. אחרי שאפליקציה מבצעת את הרוטציה הזו במהלך הרינדור, היא משתמשת בשדה VkSwapchainCreateInfoKHR::preTransform כדי לדווח שהרוטציה הושלמה.
מזעור מספר שלבי העיבוד לכל פריים
ברוב ארכיטקטורות ה-GPU בנייד, התחלה וסיום של שלב עיבוד הם פעולות יקרות. כדי לשפר את הביצועים של האפליקציה, כדאי לארגן את פעולות הרינדור למעברי רינדור מעטים ככל האפשר.
לפעולות שונות של טעינת קבצים מצורפים ושל אחסון קבצים מצורפים יש רמות ביצועים שונות. לדוגמה, אם אתם לא צריכים לשמור את התוכן של קובץ מצורף, אתם יכולים להשתמש ב-VK_ATTACHMENT_LOAD_OP_CLEAR או ב-VK_ATTACHMENT_LOAD_OP_DONT_CARE במקום ב-VK_ATTACHMENT_LOAD_OP_LOAD. באופן דומה, אם אין צורך לכתוב את הערכים הסופיים של הקובץ המצורף לזיכרון לשימוש מאוחר יותר, אפשר להשתמש ב-VK_ATTACHMENT_STORE_OP_DONT_CARE כדי להשיג ביצועים טובים בהרבה מאשר ב-VK_ATTACHMENT_STORE_OP_STORE.
בנוסף, ברוב שלבי העיבוד, האפליקציה לא צריכה לטעון או לאחסן את קובץ המצורף של עומק/סטנסיל. במקרים כאלה, כדי להימנע מהקצאת זיכרון פיזי לתמונה המצורפת, אפשר להשתמש בדגל VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT כשיוצרים את התמונה המצורפת. החלק הזה מספק את אותם היתרונות כמו glFramebufferDiscard ב-OpenGL ES.
בחירת סוגי זיכרונות מתאימים
כשמקצים זיכרון למכשיר, האפליקציות צריכות לבחור סוג זיכרון. סוג הזיכרון קובע איך אפליקציה יכולה להשתמש בזיכרון, וגם מתאר את מאפייני השמירה במטמון והעקביות של הזיכרון. במכשירים שונים יש סוגים שונים של זיכרון, ולכל סוג זיכרון יש מאפייני ביצועים שונים.
אפליקציה יכולה להשתמש באלגוריתם פשוט כדי לבחור את סוג הזיכרון הכי טוב לשימוש מסוים. האלגוריתם הזה בוחר את סוג הזיכרון הראשון במערך VkPhysicalDeviceMemoryProperties::memoryTypes שעומד בשני קריטריונים:
סוג הזיכרון צריך להיות מותר עבור המאגר או התמונה, וצריכות להיות לו המאפיינים המינימליים שהאפליקציה דורשת.
בדרך כלל, למערכות לנייד אין ערימות נפרדות של זיכרון פיזי למעבד ול-GPU. במערכות כאלה, הערך של VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT לא משמעותי כמו במערכות עם כרטיסי GPU נפרדים עם זיכרון ייעודי משלהם. אפליקציה לא צריכה להניח שהמאפיין הזה נדרש.
קיבוץ של קבוצות תיאורים לפי תדירות
אם יש לכם קישורי משאבים שמשתנים בתדירויות שונות, כדאי להשתמש בכמה קבוצות של קובצי תיאור לכל צינור עיבוד נתונים, במקום לקשר מחדש את כל המשאבים לכל ציור. לדוגמה, יכול להיות לכם סט אחד של תיאורים לקישורים לכל סצנה, סט אחר לקישורים לכל חומר וסט שלישי לקישורים לכל מופע רשת.
משתמשים בקבועים מיידיים לשינויים בתדירות הגבוהה ביותר, כמו שינויים שמתבצעים בכל בקשה להזזת פריט גרפי (draw call).