延遲渲染的主要優點是它允許片段着色器僅執行numLights * numPixels次。這是因爲在正向渲染中，同一像素多次渲染兩次。但是，如果在片段着色器之前和幾何着色器之後執行了深度剔除或z-culling，那麼這會導致它與延遲渲染一樣高效，並且不需要較大的G-Buffer。我相信在OpenGL的新版本中可以做到這一點，那麼爲什麼沒有人這樣做呢？請告訴我，我的想法是否有錯誤。延遲渲染與預片段着色器深度剔除
注意：也許這不是一個正確的問題，但我不知道我可以在哪裏發佈這個。
但是，如果有什麼深度撲殺或z剔除被片段着色器之前和幾何着色器之後進行，這會導致它被作爲efficent作爲延遲執行渲染
沒有，也不會。
由於標準的正向渲染需要爲每個燈光繪製每個模型，因此每個燈光仍然會執行一次所有的頂點處理階段。在延遲渲染中，您只繪製一次模型，這樣可以節省頂點處理時間。
這很重要，因爲很多現代硬件都使用所謂的「統一着色器架構」。這意味着硬件能夠動態分配着色器工作負載。如果渲染很多頂點，但使用短片段着色器，則可以將更多着色單元分配給VS階段。如果用一個簡單的VS渲染4個頂點，但是渲染一個複雜的FS，那麼它可以爲頂點階段分配很少的硬件，並且可以爲片段着色器分配更多的硬件。
所以在延遲渲染中，您將花費更多的可用着色處理器時間來完成有用的工作。使用正向渲染，您將在有用的FS工作和重複且無用的VS工作之間分割GPU資源。
接下來，您可能會建議使用變換反饋來捕獲渲染結果並重新渲染它們。但是現在你只是爲另一個瓶頸交易：你佔用更多的內存，並且交換VS爲內存帶寬工作。
我執行繪圖調用僅一次，所以沒有冗餘geomitries，我使用燈的陣列作爲均勻通過所有在片段着色器的光，而不是循環。
這只是換一個低效率的另一個，雖然這通常更快（但不太靈活）。不必每次都渲染一個網格，而是對非必須可見的碎片進行非常耗時的FS調用。
Early depth tests不保證任何東西。硬件不可能保證執行的每個FS調用都是可見的，因爲GPU可能還沒有對遮擋對象進行光柵化。早期的深度測試並不能確定事物的繪製順序。
確保所有FS調用都可見的唯一方法是執行深度預處理。也就是說，你渲染場景中的所有東西，但沒有片段着色器。所以唯一被更新的是深度。然後，再次使用實際着色器渲染場景。
但是，然後，你正在渲染整個場景兩次。而且着色器負載平衡可能更難，因爲整個對象正在被剔除。
您必須認識到的另一件事是延期渲染不能保證性能。它只是另一種渲染方法，具有其自身的優點和缺點。您可以創建延遲渲染比任何正向渲染變化慢的情況。您還可以創建延遲渲染速度更快的環境。雖然隨着燈光數量的增加，延遲渲染通常是最好的選擇，但總有些情況可能會使另一種渲染技術在性能上更勝一籌。
也許我的渲染過程與標準的向前渲染不同，但是我只執行一次繪製調用，所以沒有多餘的幾何圖形，而是使用燈光陣列作爲統一來代替片段着色器中的所有燈光。 – pdid
@pdid：查看我的補充內容。 –
即使有了早期的z檢驗，也會發生很多透支。示例：繪製背景中的對象1。所有像素都必須加陰影，因爲後緩衝器中沒有任何像素。如果我們現在渲染一個前景對象，它將從背景中透視像素。對於您的方法，在渲染第一個陰影片段之前，您需要完整的深度信息。 – BDL
回答你最後的筆記。還有另一個名爲[Computer Graphics]的Stack Exchange站點（https://computergraphics.stackexchange.com/）。 – Vallentin