• Variable%20Rate%20Shading

Variable%20Rate%20Shading(VRS，可變率著色)允許像素著色器一次著色一個或多個像素，這樣一個著色計算可以代表一個像素或一組像素。VRS是反鋸齒技術(shù)的逆解。抗鋸齒技術(shù)通過平滑高變化的內(nèi)容，更頻繁地采樣每個像素，以避免走樣（aliasing）和鋸齒（jagged）邊緣。然而，如果要渲染的表面沒有高的顏色變化或?qū)⒃陔S后的通道上被模糊(例如，運動模糊)，在每個像素都一個著色計算的操作通常是低效的。

VRS允許開發(fā)者指定著色率，其中只對一個像素執(zhí)行一個著色器計算，結(jié)果操作應(yīng)用于指定的像素組配置。如果使用得當(dāng)，應(yīng)該不會導(dǎo)致視覺質(zhì)量下降，同時顯著減輕GPU渲染的負擔(dān)，從而節(jié)省功耗并提高性能。

VRS示意圖。畫面根據(jù)顏色變化頻率采用不同的著色率，變化高的采用高著色率（如汽車），反之用低著色率（如左下和右下路面）。

VRS支持的常見著色率和運行機制。其中黃點是著色坐標，綠點是直接復(fù)用黃點的著色結(jié)果。

VRS在渲染管線的工作機制。VRS在光柵化階段采用指定著色率執(zhí)行光柵化，進入PS之后再放大。

UE可以給每個材質(zhì)設(shè)定1個著色率，在材質(zhì)屬性模板中：

VRS優(yōu)化的核心思想在于減少計算次數(shù)并復(fù)用周邊計算點的結(jié)果，從而達到提升渲染效率的目的。適合使用VRS的情形：

• 顏色變化率低的物體。
• 處于運動模糊區(qū)域的物體。
• 景深范圍之外的物體。

使用移動端的VRS需要依賴不同圖形API的擴展：

// ------ OpenGLES ------// Qualcomm QCOM_shading_rateGL_SHADING_RATE_1X1_PIXELS_QCOMGL_SHADING_RATE_1X2_PIXELS_QCOM......// Arm / Imagination Tech(不支持)// ------ Vulkan ------VK_KHR_fragment_shading_rate

• 使用Vulkan代替OpenGL。

相比OpenGL等傳統(tǒng)API，Vulkan支持多線程，輕量化驅(qū)動層，可以精確地管控GPU內(nèi)存、同步等資源，避免運行時校驗，基于命令隊列的機制，沒有全局狀態(tài)等等（下圖）。

得益于Vulkan的先進設(shè)計理念，使得它的渲染性能更高，通常在CPU、GPU、帶寬、能耗等指標都優(yōu)于OpenGL。但如果是應(yīng)用程序本身的CPU或者GPU負載高，則使用Vulkan的收益可能沒有那么明顯：

• 使用遮擋剔除。

遮擋剔除可以提前剔除掉被遮擋的物體或者遠處占屏幕很小的物體，避免進入GPU管線，占用帶寬和計算資源。UE在移動端的遮擋剔除延遲了兩幀（因為BasePass結(jié)束之后才有深度緩沖，需要再增加一幀延遲確保結(jié)果可用）：

然后是在RHI線程等待遮擋查詢的結(jié)果，遮擋查詢的結(jié)果是在渲染線程使用，由于延遲了兩幀，所以渲染線程在計算可見性時不需要等待：

使用遮擋剔除時，需要遵循以下建議：

1、只在需要時返回查詢結(jié)果，不要等待它，因為同步等待是非常低效的。

2、對于遮擋，只在必要時使用精確計數(shù)選項。OpenGL ES使用GL_ANY_SAMPLES_PASSED,、Vulkan使用VK_QUERY_CONTROL_PRECISE_BIT = false，除非確實需要知道遮擋的數(shù)量。

3、不要修改正在繪制調(diào)用中引用的資源。

4、不要將GL_MAP_INVALIDATE_BUFFER /GL_MAP_INVALIDATE_RANGE與glMapBufferRange()一起使用，因為這些標志在某些版本的驅(qū)動會觸發(fā)創(chuàng)建一個不必要的資源拷貝。

12.6.1.2 管線優(yōu)化

• 曲面細分期間消除子像素。

曲面細分增加細節(jié)級別，并可以通過允許其他游戲子系統(tǒng)在低分辨率的網(wǎng)格表示上操作來減少內(nèi)存帶寬和CPU周期。然而，高級別的曲面細分可以產(chǎn)生子像素三角形，這導(dǎo)致光柵化利用率降低。利用距離、屏幕空間大小或其他自適應(yīng)度量來計算避免子像素三角形的曲面細分因子是很重要的。

