Month: September 2025

Membuka Efisiensi Baru dengan Gemini di Android Studio

Tim terima kasih memutuskan untuk mencoba Gemini di Android Studio, seorang asisten AI yang mendukung pengembang di semua tahap pengembangan, membantu mereka menjadi lebih produktif. Pengembang dapat mengajukan pertanyaan Gemini dan menerima solusi sadar-konteks berdasarkan kode mereka. Divij Gupta, pengembang senior Android dengan rasa terima kasih, berbagi bahwa tim terima kasih perlu mengetahui apakah mungkin untuk menyuntikkan objek apa pun ke dalam kelas objek Kotlin menggunakan Hilt. Gemini menyarankan menggunakan titik masuk untuk mengakses dependensi di kelas di mana injeksi standar tidak mungkin, yang membantu menyelesaikan “masalah rumit mereka,” menurut Divij.

Gemini menghilangkan kebutuhan untuk mencari dokumentasi Android juga, memungkinkan tim terima kasih untuk belajar dan menerapkan pengetahuan mereka tanpa harus meninggalkan Android Studio. “Gemini menunjukkan kepada saya cara menggunakan CPU Android Studio dan profiler memori secara lebih efektif,” kenang Divij. “Saya juga belajar cara mengatur profil awal untuk mempercepat awal yang dingin.”

Bereksperimen dengan fitur baru menggunakan Gemini di Android Studio

Gemini di Android Studio membantu tim terima kasih secara signifikan meningkatkan kecepatan dan moral pengembangan mereka. “Siklus yang lebih cepat ini telah membuat tim merasa lebih produktif, termotivasi, dan bersemangat untuk terus berinovasi,” kata Divij. Pengembang dapat menghabiskan lebih banyak waktu untuk mengidentifikasi dan bereksperimen pada fitur -fitur baru, yang mengarah pada pengalaman baru yang inovatif.

Salah satu fitur yang dibangun pengembang dengan waktu ditemukan baru adalah fungsi pembuatan gambar untuk fitur papan visi aplikasi. Pengguna sekarang dapat mengunggah foto dengan prompt, dan kemudian menerima gambar yang dihasilkan AI yang mereka dapat langsung menjepit papan mereka. Tim dapat membangun UI menggunakan Gemini di Android Studio Menyusun pembuatan pratinjau -memungkinkan mereka untuk dengan cepat memvisualisasikan kode jetpack mereka dan membuat piksel-perfect ui yang dimaksudkan oleh desainer mereka.

Ke depan, tim terima kasih berharap untuk menggunakan Gemini untuk menerapkan lebih banyak peningkatan pada kodenya, termasuk mengoreksi gangguan, kebocoran memori, dan meningkatkan kinerja berdasarkan lebih banyak wawasan dari Gemini, yang selanjutnya akan meningkatkan pengalaman pengguna.

Bangun dengan Gemini di Android Studio

Posted by Mayuri Khinvasara Khabya – Developer Relations Engineer (LinkedIn and X)

Welcome to the second installment of our three-part series on media preloading with Media3. This series is designed to guide you through the process of building highly responsive, low-latency media experiences in your Android apps.

• Part 1: Introducing Preloading with Media3 covered the fundamentals. We explored the distinction between PreloadConfiguration for simple playlists and the more powerful DefaultPreloadManager for dynamic user interfaces. You learned how to implement the basic API lifecycle: adding media with add(), retrieving a prepared MediaSource with getMediaSource(), managing priorities with setCurrentPlayingIndex() and invalidate(), and releasing resources with remove() and release().
• Part 2 (This post): In this blog, we explore the advanced capabilities of the DefaultPreloadManager. We cover how to gain insights with PreloadManagerListener, implement production-ready best practices like sharing core components with ExoPlayer, and master the sliding window pattern to effectively manage memory.
• Part 3: The final part of this series will dive into integrating PreloadManager with a persistent disk cache, enabling you to reduce data consumption with resource management and provide a seamless experience.

If you are new to preloading in Media3, we highly recommend reading Part 1 before proceeding. For those ready to move beyond the basics, let’s explore how to elevate your media playback implementation.

Listening in: Fetch analytics with PreloadManagerListener

