以毫秒爲單位測量WebGL紋理負載

現在我有一個圖像陣列，將使用遊戲循環渲染爲地圖，並且我感興趣的是捕獲WebGL以毫秒爲單位加載每個紋理圖像所需的時間。我想知道如何做到這一點，因爲JavaScript與WebGL不同步。

2015-04-23 Frixzon

這對您有何幫助？你會檢查機器和驅動程序的百萬變化嗎？例如，在運行Android 5.0.1和5.0.2的Nexus 5上運行不同操作系統的Samung Galaxy Note 6與在每個操作系統上運行不同操作系統和iPhone，iPad的每種型號，以及每種Mac型號的Mac上，紋理需要多長時間操作系統，然後所有不同的CPU，不同的gpus，不同的驅動程序等各種Windows機器...... 我問，因爲無論你想解決什麼問題，它不清楚如何測量上機時間在一臺機器上將有助於 – gman

它是我做的一項研究工作。我需要來自我已經構建的webgl測試應用程序的那種數據。 – Frixzon

你還沒有回答我的問題。這些數據有什麼意義？如果您獲得1ms的回答，那麼它將如何幫助您，因爲這對其他機器無用，而且JavaScript無法找出用戶使用何種機器。 – gman

測量WebGL中任何時間的唯一方法是找出在一定的時間內您可以完成多少工作。選擇一個目標速度，比如說30fps，使用requestAnimationFrame，繼續增加工作直到你完成目標。

var targetSpeed = 1/30; 
var amountOfWork = 1; 

var then = 0; 
function test(time) { 
    time *= 0.001; // because I like seconds 

    var deltaTime = time - then; 
    then = time; 

    if (deltaTime < targetTime) { 
    amountOfWork += 1; 
    } 

    for (var ii = 0; ii < amountOfWork; ++ii) { 
    doWork(); 
    } 

    requestAnimationFrame(test); 
} 
requestAnimationFrame(test);

它沒有那麼簡單，因爲瀏覽器，以我的經驗，至少，似乎不是給了幀真正穩定時間。

注意事項

不要以爲requestAnimationFrame將在60fps。

有很多設備運行速度更快（VR）或更慢（低端高清dpi顯示器）。
不要測量時間開始發射命令，直到時間停止

測量自上次requestAnimationFrame的時間。 WebGL只需將命令插入緩衝區。這些命令甚至可能在另一個進程中執行的驅動程序所以
```
var start = performance.now;   // WRONG! 
gl.someCommand(...);     // WRONG! 
gl.flush(...);      // WRONG! 
var time = performance.now - start; // WRONG! 
```
實際使用的資源。

許多資源被懶惰地初始化，所以只要上傳資源但不使用它不會給你一個準確的測量。你需要實際上對你上傳的每個紋理進行繪製。當然使它小1像素1個三角形繪製，用一個簡單的着色器。着色器必須實際訪問資源，否則驅動程序我不做任何惰性初始化。
不要假設不同類型/尺寸的紋理會有比例速度的變化。

司機對不同的事情。例如，一些GPU可能不支持，但RGBA紋理。如果您上傳LUMINANCE紋理，則驅動程序將將其展開爲RGBA。所以，如果你使用定時RGBA紋理並承擔相同尺寸的亮度質地會上傳 4倍快你就錯了

同樣不承擔不同大小的紋理將在速度成正比，它們的大小上傳。驅動程序和其他限制的內部緩衝區意味着差異大小可能會採用不同的路徑路徑。

換句話說，你不能假設1024x1024紋理將上傳 4x緩慢如512x512紋理。
要知道即使這樣也不能保證實際結果

我的意思是，例如，如果你在瓷磚的硬件（iPhone 例如），那麼GPU的工作方式是收集所有繪圖命令，將它們分隔成瓦片，剔除任何看不見的繪圖，並且只畫出大部分桌面GPU繪製每個三角形的每個像素的剩餘部分。

由於瓷磚GPU 在年底做的一切意味着，如果你繼續上傳數據相同的紋理和各間繪製上傳它將必須保持所有紋理的副本，直到它吸引。在內部，可能會出現一些衝突點，並且在再次緩衝之前繪製其內容。

即使一個桌面驅動程序想要流水上傳，所以你上傳內容到紋理B，繪製，上傳新內容到紋理B，繪製。如果驅動程序正在執行第一個繪圖的過程中，它不想等待GPU，因此它可以替換內容。相反，它只是想將新內容上傳到其他地方未被使用，然後它可以將紋理指向新的內容。

在正常使用中，這不是問題，因爲幾乎沒有人一直上傳噸的紋理。他們至多上傳1或2個視頻幀或1或2個程序化生成的紋理。但是，如果你是基準測試，你會強調驅動程序並將其做成它實際上不會正常運行。在上面的例子中，可能假設一個紋理不太可能上傳10000幀你會達到一個極限，它必須凍結管道，直到你的一些排隊紋理被繪製。該凍結將使您的結果看起來比您在正常的用例中得到的要慢。

問題的關鍵是，你可能會基準並獲得告訴它需要5ms的上傳質感但實際上只需要3毫秒，你只是停滯管道很多次，你的基準外面是不太可能發生。

來源

2015-04-28 09:57:00 gman

以毫秒爲單位測量WebGL紋理負載

回答

相關問題