• 曲面細分期間開啟背面剔除。

圖元的背面剔除可以防止冗余的像素進入像素著色器中，從而提升性能。

• 刪除未使用的render target或shader資源。

操作更多的RT或shader資源，會增加帶寬，降低性能。故而盡量刪除未引用的資源。

• 避免GMEM加載。

在每個Pass渲染之前，需要調(diào)用圖形API明確清理RT。

OpenGL ES: glClear()

Vulkan: LOAD_OP_CLEAR / LOAD_OP_DONT_CARE

• 使用subpass或PLS。

Vulkan的subpass（或OpenGL ES的PLS）可以讓多個pass的數(shù)據(jù)持續(xù)保存在GMEM（Tile緩沖區(qū)）中，避免數(shù)據(jù)反復(fù)從GMEM和全局內(nèi)存之間傳輸，從而降低帶寬和延時。

• 使用PSO緩存。運行時創(chuàng)建PSO對象比較消耗CPU性能，如果在離線階段收集、編譯材質(zhì)使用的Shader并保存成二進制文件，以便下次運行時調(diào)用時直接讀取Cache文件并轉(zhuǎn)成PSO對象，可以降低CPU負載。下圖是UE的PSO緩存機制圖示：

更多詳情請參看UE官方文檔：PSO%20Caching。

• 使用僅深度（Z-only）渲染。

GPU有一種特殊的模式，可以以兩倍于正常模式的速率寫入Z-only像素，例如應(yīng)用程序渲染陰影圖。

有兩種方式可以讓GPU進入此模式：

1、圖形API明確指示，硬件才能進入這個特殊的渲染模式。

2、應(yīng)用程序通過特定的渲染狀態(tài)提示驅(qū)動程序。比如：使用一個空的片元著色器和禁用Frame%20Buffer（幀緩沖區(qū)）寫掩碼。

一些渲染程序或引擎（如UE）會使用專用的PrePass來渲染深度，以充分利用Early-Z計算。不過對于移動端GPU需要謹慎對待，應(yīng)以實際測試為準。

• 使用間接索引（indirect%20indexed）的繪制接口。

間接繪制調(diào)用將開銷從CPU轉(zhuǎn)移到GPU，從而減少CPU和GPU的帶寬。例如，在加載時緩存繪制調(diào)用參數(shù)，以便在緩沖對象存儲中渲染網(wǎng)格。這些緩存數(shù)據(jù)可以作為glDrawArraysIndirect%20或glDrawElementsIndirect的輸入?yún)?shù)。

需要OpenGL%20ES%203.1才支持。

• Draw%20Call優(yōu)化。
  • 合并幾何物體，同時合并它們的材質(zhì)。
  • 使用批處理，即便不是CPU受限，也可以減少能耗。
  • 使用實例化（instance）。
  • 使用非直接索引繪制。
  • 避免多次繪制小量物體。
  • 根據(jù)高中低畫質(zhì)設(shè)定合理的Draw%20Call數(shù)量。

使用批處理時，要注意頂點總數(shù)限制，不能超過索引的表達范圍（通常最大是65k）。另外，如果合并或批處理之后的物體包圍盒過大，反而會造成性能下降，因為無法有效使用Frustum%20Cullinig、遮擋剔除等技術(shù)進行剔除。

另外，需要注意提交的幾何物體具有相鄰性，盡量落在同一個Tile內(nèi)，以減少覆蓋的Tile數(shù)量，降低帶寬，提升緩存命中率：

上：良好的幾何物體提交順序；下：錯誤的幾何物體提交順序。

• 禁用Alpha Test / Discard。

Alpha Test會打亂TBR的正常流程，造成渲染管線Stall，在PowerVR尤為明顯（Alpha Test階段會寫回深度到HSR階段）。

因為TB(D)R在渲染不透明物體時普遍開啟了Early-Z技術(shù)和特殊的隱藏面消除技術(shù)（HSR、FPK），在此階段會開啟深度測試，并寫入通過了深度測試的片元深度。但是，如果開啟了Alpha Test或Shader中使用了Discard，無法在Early-Z/隱藏面消除技術(shù)階段就確定該片元的深度是否有效，必須等執(zhí)行完P(guān)S、Alpha Test等階段才行：

這樣就無法充分發(fā)揮HSR技術(shù)的優(yōu)勢，從而降低渲染性能。

可以使用Alpha Blend代替Alpha Test。如果確實需要Alpha Test，則物體的渲染順序需尊照此順序：Opaque -> Alpha-tested -> Blended。