When you want to launch a feature in production, as an app developer you also want to understand and capture the analytics behind it. How can you be certain that your preloading strategy is effective in a real-world environment? Answering this requires data on success rates, failures, and performance. The PreloadManagerListener interface is the primary mechanism for gathering this data.

The PreloadManagerListener provides two essential callbacks that offer critical insights into the preloading process and status.

• onCompleted(MediaItem mediaItem): This callback is invoked upon the successful completion of a preload request, as defined by your TargetPreloadStatusControl.
• onError(PreloadException error): This callback could be useful for debugging and monitoring. It is invoked when a preload fails, providing the associated exception.

You can register a listener with a single method call as shown in the following example code:

val preloadManagerListener = object : PreloadManagerListener {
    override fun onCompleted(mediaItem: MediaItem) {
        // Log success for analytics. 
        Log.d("PreloadAnalytics", "Preload completed for $mediaItem")
    }

    override fun onError( preloadError: PreloadException) {
        // Log the specific error for debugging and monitoring.
        Log.e("PreloadAnalytics", "Preload error ", preloadError)
    }
}

preloadManager.addListener(preloadManagerListener)

Extracting insights from the listener 

These listener callbacks can be hooked to your analytics pipeline. By forwarding these events to your analytics engine, you can answer key questions like:

• What is our preload success rate? (ratio of onCompleted events to total preload attempts)
• Which CDNs or video formats exhibit the highest error rates? (By parsing the exceptions from onError)
• What is our preload error rate? (ratio of onError events to total preload attempts)

This data could give you quantitative feedback on your preloading strategy, enabling A/B testing and data-driven improvements to your user experience. This data can further help you to intelligently finetune your preload durations and number of videos you want to preload as well as the buffers you allocate.

Beyond debugging: Using onError for graceful UI fallback

A failed preload is a strong indicator of an upcoming buffering event for the user. The onError callback allows you to respond reactively. Instead of merely logging the error, you can adapt the UI. For instance, if the upcoming video fails to preload, your application could disable autoplay for the next swipe, requiring a user tap to begin playback.

Additionally, by inspecting the PreloadException type you can define a more intelligent retry strategy. An app can choose to immediately remove a failing source from the manager based on the error message or HTTP status code. The item would need to be removed from the UI stream accordingly to not make loading issues leak into the user experience. You could also get more granular data from PreloadException like the HttpDataSourceException to probe further into the errors. Read more about ExoPlayer troubleshooting.

The buddy system: Why is sharing components with ExoPlayer necessary?

The DefaultPreloadManager and ExoPlayer are designed to work together. To ensure stability and efficiency, they must share several core components. If they operate with separate, uncoordinated components, it could impact thread safety and usability of preloaded tracks on the player since we need to ensure that preloaded tracks should be played on the correct player. The separate components could also compete for limited resources like network bandwidth and memory, which could lead to performance degradation. An important part of the lifecycle is handling appropriate disposal, the recommended order of disposal is to release the PreloadManager first, followed by the ExoPlayer.

The DefaultPreloadManager.Builder is designed to facilitate this sharing and has APIs to instantiate both your PreloadManager and a linked player instance. Let’s see why components like BandwidthMeter, LoadControl, TrackSelector, Looper must be shared. Check the visual representation of how these components interact with ExoPlayer Playback.

Preventing bandwidth conflicts with a shared BandwidthMeter

The BandwidthMeter provides an estimate of available network bandwidth based on historical transfer rates. If the PreloadManager and the player use separate instances, they are unaware of each other’s network activity, which can lead to failure scenarios. For example, consider the scenario where a user is watching a video, their network connection degrades, and the preloading MediaSource simultaneously initiates an aggressive download for a future video. The preloading MediaSource’s activity would consume bandwidth needed by the active player, causing the current video to stall. A stall during playback is a significant user experience failure.

By sharing a single BandwidthMeter, the TrackSelector is able to select tracks of highest quality given the current network conditions and the state of the buffer, during preloading or playback. It can then make intelligent decisions to protect the active playback session and ensure a smooth experience.

preloadManagerBuilder.setBandwidthMeter(customBandwidthMeter)

Ensuring consistency with shared LoadControl, TrackSelector, Renderer components of ExoPlayer

