Profiling Unity UI: Siapa yang merusak Batching Saya?

Anda telah menghabiskan banyak waktu untuk mengoptimalkan UI Persatuan. Tetapi untuk menyebabkan penghambatan, modifikasi kecil dari atribut kecil elemen Canvas UI hampir tidak terlihat sudah cukup. Dan ketika itu terjadi, bahkan membuat profil Unity UI tidak akan menyelamatkan Anda dari penurunan FPS. Apakah Anda siap untuk perbaikan bug yang lama?

Inilah yang terjadi dalam proyek terakhir saya ...

Saya bekerja keras untuk mengoptimalkan beberapa panel UI di port game kami di Oculus Quest . Pada dasarnya, tugasnya adalah mengurangi level overdraw ke nilai yang dapat diterima sehingga GPU dapat mengatasi hal yang paling penting - rendering 3D nyata.

Jadi saya berupaya mengoptimalkan UI Persatuan setidaknya selama sebulan, dan akhirnya membuat kemajuan yang sangat bagus.

Pada titik tertentu, UI menjadi sangat optimal sehingga hampir tidak mempengaruhi timing GPU. Teknik peredupan UI buram yang saya terapkan mengkompensasi sebagian besar redraws yang disebabkan oleh pelapisan UI (elemen digambar di atas elemen lainnya).

Jadi, saya mendapatkan sistem UI hybrid yang sangat dioptimalkan, yang pada dasarnya tumpang tindih elemen 3D yang digambar di bawahnya. Menjadi sangat mudah untuk membuang rendering fragmen yang tumpang tindih ini.

Namun, pekerjaan itu masih jauh dari selesai ...

Ketika saya terhubung dengan Unity UI Profiler , satu hal menarik perhatian saya.

Saya melihat bahwa CPU yang kelebihan beban menghabiskan lebih dari 1 ms di setiap frame untuk merender UI. Ini adalah banyak waktu untuk platform yang memberi Anda anggaran 13 ms untuk seluruh permainan: fisika, logika, rendering 3D, input, VR dan kode jaringan.

Dan setelah semua ada kasus ketika UI "membunuh" kinerja CPU bahkan lebih.


Unity UI: pembuatan batch yang mahal

Dan ini mengatakan satu hal: UI dapat dioptimalkan untuk GPU, tetapi ini tidak berarti optimasi untuk CPU .

Bahkan, ketika merender Unity UI, tugas CPU dan GPU sangat berbeda. Tidak mengherankan, saya merekomendasikan untuk mendekati pengoptimalan CPU dan GPU secara berbeda, dan ini telah dibahas dalam posting saya sebelumnya tentang pengoptimalan UI Unity .

Profiling lebih lanjut dari Unity UI mengungkapkan masalah yang jelas: UI terus-menerus diciptakan kembali di setiap bingkai baru, yaitu Kanvas (Canvas Rebuild) dibangun kembali di setiap bingkai .

Beban konstan pada CPU selama 1 ms ... oh-oh.

Tapi mengapa Unity melakukan ini padaku? Saya pikir Unity cache semua antarmuka Canvas ...

Sebenarnya ya, benar. Unity secara efektif melakukan cache kanvas sehingga mereka dikumpulkan hanya sekali.

Namun, masalah muncul ketika Anda mengubah properti dari salah satu elemen UI di kanvas - warna, posisi, dan sebagainya.

Artinya, semua animasi yang kita sukai, misalnya, efek tombol ketika Anda mengarahkan kursor, membunuh produktivitas, dan Anda mungkin tidak tahu itu.

Ketika perubahan properti UI terjadi, Unity menjalankan Canvas Rebuild yang terkenal, yang merusak kinerja game .

Canvas Rebuild dari antarmuka memaksa engine Unity untuk secara iteratif melintasi semua elemen UI dari Canvas ini untuk menghasilkan daftar panggilan undian yang dioptimalkan (beberapa simpul, warna, bahan, dll.) Dan Canvas Rebuild membutuhkan waktu lebih lama daripada Seat Panda untuk mempercepat dari nol hingga 60 mph .

Menyadari bahwa kita terus-menerus menderita Canvas Rebuild, masuk akal untuk mengajukan pertanyaan ...

Mengapa kita menderita Canvas Rebuilds dan apa yang bisa dilakukan?

Untuk menjawab pertanyaan sederhana ini, saya harus menghabiskan lebih dari 5 jam mempelajari topik dan bekerja dengan Unity UI Profiler .

Mari kita perbaiki.

1. Profiling Unity UI: semuanya baik-baik saja, untuk saat ini ...

Bayangkan kita memiliki UI sederhana.

UI ini tidak melakukan apa-apa, hanya muncul di layar dan mengganggu pemain yang mencoba melihat sesuatu melaluinya.

Sebagai kumpulan 350+ gambar di Grup Tata Letak Kotak, tampilannya seperti ini:


Contoh Profil Unity UI