• 盡量減少Alpha Blend。

原因是延遲渲染器，比如PowerVR GPU，在片元著色器處理它之前計算片元的可見性，防止輸出圖像中的不可見片元被不必要地處理。如果需要透明對象，請盡量減少透明對象的數(shù)量。

由于Alpha Blend不能寫入深度，不能充分利用HSR/FPK，會引發(fā)Overdraw，提升帶寬和數(shù)據(jù)傳輸量。

如果確實需要，有以下優(yōu)化建議：

1、優(yōu)先使用unorm格式，而不是浮點數(shù)。（注意：此條來自Arm Mali的建議，其它GPU可能不一樣，以實測為主）

2、如果是不透明物體，應(yīng)禁用Blend和alpht to coverage。

3、不要在攜帶MSAA數(shù)據(jù)的浮點frame buffer上使用混合。

4、避免過高的OverDraw。監(jiān)控每像素基礎(chǔ)上生成的混合層數(shù)量，即使是簡單的著色器，混合層數(shù)量高會因為片元數(shù)量多而快速消耗時鐘周期。

5、考慮將大型UI元素分成不透明和透明部分。然后可以分別繪制不透明部分和透明部分，允許Early-ZS或FPK/HSR刪除不透明部分下面的OverDraw。

6、不要僅僅在片元著色器中將alpha設(shè)置為1.0來禁用混合。

• 充分利用Early-Z和FPK/HSR剔除被遮擋的像素。

為了充分利用Early-Z，物體繪制順序應(yīng)該如下所示：

1、繪制不透明物體。從前向后繪制。

2、繪制鏤空（Masked）物體。從前向后繪制。

3、繪制半透明物體。從后向前繪制。

對于廣泛支持TBR架構(gòu)的移動端GPU，不建議開啟Prepass繪制專用的深度，否則反而會增加帶寬和Draw Call。

另外，在繪制不透明物體時，盡量做到以下幾點：

1、禁用discard語句。

2、禁用Alpha to Coverage。

3、禁止在片元著色器中修改深度。

若是違反以上任意一條，便會使Early-Z失效，強制使用Late-Z，從而降低渲染效率。

• 充分開啟裁剪和測試。

裁剪技術(shù)包含遮擋剔除、視錐體裁剪、Scissor、距離裁剪、LOD等等。

測試包含背面測試、深度測試、模板測試等，但禁用透明度測試。

• 禁用Z-Prepass。

移動端GPU基于TBR結(jié)構(gòu)通常內(nèi)置了像素級的剔除，無需再專門繪制一次深度。UE在移動端默認禁用了Z-Prepass。

• 最小化模板緩沖的更新。

1、如果值相同，則使用KEEP而不是REPLACE。

2、有些渲染器（如UE）使用光照繪制Pass對（pair）：第一個Pass用于創(chuàng)建模板緩沖，第二個Pass用于給未蒙版的片元著色。可以在第二個Pass重置模板值，以便為下一個光照配對做好準備，這樣可以避免多帶帶的模板清理操作。

UE的移動端場景渲染器在繪制光照時正是使用了此種模板清理優(yōu)化方式。

• 正確調(diào)用圖形API。

  • 除非達到了目標性能，否則不要以導(dǎo)致GPU空閑的方式使用API。

  • 不要過早等待渲染管線中的圍欄（fence）和查詢（query）對象的查詢結(jié)果。

  • 調(diào)用glMapBufferRange()時使用GL_MAP_UNSYNCHRONIZED標記開啟異步，防止渲染管線卡頓。

  • 避免同步方式調(diào)用以下接口：

    • glFlush()。但是，某些GPU（如PowerVR）由于使用了雙緩沖機制，不會卡調(diào)用線程。
    • glFinish()
    • glReadPixels()
    • glWaitSync()
    • glClientWaitSync()
    • eglClientWaitSync()
    • 沒有GL_MAP_UNSYNCHRONIZED標記的glMapBufferRange()

    避免不必要地調(diào)用以上接口，調(diào)用次數(shù)越少越好。

  • 避免使用glFlush()來分割渲染通道，因為驅(qū)動程序（Mali）會在需要時自動刷新。

  • 盡可能執(zhí)行Clear。在繪制前或渲染通道開始時，使用glClear/glDiscardFramebufferEXT/glInvalidateFramebuffer執(zhí)行渲染紋理的清理，防止GPU讀取上一幀的數(shù)據(jù)到Tile緩沖區(qū)中，節(jié)省帶寬。Vulkan則使用loadOp。

  • 盡可能使用glColorMask屏蔽不需要寫入的顏色通道。