• LoadControl: This component dictates buffering policy, such as how much data to buffer before starting playback and when to start or stop loading more data. Sharing LoadControl ensures that the memory consumption of player and PreloadManager is guided by a single, coordinated buffering strategy across both preloaded and actively playing media, preventing resource contention. You will have to smartly allocate buffer size coordinating with how many items you are preloading and with what duration, to ensure consistency. In times of contention, the player will prioritize playback of the current item displayed on the screen. With a shared LoadControl, the preload manager will continue preloading as long as the target buffer bytes allocated for preloading hasn’t reached the upper limit, it doesn’t wait until the loading for playback is done.

Note : The sharing of LoadControl in the latest version of Media3 (1.8) ensures that its Allocator can be shared correctly with PreloadManager and player. Using the LoadControl to effectively control the preloading is a feature that will be available in the upcoming Media3 1.9 release.

preloadManagerBuilder.setLoadControl(customLoadControl)

• TrackSelector: This component is responsible for selecting which tracks (for example, video of a certain resolution, audio in a specific language) to load and play. Sharing ensures that the tracks selected during preloading are the same ones the player will use. This avoids a wasteful scenario where a 480p video track is preloaded, only for the player to immediately discard it and fetch a 720p track upon playback.< br />
  The preload manager should NOT share the same instance of TrackSelector with the player. Instead, they should use the different TrackSelector instance but of the same implementation. That’s why we set the TrackSelectorFactory rather than a TrackSelector in the DefaultPreloadManager.Builder.

preloadManagerBuilder.setTrackSelectorFactory(customTrackSelectorFactory)

• Renderer: This component is responsible for understanding the player’s capabilities without creating the full renderers. It checks this blueprint to see which video, audio, and text formats the final player will support. This allows it to intelligently select and download only the compatible media track and prevents wasting bandwidth on content the player can’t actually play.

preloadManagerBuilder.setRenderersFactory(customRenderersFactory)

Read about more Exoplayer components.

The golden rule: A common Playback Looper to rule them all

The thread on which an ExoPlayer instance can be accessed can be explicitly specified by passing a Looper when creating the player. The Looper of the thread from which the player must be accessed can be queried using Player.getApplicationLooper. By maintaining a shared Looper between the player and PreloadManager, it is guaranteed that all operations on these shared media objects are serialized onto a single thread’s message queue. This can reduce the concurrency bugs.

All interactions between the PreloadManager and the player with media sources to be loaded or preloaded need to happen on the same playback thread. Sharing the Looper is a must for thread safety and hence we must share the PlaybackLooper between the PreloadManager and player.

The PreloadManager prepares a stateful MediaSource object in the background. When your UI code calls player.setMediaSource(mediaSource), you are performing a handoff of this complex, stateful object from the preloading MediaSource to the player. In this scenario, the entire PreloadMediaSource is moved from the manager to the player. All these interactions and handoffs should occur on the same PlaybackLooper.

If the PreloadManager and ExoPlayer were operating on different threads, a race condition could occur. The PreloadManager’s thread could be modifying the MediaSource’s internal state (e.g, writing new data into a buffer) at the exact moment the player’s thread is attempting to read from it. This leads to unpredictable behavior, IllegalStateException that is difficult to debug.

preloadManagerBuilder.setPreloadLooper(playbackLooper)

Lets see how you can share all the above components between ExoPlayer and DefaultPreloadManager in the setup itself.

val preloadManagerBuilder =
DefaultPreloadManager.Builder(context, targetPreloadStatusControl)

// Optional - Share components between ExoPlayer and DefaultPreloadManager
preloadManagerBuilder
     .setBandwidthMeter(customBandwidthMeter)
     .setLoadControl(customLoadControl)
     .setMediaSourceFactory(customMediaSourceFactory)
     .setTrackSelectorFactory(customTrackSelectorFactory)
     .setRenderersFactory(customRenderersFactory)
     .setPreloadLooper(playbackLooper)

val preloadManager = val preloadManagerBuilder.build()

Tip: If you use the Default components in ExoPlayer like the DefaultLoadControl, etc, you don’t need to explicitly share them with DefaultPreloadManager. When you build your ExoPlayer instance via the buildExoPlayer of the DefaultPreloadManager.Builder these components are automatically referenced with each other, if you use the default implementations with default configurations. But if you use custom components or custom configurations, you should explicitly notify the DefaultPreloadManager about them via the above APIs.