Dan semuanya beres, bahkan meskipun gambar 350-aneh. Dalam kasus standar, UI akan membuat hanya dalam dua panggilan draw, karena hanya ada dua gambar unik di dalamnya yang tidak ada dalam atlas sprite.

Bahkan, di profiler, saya bisa melihat bahwa praktis tidak ada beban pada bagian CPU. Sebagian besar waktu yang dihabiskan di UI kurang dari 0,01 ms , yang sangat bagus.


Profil Unity UI: Gelombang Misterius

(... sebagian besar waktu)

Tunggu, dari mana lonjakan sumber daya CPU ini berasal di akhir grafik?

2. Profiling Unity UI: Canvas Tiba-Tiba Dibangun Kembali!

Apa yang terjadi di akhir Profil Persatuan? Sangat aneh, hanya dalam sedetik, overhead CPU pada Unity UI lebih dari dua kali lipat.

Saya ingin bermain game

Temukan dua perbedaan dalam contoh di bawah ini (Anda mungkin harus membuka gambar di jendela terpisah untuk melihat yang lebih baik) .


Unity UI Profiling: Kanvas Berbiaya Rendah


Unity UI Profileing: Canvas Rebuild

Saya memberi Anda lima detik untuk mencari tahu.

5, 4 ... well, berikut ini tip untuk menyederhanakan tugas:


Unity UI Profileing: Overhead Canvas Rebuild

Wow!

PostLateUpdate.UpdateRectTransform dan UGUI.Rendering.UpdateBatches sangat ingin menjadi bintang utama acara ini.

Apa yang dilakukan area ini?

Yang pertama, UpdateRectTransform , memperjelas bahwa transformasi beberapa objek telah berubah, dan karena itu Unity harus melakukan logika mahal untuk mencerminkan perubahan visual. Kita tidak tahu apakah itu suatu posisi, rotasi, skala, atau sifat-sifat lain dari RectTransform .

Sial, kami bahkan tidak tahu apakah itu hanya satu atribut, atau sekaligus. Apakah itu objek tunggal atau beberapa? Dan yang mana? Ini masalahnya: kita tidak tahu .

Bagian mahal kedua, UpdateBatches , terkait dengan kebutuhan untuk membangun kembali seluruh geometri Kanvas. Proses ini disebut Canvas Rebuild . Rebuilding Canvas berarti Unity mengelilingi seluruh hierarki Canvas untuk menghasilkan daftar panggilan undian. Verteks, indeks, warna, dan uv dari semua elemen dihitung, dan kemudian batch pass dilakukan untuk menggabungkan jumlah panggilan draw maksimum yang mungkin untuk mengurangi beban berlebih pada CPU, yang memindahkannya ke driver grafis.

Sekarang kita sepertinya tahu apa yang sedang terjadi dan berada di jalur yang benar. Tetapi bagaimana cara menghindari perbaikan kanvas ini? Apa yang menyebabkan mereka?

Kami membutuhkan informasi yang lebih spesifik ...

Untuk meringkas

• Mengubah atribut dalam elemen UI menandai elemen itu sendiri sebagai kotor
• Elemen UI dapat benar-benar kotor, tetapi dapat juga sebagian: puncak kotor, tata letak kotor, bahan kotor. Lebih mudah untuk pulih dari kondisi kotor sebagian
• Setelah elemen Canvas ditandai sebagai kotor, Unity membangunnya kembali sepenuhnya
• Rekondisi ulang kanvas mahal untuk CPU, jadi hal terpenting yang harus dihindari adalah

3. Mencari hama: cara kasar yang secara politis salah

Kita masih perlu menjawab pertanyaan berikut:

Apa yang menyebabkan Canvas Rebuild ini?

Ternyata tidak ada cara cepat untuk mengetahuinya, terutama dengan hierarki Kanvas besar.

Tapi pertama-tama, saya akan menunjukkan kepada Anda metode brute force untuk menemukan alasan Canvas Rebuild .


1. Biarkan Unity UI Profiler Terus Merekam

Kami akan memfilter metrik agar kami dapat fokus pada yang paling penting: rendering, skrip, dan UI.

Lacak tanda awal untuk memahami biaya skema saat ini, yang harus mencakup Canvas Rebuild yang mahal.


2. Nonaktifkan Objek Game dari UI dan bandingkan bacaan

Pilih grup objek game dan nonaktifkan mereka.

Bandingkan metrik kinerja.

Jika bacaan tidak banyak membaik, maka lanjutkan untuk menonaktifkan objek game sampai Anda melihat peningkatan yang signifikan.


3. Temukan apa yang mengubah propertinya

Kami dapat memilih objek yang memanggil Canvas Rebuild. Tapi apa sebenarnya yang menjadi alasan mereka?

Mungkin skalanya berubah melalui skrip? Atau posisinya berubah oleh animasi?