如果違反以上建議，有可能導(dǎo)致以下結(jié)果：

1、如果管道被耗盡，GPU在產(chǎn)生氣泡期間部分空閑，導(dǎo)致性能損失。

2、根據(jù)與系統(tǒng)動態(tài)電壓和頻率縮放電源管理邏輯的相互作用，可能會有一些性能不穩(wěn)定。

• 優(yōu)化Command Buffer。

1、要獲得最佳性能，請設(shè)置ONE_TIME_SUBMIT_BIT標志。不要設(shè)置SIMULTANEOUS_USE_BIT，除非確實需要。

2、構(gòu)建每幀命令緩沖區(qū)，而不是使用同步命令緩沖區(qū)。

3、如果替代方法是每次在應(yīng)用程序邏輯中重放相同的命令序列，則使用SIMULTANEOUS_USE_BIT。它比應(yīng)用程序手動重放命令更有效，但比一次性提交緩沖區(qū)更低效。

4、不要使用設(shè)置了RESET_COMMAND_BUFFER_BIT的命令池，會增加內(nèi)存管理開銷，因為驅(qū)動程序無法為池中的所有命令緩沖區(qū)使用單個大型分配器。

5、使用secondary command buffer來允許多線程渲染通道的構(gòu)造。

6、最小化每幀secondary command buffer的調(diào)用次數(shù)。

• 優(yōu)化描述符集和布局（descriptor sets and layouts）。

1、盡可能多地打包描述符集綁定空間。

2、更新已經(jīng)分配但不再引用的描述符集，而不是重置描述符池和重新分配新的描述符集。

3、重用預(yù)分配的描述符集，避免更新相同的信息。

4、使用VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER_DYNAMIC或VK_DESCRIPTOR_TYPE_STORAGE_BUFFER_DYNAMIC綁定相同的UBO或SSBO，但不同的偏移量。 另一種選擇是構(gòu)建更多的描述符集。

5、不要在描述符集中留下空白，會浪費空間，阻斷訪問連續(xù)性。

6、不要留下未使用的條目（entry），因為復(fù)制和合并依舊有消耗。

7、不要在性能關(guān)鍵的代碼路徑上從描述符池（descriptor pool）分配描述符集。

8、如果不打算更改綁定偏移量，就不要使用DYNAMIC_OFFSET UBOs/SSBOs，因為處理動態(tài)偏移量會有很小的額外成本。低效的描述符集和布局未優(yōu)化的Vulkan描述符集和布局的負面影響可能會增加繪制調(diào)用的CPU消耗。

• 避免渲染管線氣泡（空閑）。

以下幾種情況會產(chǎn)生渲染管線氣泡：

1、Command Buffer提交不夠頻繁。不經(jīng)常提交命令緩沖區(qū)會減少GPU處理隊列中的工作量，限制潛在的編排機會。

2、數(shù)據(jù)依賴。假設(shè)有渲染通道M和N，M在稍后的階段。當(dāng)N在管道中被M更早地使用時，數(shù)據(jù)依賴就產(chǎn)生了。數(shù)據(jù)依賴會導(dǎo)致延遲，在此期間必須做足夠的工作來隱藏結(jié)果生成中的延遲。

渲染管線氣泡示意圖。圖中顯示CPU、VS、PS都存在氣泡。

以下建議可以減少管線氣泡：

1、頻繁地提交Command Buffer。例如，為幀中的每個主要渲染通道之后，但渲染通道期間不宜提交。

2、如果某些情況導(dǎo)致了氣泡，嘗試填充氣泡技術(shù)。例如，通過在兩個渲染通道之間插入獨立的工作負載。

3、考慮在比使用依賴數(shù)據(jù)的階段更早的管道階段生成依賴數(shù)據(jù)。例如，計算（compute）階段適合為頂點著色階段生成輸入數(shù)據(jù)。而片元階段是不合適的，因為它的執(zhí)行晚于頂點著色階段管道，否則會造成卡頓和延時。

4、考慮在管道中的更后階段處理依賴數(shù)據(jù)。例如，片元著色使用來自其他片元著色的輸出比計算著色使用片元著色更好。

5、使用柵欄異步地將GPU的數(shù)據(jù)讀回CPU。千萬不用同步地調(diào)用從GPU讀取數(shù)據(jù)到CPU的接口，否則整個渲染管線將可能發(fā)生嚴重停滯。

此外，以下建議可以優(yōu)化渲染管線：

1、不要在管道的任何地方不必要地等待GPU數(shù)據(jù)。

2、不要等到幀結(jié)束才提交所有的渲染通道。