Production-ready preloading: The sliding window pattern

In a dynamic feed, a user can scroll through a virtually infinite amount of content. If you continuously add videos to the DefaultPreloadManager without a corresponding removal strategy, you will inevitably cause an OutOfMemoryError. Each preloaded MediaSource holds onto a SampleQueue, which allocates memory buffers. As these accumulate, they can exhaust the application’s heap space. The solution is an algorithm you may already be familiar with, called the sliding window.
The sliding window pattern maintains a small, manageable set of items in memory that are logically adjacent to the user’s current position in the feed. As the user scrolls, this “window” of managed items slides with them, adding new items that come into view, and also removing items that are now distant.

Implementing the sliding window pattern

It is essential to understand that PreloadManager does not provide a built-in setWindowSize() method. The sliding window is a design pattern that you, the developer, are responsible for implementing using the primitive add() and remove() methods. Your application logic must connect UI events, such as a scroll or page change, to these API calls. If you want a code reference for this, we have this sliding window pattern implemented in socialite sample which also includes a PreloadManagerWrapper which imitates a sliding window.

Don’t forget to add preloadManager.remove(mediaItem) in your implementation when the item is no longer likely to come up soon in the user’s viewing. Failing to remove items that are no longer proximate to the user is the primary cause of memory issues in preloading implementations. The remove() call ensures resources are released that help you keep your app’s memory usage bound and stable.

Fine-Tuning a categorized preloading strategy with TargetPreloadStatusControl

Now that we have defined what to preload (the items in our window), we can apply a well defined strategy for how much to preload for each item. We already saw how to achieve this granularity with the TargetPreloadStatusControl setup in Part 1.

To recall, an item at position +/- 1 could have a higher probability of being played than an item at position +/- 4. You could allocate more resources (network, CPU, memory) to items the user is most likely to view next. This creates a “preloading” strategy based on proximity, which is the key to balancing immediate playback with efficient resource usage.

You could use analytics data via PreloadManagerListener as discussed in the earlier sections to decide your preload duration strategy.

Conclusion and next steps

You are now equipped with the advanced knowledge to build fast, stable, and resource-efficient media feeds using Media3’s DefaultPreloadManager.

Let’s recap the key takeaways:

• Use PreloadManagerListener to gather analytics insights and implement robust error handling.
• Always use a single DefaultPreloadManager.Builder to create both your manager and player instances to ensure important components are shared.
• Implement the sliding window pattern by actively managing add() and remove() calls to prevent OutOfMemoryError.
• Use TargetPreloadStatusControl to create a smart, tiered preloading strategy that balances performance and resource consumption.

What’s next in Part 3: Caching with preloaded media

Preloading data into memory provides an immediate performance benefit, but it can come with tradeoffs. Once the application is closed or the preloaded media is removed from the manager, the data is gone. To achieve a more persistent level of optimization, we can combine preloading with disk caching. This feature is in active development and will come soon in a few months.

Do you have any feedback to share? We are eager to hear from you.

Stay tuned, and go make your video playback faster! 🚀

Program Level Up terbuka untuk semua game¹, termasuk akses ke alat yang kuat dan peluang promosi. Permainan dapat tetap terdaftar dalam program dan memaksimalkan manfaat dengan memenuhi pedoman pengalaman pengguna oleh setiap tonggak program, tanggal tonggak pertama adalah Juli 2026. Mari kita lihat lebih dekat manfaat dan pedoman dari Google Play Games Level Up.

https://www.youtube.com/watch?v=xy9wq-hrene

Manfaat program untuk mempercepat pertumbuhan Anda

Game yang merupakan bagian dari program Level Up dapat mengakses serangkaian manfaat untuk mempercepat pertumbuhan bisnis. Ini termasuk ruang baru untuk terlibat dengan pemain, akses ke alat konten di Play Console, dan peningkatan peluang penemuan melalui permukaan editorial di Play Store.

