Draw Call Batch與亂序光柵化
MSDN / Direct3D 9 / Accurately Profiling Direct3D API Calls
https://docs.microsoft.com/en-us/windows/desktop/direct3d9/accurately-profiling-direct3d-api-calls
一般認為 Draw Call Batch是為了解決 CPU瓶頸。 MSDN上的 Direct3D9文件中對此進行了相關的討論。
但實際上， Draw Call Batch還可以提高 GPU繪製三角形時的並行度，在某種程度上還可以解決 GPU瓶頸。
我們知道 GPU在本質上是一個並行的系統，比如，“不同 Fragment Shader之間不具有任何依賴”可以認為是 GPU並行性的一個典型代表；但是由於應用層的某些邏輯的需要，導致了 GPU在一定程度上具有序列性。
比如，經典的繪製透明物體的演算法需要在應用層將物體從前到後或從後到前排序，並依次呼叫 Draw Call，這意味著“在結果上” GPU繪製三角形的順序應當與應用層呼叫 Draw Call的順序一致。
我們之所以強調“在結果上”是因為：在實際實現中， GPU仍並行地繪製三角形，只不過在輸出結果前進行了相關的處理來保證 Draw Call靠後的三角形一定覆蓋 Draw Call靠前的三角形。
"Real Time Rendering Fourth Edition Chapter 23 Graphics Hardware Section 9 Architecture"中對 GPU處理三角形時所進行的排序進行了詳細的討論。
顯然同一個 Draw Call中的三角形不需要排序（應用層的邏輯不關心它們的繪製順序），因此 Draw Call Batch可以提高 GPU的並行度，從而可以在某種程度上解決 GPU瓶頸。
Matthaeus Chajdas. "Unlock the Rasterizer with Out-of-Order Rasterization." AMD GPUOpen 2016.
https://gpuopen.com/unlock-the-rasterizer-with-out-of-order-rasterization/
AMD最近給出了一個亂序光柵化的 Vulkan擴充套件，試圖通過摒棄排序的方式來提升 GPU的並行度。
//AMD的亂序光柵化擴充套件說明了 OIT（順序無關透明）的重要性，是時候啟用一波 OIT演算法了（ http://research.nvidia.com/publication/phenomenological-scattering-model-order-independent-transparency ） 233333333
但是，通過摒棄排序來提升 GPU並行度的方式貌似只適用於 Sort-Last Fragment架構的 PC平臺的 GPU； Sort-Middle Tiled架構的 Mobile平臺的 GPU在 Fragment Shader之前進行排序，並通過 FPK(Forward Pixel Kill)的方式對 Fragment Shader的執行次數進行優化，想要摒棄排序貌似是不大可能的。