3、在沒有足夠的中間工作來隱藏延遲的情況下，不要在管道中創(chuàng)建任何逆向（backwards）的數(shù)據(jù)依賴。

4、不要使用vkQueueWaitIdle()或vkDeviceWaitIdle()。

• 正確使用管線同步。

現(xiàn)代圖形API（如Vulkan）擁有非常細粒度的管線階段：

typedef enum VkPipelineStageFlagBits{    VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT = 0x00000001,        // Vertex Stages    VK_PIPELINE_STAGE_DRAW_INDIRECT_BIT = 0x00000002,    VK_PIPELINE_STAGE_VERTEX_INPUT_BIT = 0x00000004,    VK_PIPELINE_STAGE_VERTEX_SHADER_BIT = 0x00000008,    VK_PIPELINE_STAGE_TESSELLATION_CONTROL_SHADER_BIT = 0x00000010,    VK_PIPELINE_STAGE_TESSELLATION_EVALUATION_SHADER_BIT = 0x00000020,    VK_PIPELINE_STAGE_GEOMETRY_SHADER_BIT = 0x00000040,    // Fragment Stages    VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT = 0x00000080,    VK_PIPELINE_STAGE_EARLY_FRAGMENT_TESTS_BIT = 0x00000100,    VK_PIPELINE_STAGE_LATE_FRAGMENT_TESTS_BIT = 0x00000200,    VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT = 0x00000400,    // Compute Stages    VK_PIPELINE_STAGE_COMPUTE_SHADER_BIT = 0x00000800,    VK_PIPELINE_STAGE_TRANSFER_BIT = 0x00001000,    VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT = 0x00002000,        VK_PIPELINE_STAGE_HOST_BIT = 0x00004000,    VK_PIPELINE_STAGE_ALL_GRAPHICS_BIT = 0x00008000,    VK_PIPELINE_STAGE_ALL_COMMANDS_BIT = 0x00010000,        (......)} VkPipelineStageFlagBits;

現(xiàn)代圖形API（如Vulkan）也包含了眾多同步對象：

1、Subpass依賴、Pipeline Barrier、Event等，用于單個Queue內(nèi)的精細粒度同步。

2、Semaphore（信號）用于跨Queue的較重度的依賴關(guān)系。

管線依賴存在兩個變量：srcStage和dstStage。srcStage標明必須等待的管線階段（pipeline stage），dstStage標明在處理開始之前必須等待同步的管線階段。

為了更好的并行效率和更少的管線氣泡，srcStage越早越好，而dstStage越遲越好。如果srcStage是VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT時，將獲得最差的性能。

Semaphore可以使用pWaitDstStages指定具體的階段。

更具體地說，遵循以下準則，可以獲得更好的渲染效率：

1、srcStageMask被設(shè)置得越早越好。

2、dstStageMask被設(shè)置得越晚越好。

3、檢查依賴關(guān)系是向前的（比如srcStageMask是頂點或計算，dstStageMask是片元）還是向后的（如srcStageMask是片元，dstStageMask是頂點或計算）。 盡量減少使用向后依賴關(guān)系。

4、如果確實需要向后依賴，則在生成和消費資源之間添加足夠的延遲，以便隱藏向后依賴引起的調(diào)度氣泡。

5、使用srcStageMask = ALL_GRAPHICS_BIT 和 dstStageMask = FRAGMENT_SHADER_BIT 彼此同步兩個渲染通道。

6、零拷貝（Zero-copy）算法是最有效的，因此盡量減少TRANSFER拷貝操作的使用。密切關(guān)注TRANSFER副本對硬件流水線的影響。

7、只在需要時使用隊列內(nèi)屏障（intra-queue barrier），并在屏障之間盡可能多地安排工作。

8、不要讓硬件處于空閑狀態(tài)。

9、不要忘記重疊頂點/計算和片元之間的處理。

10、不要使用下面的srcStageMask到dstStageMask同步組合，因為它們會完全耗盡管道：

BOTTOM_OF_PIPE_BIT to TOP_OF_PIPE_BITALL_GRAPHICS_BIT to ALL_GRAPHICS_BITALL_COMMANDS_BIT to ALL_COMMANDS_BIT

11、如果合并管道屏障，請注意不要引入錯誤的依賴項。確保不打破頂點/片元重疊，并創(chuàng)建一個不必要的氣泡。

12、不要使用VkEvent信號并立即等待該事件，用vkCmdPipelineBarrier()。

13、不要在單個Queue中使用VkSemaphore進行依賴管理。

14、不要讓渲染管線留有太大的空閑（否則降低性能），也不要讓渲染管線留有太小的空閑（否則可能產(chǎn)生錯誤）。

• 正確處理管線資源。

OpenGL ES為應(yīng)用開發(fā)人員提供了一個同步呈現(xiàn)模型，即使底層的執(zhí)行可能是異步的，必須反映數(shù)據(jù)資源在繪制調(diào)用時的狀態(tài)。如果一個應(yīng)用程序修改了一個資源，而一個掛起的draw調(diào)用仍在引用它，那么驅(qū)動程序必須采取規(guī)避操作來確保正確性。

驅(qū)動程序處理這些資源的同步行為時因GPU廠商而異，例如Mali驅(qū)動程序避免了阻塞和等待資源引用計數(shù)達到零，因為這樣做會耗盡管道并導(dǎo)致性能低下。Mali GPU會創(chuàng)建一個全新版本的資源，資源的舊版本或幽靈（Ghost）版本將一直保留，直到掛起的繪制調(diào)用完成，其引用計數(shù)降至零。其它一些驅(qū)動程序（如PowerVR）會卡住本幀的渲染管線，延遲到下一幀處理，引發(fā)性能下降。

這種行為開銷大，需要為新資源分配內(nèi)存，并在完成時清理空資源。如果更新不是完全替換，還需要從舊的資源緩沖區(qū)復(fù)制到新的資源緩沖區(qū)。

為了優(yōu)化資源，需要遵循以下建議：

1、避免修改已入隊的draw call引用的資源，可以使用N-buffered資源，并通過管道進行動態(tài)資源更新。

2、使用GL_MAP_UNSYNCHRONIZED標記，以允許使用glMapBufferRange()來補齊緩沖區(qū)中仍被動態(tài)繪制調(diào)用引用的未引用區(qū)域。不要將GL_MAP_INVALIDATE_BUFFER /GL_MAP_INVALIDATE_RANGE與glMapBufferRange()一起使用，因為這些標志在某些版本的驅(qū)動會觸發(fā)創(chuàng)建一個不必要的資源拷貝。

• 高效地上傳紋理資源。

上傳紋理資源到到圖形硬件時，對于非壓縮紋理，按線性的掃描線上傳，對于壓縮的紋理，將會逐塊上傳。

部分GPU內(nèi)部（如PowerVR）使用獨特的布局來改善內(nèi)存訪問局部性和提高緩存效率。數(shù)據(jù)的重新格式化是由專用硬件在芯片上完成的，因此非常快。如果能遵循以下步驟更能提升性能：

1、在非性能關(guān)鍵時期上傳紋理，如初始化。有助于避免與紋理加載相關(guān)的幀率下降。

2、避免上傳幀期間（mid-frame）的紋理數(shù)據(jù)到已經(jīng)用于該幀的紋理對象。

3、在紋理上傳完成后執(zhí)行一個預(yù)熱（warm-up）步驟。依然是有助于避免與紋理加載相關(guān)的幀率下降。

前面提到的預(yù)熱（warm-up）步驟可以確保紋理立即完全上傳。默認情況下，glTexImage2D不會立即執(zhí)行上傳所需的所有處理，紋理是在第一次使用時完全上傳的。可以通過在屏幕上畫出一系列三角形或用有問題的紋理對象進行綁定處理來強制上傳。

12.6.1.3 帶寬優(yōu)化

• 注意數(shù)據(jù)的存放位置。如：RAM、VRAM、Tile Buffer、GPU Cache，減少不必要的數(shù)據(jù)傳輸。
• 關(guān)注數(shù)據(jù)的訪問類型。如：是只讀還是只寫操作，是否需要原子操作，是否需要緩存一致性。
• 關(guān)注緩存數(shù)據(jù)的可行性，硬件可以緩存數(shù)據(jù)以供GPU后續(xù)操作快速訪問。可以通過以下幾點提升緩存命中率：
  • 提高傳輸速度，確保客戶端頂點數(shù)據(jù)緩沖區(qū)被用于盡可能少的繪制調(diào)用。理想情況下，應(yīng)用程序永遠不應(yīng)該使用它們。
  • 減少GPU在執(zhí)行調(diào)度或繪制調(diào)用時需要訪問的數(shù)據(jù)量。這樣可以讓盡量多的數(shù)據(jù)放到緩存行，提升命中率。
• 使用紋理壓縮格式。優(yōu)先ASTC，其次是ETC、PVRTC、BC等壓縮格式。GPU的硬件通常都支持這類壓縮格式，可以快速地編解碼它們，并且可以一次性讀取更多的紋素內(nèi)容到GPU的緩存行，提升緩存命中率。
• 使用位數(shù)更少的像素格式。如RGB565比RGB888少8位，ASTC_6X6代替ASTC_4x4等。Adreno支持的像素格式參見Spec Sheets。
• 使用半精度（如FP16）取代高精度（FP32）數(shù)據(jù)。如模型頂點和索引數(shù)據(jù)，并且可以使用SOA（Structure of Array）數(shù)據(jù)布局，而不用AOS。
• 降分辨率渲染，后期再放大。可以減少帶寬、計算量，減少設(shè)備熱發(fā)熱量。
• 盡量減少繪制次數(shù)。繪制數(shù)量的減少可以減少CPU和GPU之間、GPU內(nèi)部的帶寬和消耗。
• 確保數(shù)據(jù)存儲在On-Chip內(nèi)。

利用PLS、Subpass的特性，可以實現(xiàn)移動端的延遲渲染、粒子軟混合等。下表是PowerVR GX6250在實現(xiàn)延遲渲染時，使用不同的位數(shù)和性能的關(guān)系：

以上可知，當(dāng)位數(shù)大于256，超過GX6250的最大位數(shù)，數(shù)據(jù)無法完全存儲在On-Chip內(nèi)，會外溢到全局內(nèi)存，導(dǎo)致每幀時間暴增10ms，增幅為34.5%。

因此，對每像素的數(shù)據(jù)進行精心的組裝、優(yōu)化和壓縮，保持數(shù)據(jù)能夠完全容納于On-Chip內(nèi)，可有效提升性能，節(jié)省帶寬。

• 避免多余的副本。

確保使用相同內(nèi)存的硬件組件（CPU、圖形核心、攝像機接口和視頻解碼器等）都訪問相同的數(shù)據(jù)，而不需要進行任何中間復(fù)制。

• 使用正確的標記創(chuàng)建Buffer、紋理等內(nèi)存。部分Mali GPU（如Bifrost）執(zhí)行以下幾個標記組合：

1、DEVICE_LOCAL_BIT | HOST_VISIBLE_BIT | HOST_COHERENT_BIT

2、DEVICE_LOCAL_BIT | HOST_VISIBLE_BIT | HOST_CACHED_BIT

3、DEVICE_LOCAL_BIT | HOST_VISIBLE_BIT | HOST_COHERENT_BIT | HOST_CACHED_BIT

4、DEVICE_LOCAL_BIT | LAZILY_ALLOCATED_BIT

其中HOST_VISIBLE_BIT | HOST_COHERENT_BIT | HOST_CACHED_BIT的內(nèi)存類型說明如下：

1、提供CPU上的緩存存儲，與內(nèi)存的GPU視圖一致，無需手動同步。

2、如果芯片組支持CPU與GPU之間的硬件一致性協(xié)議，則該GPU支持此標記組合。

3、由于硬件的一致性，它避免了手動同步操作的開銷。當(dāng)可用時，緩存的、一致的內(nèi)存優(yōu)先于緩存的、不一致的內(nèi)存類型。

4、必須用于CPU上的應(yīng)用軟件映射和讀取的資源。

5、硬件一致性的功耗很小，所以不能用于CPU上只寫的資源。對于只寫資源，通過使用Not Cached，一致內(nèi)存類型繞過CPU緩存。

關(guān)于LAZILY_ALLOCATED內(nèi)存類型說明：

1、是一種特殊的內(nèi)存類型，最初只支持GPU虛擬地址空間，而不是物理內(nèi)存頁面。如果訪問內(nèi)存，則根據(jù)需要分配物理頁。

2、必須與使用VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT創(chuàng)建的瞬態(tài)attachment一起使用。瞬態(tài)Image的目的是用作幀緩沖attachment，只存在于一個單一的渲染過程中，可以避免使用物理內(nèi)存。

3、不能將數(shù)據(jù)寫回全局內(nèi)存。

以下是Vulkan內(nèi)存標記的使用建議：

1、對于不可變資源，使用HOST_VISIBLE | HOST_COHERENT內(nèi)存。

2、對于CPU上只寫的資源，使用HOST_VISIBLE | HOST_COHERENT內(nèi)存。

3、使用memcpy()將更新寫入HOST_VISIBLE | HOST_COHERENT內(nèi)存，或者按順序?qū)懭胍垣@得CPU write-combine單元的最佳效率。