1. Tab ulang pemain pada tab Anda. You Tab² adalah tujuan pribadi baru di Play Store di mana pemain dapat melihat konten dan hadiah dari game yang baru -baru ini mereka mainkan, semuanya di satu tempat khusus. Ini dirancang untuk membantu Anda melibatkan kembali dan mempertahankan pemain dengan menampilkan acara terbaru, penawaran, dan pembaruan Anda.

   Game dapat menampilkan konten mereka di tab Anda menggunakan alat pertunangan di Play Console. Anda dapat mendorong keterlibatan pemain melalui kehadiran toko yang kaya menggunakan konten promosi, kupon poin, video YouTube, dan pencapaian, yang semuanya muncul di halaman detail game Anda dan tab Anda.

   
   Clash of Clans sedang melibatkan kembali pemain melalui tab Anda

2. Maksimalkan jangkauan permainan Anda. Untuk memudahkan pemain untuk menemukan permainan hebat, kami memasukkan pedoman pengalaman pengguna ke dalam kriteria editorial kami. Game yang merupakan bagian dari program ini akan memiliki kesempatan untuk meningkatkan menonjol di seluruh toko termasuk menampilkan peluang dan bermain poin dan pencarian. Judul yang merupakan bagian dari program ini akan memiliki lebih banyak peluang untuk direkomendasikan melalui permukaan editorial di seluruh toko termasuk rumah permainan dan poin bermain di rumah.

   
   Dapatkan lebih banyak kesempatan untuk ditampilkan di permukaan editorial

3. Buka wawasan kinerja yang lebih dalam. Membuat keputusan yang tepat untuk menumbuhkan permainan Anda membutuhkan gambaran yang jelas tentang seluruh bisnis Anda. Tahun depan, kami memperkenalkan pelaporan yang lebih maju di Play Console. Anda akan dapat menghubungkan titik-titik dari akuisisi pemain ke keterlibatan jangka panjang dan monetisasi, memberi Anda wawasan holistik yang diperlukan untuk mengoptimalkan strategi pertumbuhan Anda dengan percaya diri.

Pedoman yang dibangun di atas pengalaman pengguna yang hebat

Saat ini, Microsoft membuat Windows ML tersedia untuk pengembang. Windows ML memungkinkan pengembang C#, C ++ dan Python untuk menjalankan model AI secara optimal di seluruh perangkat keras PC dari CPU, NPU dan GPU. Pada NVIDIA RTX GPU, ini menggunakan NVIDIA TensorRT untuk penyedia eksekusi RTX (EP) yang memanfaatkan inti tensor GPU dan kemajuan arsitektur seperti FP8 dan FP4, untuk memberikan kinerja inferensi AI tercepat pada RTX AI PCS berbasis Windows.

“Windows ML membuka akselerasi Tensorrt penuh untuk GeForce RTX dan RTX Pro GPU, memberikan kinerja AI yang luar biasa di Windows 11,” kata Logan Iyer, VP, Insinyur Terhormat, Platform Windows dan Pengembang. “Kami senang umumnya tersedia untuk pengembang hari ini untuk membangun dan menggunakan pengalaman AI yang kuat pada skala.”

Tinjauan Windows ML dan TensorRT untuk RTX EP

Windows ML dibangun di atas API runtime ONNX untuk menyimpulkan. Ini memperluas API runtime ONNX untuk menangani inisialisasi dinamis dan manajemen ketergantungan dari penyedia eksekusi di CPU, NPU, dan perangkat keras GPU pada PC. Selain itu, Windows ML juga secara otomatis mengunduh penyedia eksekusi yang diperlukan sesuai permintaan, mengurangi kebutuhan pengembang aplikasi untuk mengelola dependensi dan paket di beberapa vendor perangkat keras yang berbeda.

NVIDIA TensorRT untuk Penyedia Eksekusi RTX (EP) memberikan beberapa manfaat bagi pengembang ML Windows menggunakan Onnx Runtime termasuk:

• Jalankan model ONNX dengan inferensi latensi rendah dan 50% throughput lebih cepat dibandingkan dengan implementasi DirectML sebelumnya pada GPU NVIDIA RTX, seperti yang ditunjukkan pada gambar di bawah ini.
• Terintegrasi secara langsung dengan WindowsML dengan arsitektur EP yang fleksibel dan integrasi dengan ORT.
• Kompilasi tepat waktu untuk penyebaran ramping pada perangkat pengguna akhir. Pelajari lebih lanjut tentang proses kompilasi dalam Tensorrt untuk RTX. Proses kompilasi ini didukung dalam runtime ONNX sebagai model konteks EP.
• Kemajuan Arsitektur Leverage seperti FP8 dan FP4 pada inti tensor
• Paket ringan di bawah 200 MB.
• Dukungan untuk berbagai arsitektur model dari LLMS (dengan ekstensi Onnx Runtime Genai SDK), difusi, CNN, dan banyak lagi.