Akan lebih mudah untuk mengklik kanan pada RectTransform dan pilih " Find Reference in Scene "

Ketika Anda mengetahui apa yang menyebabkan Canvas membangun kembali, lakukan sesuatu untuk itu, misalnya, matikan animasi atau transformasi.

Ruben, tetapi bagaimana saya menggunakan metode ini dengan hirarki besar UI? Jangan bilang omong kosong

Saya mengatakan bahwa prosesnya tidak akan cepat atau menarik, tetapi para pemain akan berterima kasih kepada Anda.

Itu intinya. Pertama, keberadaan hierarki besar bukanlah situasi yang ideal. Ini adalah hierarki besar dan mendalam yang membuat Canvas Rebuild begitu mahal untuk CPU.

Tetapi hierarki UI yang besar dan bersarang dapat (dan akan) muncul, jadi harapkan Canvas Rebuild untuk mencapai hal yang paling penting: gameplay.

Meskipun metode brute force membantu menemukan sumber perbaikan kanvas, metode ini tidak dapat diukur dalam jangka panjang.

Setelah menjadi lebih profesional dalam mengoptimalkan UI, saya menciptakan alat yang memberikan semua jawaban yang saya butuhkan sehingga proyek memenuhi harapan para pemain ...


Membuat Profil Kanvas Rebuild

4. Bonus: Meningkatkan Fitur Pengoptimalan UI Unity Profiler

Saya harap Anda sudah memahami seberapa sering dan mengganggu Canvas Rebuild dapat terjadi.

Perestroika ini, yang menginfeksi game saya, mengambil sebanyak 10% dari seluruh anggaran CPU!

Seperti yang telah kita lihat, ada metode brute force untuk menemukan sumber Canvas Rebuild. Mungkin Anda bisa mengatasinya menggunakan strategi yang tercantum dalam posting saya tentang mengoptimalkan Unity UI .

Tetapi proses rawan kesalahan seperti itu tidak akan pernah memuaskan seorang guru sejati. Anda dapat menghabiskan beberapa hari berjuang dengan Canvas Rebuild, tetapi pada saat yang paling tak terduga mereka akan kembali menghilang begitu Anda pasang di Unity UI Profiler.

Jika Anda mengembangkan game untuk VR, ini menjadi kritis. Kami tidak ingin Kanvas dibangun kembali di UI ruang dunia. Jika Anda tidak dapat menyingkirkan perestroika, maka pemain Anda kemungkinan besar tidak akan tahan.

Baiklah, saya mendapatkan ide untuk menyingkirkan Canvas Rebuilds. Tetapi Unity Profiler hampir tidak memberikan informasi tentang mereka! Apa yang bisa Anda beri tahu?

Senang Anda bertanya. Ternyata kami dapat meyakinkan Unity Profiler untuk memberi kami informasi berguna tentang apa yang menghambat kinerja UI .

Kami dapat memperluas fungsionalitas Unity UI Profiler . Untuk melakukan ini, Anda perlu memodifikasi kode sumber UI Unity yang tersedia untuk umum. Setelah Anda mendapatkan kode sumber, Anda harus mencari fungsi kode tempat Canvas Rebuild muncul . Maka kita perlu sihir API dengan profiler BeginSample dan EndSample .

Jika Anda menjalankan Unity 2019.1 atau lebih lama, kode sumber Unity UI telah diunggah ke repositori Bitbucket . Ada juga panduan untuk mengunduh, menginstal, dan memodifikasi.

Apa yang saya sarankan? Gunakan versi Unity yang lebih baru, tidak lebih rendah dari 2019.2.0. Versi Unity yang lebih baru datang secara default dengan UI sumber , karena sistem UI sekarang menjadi bagian dari manajer paket. Ini adalah cara yang paling mudah.

Berikut adalah daftar potongan kode yang saya temukan selama penelitian di mana saya dapat menambahkan panggilan API Profiling:

• CanvasUpdateRegistry.cs : PerformUpdate Function
  
• Graphic.cs : Fungsi SetAllDirty
  
• Graphic.cs : fungsi lain seperti SetVerticesDirty , SetMaterialDirty , dll ...

Unity UI: Sumber Profiling

Apakah ini membantu? Ya

Nyaman untuk artis / desainer? Tidak.

Penyair yang menulis Unity Extension open source kecil yang memperluas kemampuan Unity Profiler .


Alat gratis ini akan memungkinkan kita untuk dengan cepat beralih di antara mode profil yang berbeda untuk memastikan kinerja game maksimum.

Apa hal terbaik tentang expander Unity Profiler ini? Ini bekerja di luar editor, pada dasarnya membebaskan Anda dari semua sakit kepala saat membuat profil UI untuk Android dan platform lainnya.

Ini dia, semua kekuatannya dikendalikan hanya dengan dua tombol:

• Penggosok Unity Profiler saya
  
• Nerf Unity Profiler saya .

Anda bisa mendapatkan alat ini di sini .