4、使用HOST_VISIBLE | HOST_COHERENT | HOST_CACHED內(nèi)存用于將資源讀回CPU，如果此組合不可以，則使用HOST_VISIBLE | HOST_CACHED。

5、使用LAZILY_ALLOCATED內(nèi)存用于僅在單個渲染過程中存在的臨時幀緩沖區(qū)附件。

6、只將LAZILY_ALLOCATED內(nèi)存用于TRANSIENT_ATTACHMENT幀緩沖區(qū)附件。

7、映射和取消映射緩沖區(qū)消耗CPU性能。因此要持久地映射經(jīng)常被訪問的緩沖區(qū)，例如：統(tǒng)一緩沖區(qū)、數(shù)據(jù)緩沖區(qū)或動態(tài)頂點數(shù)據(jù)緩沖區(qū)。

• 盡量使用零拷貝（Zero-Copy）路徑。

如下圖所示，通過使用EglImage實現(xiàn)Camera和OpenCL共享Original Image Data，OpenCL和OpenGL ES共享Final Image Data，從而達到零拷貝：

• 將內(nèi)存訪問分組。

編譯器使用幾種啟發(fā)式方法，可以識別內(nèi)核中的內(nèi)存訪問模式，這些模式可以組合成讀或?qū)懖僮鞯耐话l(fā)傳輸。為了讓編譯器更好實現(xiàn)這種優(yōu)化，內(nèi)存訪問應(yīng)該盡可能緊密地組合在一起。