Pelajari lebih lanjut tentang TensorRT untuk RTX.

Memilih penyedia eksekusi

Rilis 1.23.0 ONNX Runtime, disertakan dengan WindowsML, menyediakan vendor dan penyedia eksekusi API independen untuk pemilihan perangkat. Ini secara dramatis mengurangi jumlah logika aplikasi yang diperlukan untuk memanfaatkan penyedia eksekusi optimal untuk setiap platform vendor perangkat keras. Lihat di bawah untuk kutipan kode tentang cara melakukan ini secara efektif dan memperoleh kinerja maksimum pada GPU NVIDIA.

// Register desired execution provider libraries of various vendors
auto env = Ort::Env(ORT_LOGGING_LEVEL_WARNING);
env.RegisterExecutionProviderLibrary("nv_tensorrt_rtx", L"onnxruntime_providers_nv_tensorrt_rtx.dll");

// Option 1: Rely on ONNX Runtime Execution policy
Ort::SessionOptions sessions_options;
sessions_options.SetEpSelectionPolicy(OrtExecutionProviderDevicePolicy_PREFER_GPU);

// Option 2: Interate over EpDevices to perform manual device selection 
std::vector<Ort::ConstEpDevice> ep_devices = env.GetEpDevices();
std::vector<Ort::ConstEpDevice> selected_devices = select_ep_devices(ep_devices);

Ort::SessionOptions session_options;
Ort::KeyValuePairs ep_options;
session_options.AppendExecutionProvider_V2(env, selected_devices, ep_options);

# Register desired execution provider libraries of various vendors
ort.register_execution_provider_library("NvTensorRTRTXExecutionProvider", "onnxruntime_providers_nv_tensorrt_rtx.dll")

# Option 1: Rely on ONNX Runtime Execution policy
session_options = ort.SessionOptions()
session_options.set_provider_selection_policy(ort.OrtExecutionProviderDevicePolicy.PREFER_GPU)

# Option 2: Interate over EpDevices to perform manual device selection
ep_devices = ort.get_ep_devices()
ep_device = select_ep_devices(ep_devices)

provider_options = {}
sess_options.add_provider_for_devices([ep_device], provider_options)

Runtime yang dikompilasi menawarkan waktu pemuatan cepat

Model RunTimes sekarang dapat dikompilasi menggunakan file konteks EP ONNX dalam ONNX Runtime. Setiap penyedia eksekusi dapat menggunakan ini untuk mengoptimalkan seluruh subgraph dari model ONNX, dan memberikan implementasi spesifik EP. Proses ini dapat diserialisasi ke disk untuk mengaktifkan waktu pemuatan cepat dengan windowsml, seringkali ini lebih cepat daripada metode berbasis operator tradisional sebelumnya dalam ML langsung.

Bagan di bawah ini menunjukkan bahwa TensorRT untuk RTX EP membutuhkan waktu untuk dikompilasi, tetapi lebih cepat memuat dan melakukan inferensi pada model karena optimasi sudah diserialisasi. Selain itu, fitur cache runtime dalam TensorRT untuk RTX EP memastikan bahwa kernel yang dihasilkan selama fase kompilasi diserialisasi dan disimpan ke direktori, sehingga mereka tidak harus dikompilasi ulang untuk inferensi berikutnya.

Overhead transfer data minimal dengan ONNX Runtime Device API dan Windows ML

ONNX Runtime Device API baru, juga tersedia di Windows ML, menyebutkan perangkat yang tersedia untuk setiap penyedia eksekusi. Dengan menggunakan gagasan baru ini, pengembang sekarang dapat mengalokasikan tensor khusus perangkat, tanpa spesifikasi tipe EP-dependen tambahan.

Dengan memanfaatkan copytensors dan iobinding, API ini memungkinkan pengembang untuk melakukan inferensi EP-agnostik, GPU-dipercepat dengan overhead transfer data runtime minimal-memberikan peningkatan kinerja dan desain kode yang lebih bersih.

