Asynchronous Texture Upload 異步貼圖上傳 AUP(Async Upload Pipeline)
本文檔主要是對Unity官方手冊的個人理解與總結（其實以翻譯記錄爲主：>）
僅作爲個人學習使用，不得作爲商業用途，歡迎轉載，並請註明出處。
文章中涉及到的操作都是基於Unity2018.4版本
參考鏈接：https://docs.unity3d.com/Manual/AsyncTextureUpload.html
Asynchronous Texture Upload enables asynchronous loading of Texture Data from disk and enables time-sliced upload to GPU on the Render-thread. This reduces wait for GPU uploads in the main thread. Async Texture Upload will automatically be used for all Textures that are not read-write enabled, so to use this feature no direct action is required. You can however control some aspects of how the async upload operates, and so some understanding of the process is useful to be able to use these controls.
AUP支持從磁盤異步加載紋理數據，並支持在渲染線程上以時間片方式把紋理數據上傳到GPU。這減少了紋理數據從主線程上傳到GPU的等待時間。AUP將自動用於所有未啓用讀寫的紋理，因此使用此功能不需要直接操作。不過，您可以控制AUP的一些參數，因此瞭解其過程有助於使用這些參數。
When the project is built, the texture data of asynchronous uploadable textures are stored in as streaming resource files and are loaded asynchronously.
在構建項目時，異步可上傳紋理的紋理數據作爲流資源文件存儲並用於異步加載。
Simple & Full Control Over Memory / Time-Slicing 簡單並全面由內存和時間片控制
A single ring-buffer is reused to load the texture data and upload it to the GPU, which reduces the amount of memory allocations required. For example, if you have 20 small textures, Unity will set up an asynchronous load request for those 20 textures in one go. If you have one huge texture, Unity will request only one.
一個環形緩衝區被重用來加載紋理數據並上傳到GPU，這減少了所需的內存分配量。例如，如果你有20個小紋理，Unity會一次性爲這20個紋理建立一個異步加載請求。如果你有一個巨大的紋理，那Unity只請求加載一個。
If the buffer size is not large enough for the textures being requested, it will automatically resize to accomodate, however it is always optimal to try to set the size to fit the largest sized texture that you will be uploading from the outset, so that the buffer does not need to resize for each new larger texture it encounters.
如果可請求的紋理緩衝區大小不足夠大,它會自動調整適應,然而它總是設置大小爲最大的紋理大小以作爲最優的內存佔用,這是從一開始上傳就開始調整的,所以緩衝不需要爲每個新遇到的更大的紋理而調整。
The time spent on texture upload each frame can be controlled, with larger values meaning the textures will become ready on the GPU sooner but with the overhead of more CPU time being used during those frames for other processing. This CPU time is only used if there are textures waiting in the buffer to be uploaded to the GPU.
花在每幀紋理上傳的時間是可以被控制的，更大的值意味着紋理數據將會在GPU上更快地就緒，但這些幀的佔用導致用於其他處理的CPU時間開銷會更大。這個CPU時間只在緩存中有紋理數據等待上傳到GPU時纔會持續佔用。
The size of the buffer and time-slice can be specified through the Quality settings:
緩衝區大小和時間片可以通過Quality設置來指定:
The Async Upload settings in the Quality settings
Async Texture Upload Scripting API AUP的腳本API
We provide the ability to control the Buffer Size and the Time-Slice value from script.
我們提供了從腳本控制 緩衝區大小 和 時間片值 的功能。
Time-Slice
Sets the Time-Slice in milliseconds for CPU time spent on Asynchronous Texture Uploads per frame. Depending on the target platform and API, you may want to set this. Time is only spent on the function call if there are textures to upload, otherwise it early-exits.
設置每幀用於AUP的CPU時間片(以毫秒爲單位)。根據目標平臺和API的不同，您可能需要設置這個參數。只有當要上傳紋理時，纔會耗費時間在AUP的函數調用上，否則它會提前退出。
Buffer Size
Set the Ring Buffer Size for Asynchronous Texture Uploads. The size is in mega-bytes. Ensure that you set a reasonable size depending on the Target platform. Also please ensure that it is always sufficient to load any huge texture in your games. For example if you have a Cubemap of size 22MB and if you set the size of the RingBuffer to 16MB, the App will automatically resize the Ringbuffer to 22MB while loading that scene.
設置AUP的環形緩衝區大小。大小以MB爲單位。確保根據目標平臺設置合理的大小。此外，請確保它總是足夠加載任何巨大的紋理在您的遊戲。例如，如果您有一個22MB大小的Cubemap，並且將RingBuffer的大小設置爲16MB，那麼在加載該場景時，應用程序將自動將RingBuffer的大小調整爲22MB。
Notes
For non-read/write enabled textures, the TextureData is part of resS (Streaming Resource) and upload now happens on Render-Thread. Availability of Texture is guaranteed during call to AwakeFromLoad just as before, so there are no changes in terms of order of loading or availability of Textures on Rendering.
對於非 讀/寫 的紋理，TextureData作爲resS(流資源)的一部分，現在可以在渲染線程上進行上傳。紋理的可用性在調用AwakeFromLoad時就得到了保證，就像以前一樣，因此在加載順序或渲染時紋理的可用性方面沒有變化。
For other types of texture loading, such as read/write enabled textures, textures loaded directly with the LoadImage(byte[] data) function, or loading from the Resources folder, the Asynchronous buffer loading is not used - the older Synchronous method is used.
對於其他類型的紋理加載，比如支持 讀/寫 的紋理，直接用LoadImage(byte[] data)函數加載的紋理，或者從Resources文件夾加載的紋理，都不會用AUP加載而是使用舊的同步方法。