例如，將讀放在內(nèi)核的開頭，寫放在內(nèi)核的結(jié)尾，可以獲得最佳的效率。對更大的數(shù)據(jù)類型(如向量)的訪問也會盡可能地編譯為單個傳輸，加載1個float4比加載4個多帶帶的float值更好。

• 合理使用Shared/Local內(nèi)存。

可以在Shader初期（如初始化），將常訪問的數(shù)據(jù)先讀取到Shared/Local內(nèi)存，提升訪問速度。

• 以行優(yōu)先（Row-Major）的順序訪問內(nèi)存。

GPU通常會預(yù)讀取行相鄰的數(shù)據(jù)到GPU緩存中，如果著色器算法以行優(yōu)先的方式訪問，可以提升Cache命中率，降低帶寬。

• GPU特定帶寬優(yōu)化。

Mali的Transaction%20elimination只有在以下情形適用：

1、采樣數(shù)據(jù)為1。

2、mimap級別為1。

3、image使用了COLOR_ATTACHMENT_BIT。

4、image沒有使用TRANSIENT_ATTACHMENT_BIT。

5、使用單一顏色附件。（Mali-G51%20GPU及之后沒有此限制）

6、有效的tile尺寸是16x16像素，像素數(shù)據(jù)存儲決定了有效的tile尺寸。