Gambar 5 menampilkan model medium difusi 3.5 stabil yang memanfaatkan API perangkat runtime ONNX. Gambar 4 di bawah ini mewakili waktu yang diperlukan untuk satu iterasi tunggal dalam loop difusi untuk model yang sama, baik dengan dan tanpa binding perangkat IO.

Menggunakan sistem NSIGHT, kami memvisualisasikan overhead kinerja karena salinan berulang antara host dan perangkat saat tidak menggunakan IO Binding:

Sebelum setiap run inferensi, operasi salinan input tensor selesai, yang disorot sebagai hijau di profil kami dan perangkat untuk meng -host salinan output membutuhkan waktu yang bersamaan. Selain itu, Onnx Runtime secara default menggunakan memori yang dapat di -pagable yang perangkat untuk meng -host salinan adalah sinkronisasi implisit, meskipun API Cudamemcpyasync digunakan oleh ONNX Runtime.

Di sisi lain, ketika input dan output tensor terikat IO, salinan input host-ke-perangkat terjadi hanya sekali sebelum pipa inferensi multi-model. Hal yang sama berlaku untuk salinan output perangkat-ke-host, setelah itu kami menyinkronkan CPU dengan GPU lagi. Jejak async nsight di atas menggambarkan beberapa inferensi berjalan di loop tanpa operasi salinan atau operasi sinkronisasi di antaranya, bahkan membebaskan sumber daya CPU sementara itu. Ini menghasilkan waktu salinan perangkat 4,2 milidetik dan waktu salinan host satu kali 1,3 milidetik, membuat total waktu salinan 5,5 milidetik, terlepas dari jumlah iterasi dalam loop inferensi. Untuk referensi, pendekatan ini menghasilkan pengurangan ~ 75x dalam waktu salin untuk loop 30 iterasi!

TensorRT untuk optimasi spesifik RTX

TensorRT untuk eksekusi RTX menawarkan opsi khusus untuk mengoptimalkan kinerja lebih lanjut. Optimalisasi terpenting tercantum di bawah ini.

• Grafik CUDA: Diaktifkan dengan pengaturan enable_cuda_graph Untuk menangkap semua kernel CUDA yang diluncurkan dari Tensorrt di dalam grafik, sehingga mengurangi overhead peluncuran di CPU. Ini penting jika grafik Tensorrt meluncurkan banyak kernel kecil sehingga GPU dapat mengeksekusi ini lebih cepat daripada CPU dapat mengirimkannya. Metode ini menghasilkan sekitar 30% kenaikan kinerja dengan LLM, dan berguna untuk banyak jenis model, termasuk model AI tradisional dan arsitektur CNN.

• Cache runtime: nv_runtime_cache_path Poin ke direktori di mana kernel yang dikompilasi dapat di -cache untuk waktu beban cepat dalam kombinasi dengan menggunakan node konteks EP.

• Bentuk dinamis: Timpa rentang bentuk dinamis yang diketahui dengan mengatur 3 opsi profile_{min|max|opt]_shapes atau dengan menentukan bentuk statis menggunakan AddFreedimensionOverrideByName untuk memperbaiki bentuk input model. Saat ini, fitur ini dalam mode eksperimental.

Ringkasan

Kami senang berkolaborasi dengan Microsoft untuk membawa Windows ML dan TensorRT untuk RTX EP ke pengembang aplikasi Windows untuk kinerja maksimum di NVIDIA RTX GPU. Pengembang aplikasi Windows Top termasuk Topaz Labs, dan Wondershare Filmora saat ini sedang berupaya mengintegrasikan Windows ML dan TensorRT untuk RTX EP ke dalam aplikasi mereka.

Mulailah dengan Windows ML, ONNX Runtime API, dan TensorRT untuk RTX EP menggunakan sumber daya di bawah ini:

Tetap disini untuk perbaikan di masa mendatang dan mempercepat dengan API baru yang ditunjukkan sampel kami. Jika ada permintaan fitur dari pihak Anda, jangan ragu untuk membuka masalah di GitHub dan beri tahu kami!

Ucapan Terima Kasih

Kami ingin mengucapkan terima kasih kepada Gaurav Garg, Kumar Anshuman, Umang Bhatt, dan Vishal Agarawal atas kontribusi mereka ke blog.