Mali%20GPU還支持AFBC紋理，可以減少顯存和帶寬。

GL_BYTEGL_UNSIGNED_BYTEGL_SHORTGL_UNSIGNED_SHORTGL_FIXEDGL_FLOATGL_HALF_FLOATGL_INT_2_10_10_10_REVGL_UNSIGNED_INT_2_10_10_10_REV

int4 ResultOfA(int4 a) {    return a + 1; // int4和int相加, 只需要1條指令.}int4 ResultOfA(int4 a) {    return a + 1.0; // int4和float相加, 需要3條指令: int4 -> float4 -> 相加 -> int4}

uniform sampler2D ColorTexture;in vec2 TexC;vec3 light(in vec3 amb, in vec3 diff){    // 紋理采樣返回vec4, 會隱性轉(zhuǎn)換成vec3, 多出1條指令.    vec3 Color = texture(ColorTexture, TexC);     Color *= diff + amb;    return Color;}// 以下代碼中, 輸入?yún)?shù)/臨時變量/返回值都是vec4, 沒有隱性類型轉(zhuǎn)換, 比上面代碼少1條指令.uniform sampler2D ColorTexture;in vec2 TexC;vec4 light(in vec4 amb, in vec4 diff){    vec4 Color = texture(Color, TexC);    Color *= diff + amb;    return Color;}

float scale, bias;  // 兩個float值.vec4 a = Pos * scale + bias; // 需要兩條指令.vec2 scaleNbias; // 將兩個float值打包成一個vec2vec4 a = Pos * scaleNbias.x + scaleNbias.y; // 一條指令(mad)完成.

highp vec4 v1, v2;highp float x, y;// Bad!!v2 = (v1 * x) * y; // vector*scalar接著vector*scalar總共8個標量muladd.// Good!!v2 = v1 * (x * y); // scalar*scalar接著vector*scalar總共5個標量muladd.

precision mediump float;#ifdef GL_FRAGMENT_PRECISION_HIGH    #define NEED_HIGHP highp#else    #define NEED_HIGHP mediump#endif        varying vec2 vSmallTexCoord;varying NEED_HIGHP vec2 vLargeTexCoord;