最大限度地利用 WebGL2 而不使其过载

Question

我的 Web 应用程序进行了很长时间的计算，然后显示结果。 我正在使用 WebGL2 进行计算 - 绘制到屏幕外的 2D 纹理中。 我不能简单地在单个 WegGL 调用中完成它 - 计算将花费太长时间并导致“丢失上下文”错误。 所以我将计算分成矩形部分，每个部分都可以在短时间内绘制。

问题在于调度这些 WebGL 调用。 如果我经常这样做，浏览器可能会变得无响应或带走我的 WebGL 上下文。 如果我不经常这样做，计算将花费比必要时间更长的时间。 我知道偶尔丢失上下文是正常的，我害怕系统地丢失它，因为我使用 GPU 太多了。

我能想到的最好的办法是有一些工作与睡眠的比率，并在我用于计算的一小部分时间内睡眠。 我想我可以使用 WebGL2 同步对象来等待发出的调用完成并粗略估计它们花费了多少时间。 像这样：

var workSleepRatio = 0.5; // some value
var waitPeriod = 5;
var sync;
var startTime;

function makeSomeWebglCalls() {
    startTime = performance.now();
    sync = gl.fenceSync(gl.SYNC_GPU_COMMANDS_COMPLETE, 0);
    for (<estimate how many rectangles we can do so as not to waste too much time on waiting>) {
        gl.drawArrays(); // draw next small rectangle
    }
    setTimeout(timerCb, waitPeriod);
}

function timerCb() {
    var status = gl.getSyncParameter(sync, gl.SYNC_STATUS);
    if (status != gl.SIGNALED) {
        setTimeout(timerCb, waitPeriod);
    } else {
        gl.deleteSync(sync);
        
        var workTime = performance.now() - startTime;
        setTimeout(makeSomeWebglCalls, Math.min(1000, workTime * workSleepRatio));
    }
}

makeSomeWebglCalls();

这种方法不是很好，它有以下问题：

• 不知道将 workSleepRatio 设置为什么。
• 在 GPU 工作完成和我的计时器回调之间浪费了时间。 不能依赖 gl.clientWaitSync 因为它的超时参数在许多浏览器中被限制为零，即使在 Web Worker 线程中也是如此。
• 无论我将 workSleepRatio 设置得多大，我仍然无法确定浏览器不会认为我做得太多并带走了 WebGL 上下文。 也许 requestAnimationFrame 可以在被节流时以某种方式用于减慢速度，但是用户在等待计算完成时无法切换选项卡。
• setTimeout 可能会受到浏览器的限制，并且比请求的睡眠时间更长。

所以，简而言之，我有以下问题：

• 如何使用 WebGL 既不超载又不浪费时间？ 这甚至可能吗？
• 如果不可能，那么有没有更好的方法来处理这个问题？

Answer 1

您可以使用EXT_disjoint_timer_query_webgl2吗？

 function main() { const gl = document.createElement('canvas').getContext('webgl2', { powerPreference: 'high-performance', }); log(`powerPreference: ${gl.getContextAttributes().powerPreference}\\n\\n`); if (!gl) { log('need WebGL2'); return; } const ext = gl.getExtension('EXT_disjoint_timer_query_webgl2'); if (!ext) { log('need EXT_disjoint_timer_query_webgl2'); return; } const vs = `#version 300 es in vec4 position; void main() { gl_Position = position; } `; const fs = `#version 300 es precision highp float; uniform sampler2D tex; out vec4 fragColor; void main() { const int across = 100; const int up = 100; vec2 size = vec2(textureSize(tex, 0)); vec4 sum = vec4(0); for (int y = 0; y < up; ++y) { for (int x = 0; x < across; ++x) { vec2 start = gl_FragCoord.xy + vec2(x, y); vec2 uv = (mod(start, size) + 0.5) / size; uv = texture(tex, uv).xy; uv = texture(tex, uv).xy; uv = texture(tex, uv).xy; uv = texture(tex, uv).xy; uv = texture(tex, uv).xy; uv = texture(tex, uv).xy; uv = texture(tex, uv).xy; sum += texture(tex, uv); } } fragColor = sum / float(across * up); } `; const programInfo = twgl.createProgramInfo(gl, [vs, fs]); const bufferInfo = twgl.primitives.createXYQuadBufferInfo(gl); const pixels = new Uint8Array(1024 * 1024 * 4); for (let i = 0; i < pixels.length; ++i) { pixels[i] = Math.random() * 256; } // creates a 1024x1024 RGBA texture. const tex = twgl.createTexture(gl, {src: pixels}); gl.useProgram(programInfo.program); twgl.setBuffersAndAttributes(gl, programInfo, bufferInfo); const waitFrame = _ => new Promise(resolve => requestAnimationFrame(resolve)); const widthHeightFromIndex = i => { const height = 2 ** (i / 2 | 0); const width = height * (i % 2 + 1); return { width, height }; }; async function getSizeThatRunsUnderLimit(gl, limitMs) { log('size time in milliseconds'); log('--------------------------------'); for (let i = 0; i < 32; ++i) { const {width, height} = widthHeightFromIndex(i); const timeElapsedMs = await getTimeMsForSize(gl, width, height); const dims = `${width}x${height}`; log(`${dims.padEnd(11)} ${timeElapsedMs.toFixed(1).padStart(6)}`); if (timeElapsedMs > limitMs) { return widthHeightFromIndex(i - 1); } } } (async () => { const limit = 1000 / 20; const {width, height} = await getSizeThatRunsUnderLimit(gl, limit); log('--------------------------------'); log(`use ${width}x${height}`); })(); async function getTimeMsForSize(gl, width, height) { gl.canvas.width = width; gl.canvas.height = height; gl.viewport(0, 0, width, height); // prime the GPU/driver // this is voodoo but if I don't do this // all the numbers come out bad. Even with // this the first test seems to fail with // a large number intermittently gl.drawElements(gl.TRIANGLES, 6, gl.UNSIGNED_SHORT, 0); for (;;) { const query = gl.createQuery(); gl.beginQuery(ext.TIME_ELAPSED_EXT, query); gl.drawElements(gl.TRIANGLES, 6, gl.UNSIGNED_SHORT, 0); gl.endQuery(ext.TIME_ELAPSED_EXT); gl.flush(); for (;;) { await waitFrame(); const available = gl.getQueryParameter(query, gl.QUERY_RESULT_AVAILABLE); if (available) { break; } } const disjoint = gl.getParameter(ext.GPU_DISJOINT_EXT); if (!disjoint) { const timeElapsed = gl.getQueryParameter(query, gl.QUERY_RESULT); gl.deleteQuery(query); return timeElapsed / (10 ** 6); // return milliseconds } gl.deleteQuery(query); } } } main(); function log(...args) { const elem = document.createElement('pre'); elem.textContent = args.join(' '); document.body.appendChild(elem); }

 pre { margin: 0; }

 <script src="https://twgljs.org/dist/4.x/twgl-full.min.js"></script>

在我的 2014 Macbook Pro Dual GPU（Intel/Nvidia）上，首先，即使我要求高性能 Chrome 给我低功耗，这意味着它使用的是 Intel 集成 GPU。

1x1 像素上的第一个计时通常是约 17 毫秒间歇性的，通常但并非总是如此。 我不知道如何解决这个问题。 我可以保持计时，直到 1x1 像素是一些更合理的数字，比如时间 5 次，直到它 < 1 毫秒，如果永远不会失败？

powerPreference: low-power

size        time in milliseconds
--------------------------------
1x1           16.1
2x1            0.0
2x2            0.0
4x2            0.0
4x4            0.0
8x4            0.1
8x8            0.1
16x8           0.0
16x16          0.0
32x16          0.0
32x32          0.0
64x32         13.6
64x64         35.7
128x64        62.6
--------------------------------
use 64x64

在配备英特尔集成 GPU 的 2018 年末 Macbook Air 上进行的测试显示了类似的问题，除了第一个时间在 42 毫秒时更糟。

size        time in milliseconds
--------------------------------
1x1           42.4
2x1            0.0
2x2            0.0
4x2            0.0
4x4            0.0
8x4            0.0
8x8            0.0
16x8           0.0
16x16          0.0
32x16          0.0
32x32          0.0
64x32          0.0
64x64         51.5
--------------------------------
use 64x32

此外，时间安排有点虚假。 注意我的 2014 MBP，32x32 是 0ms，64x32 突然变成 13ms。 我希望 32x32 为 6.5 毫秒。 上面的MBA也是一样，一切都是0然后突然51ms！？？！？？

在带有 Nvidia RTX 2070 的 Windows 10 桌面上运行它似乎更合理。 1x1 时序是正确的，时序按预期增长。

powerPreference: low-power

size        time in milliseconds
--------------------------------
1x1            0.0
2x1            0.0
2x2            0.0
4x2            0.0
4x4            0.0
8x4            0.0
8x8            0.0
16x8           0.0
16x16          0.0
32x16          0.1
32x32          0.1
64x32          2.4
64x64          2.9
128x64         3.1
128x128        6.0
256x128       15.4
256x256       27.8
512x256       58.6
--------------------------------
use 256x256

此外，在所有系统上，如果我没有在计时失败之前预先绘制每个尺寸并且所有计时都出现 > 16 毫秒。 添加预绘图似乎有效，但它是巫术。 我什至尝试预绘制 1x1 像素而不是宽度乘高度像素作为预绘制，但失败了！？！？！？

此外，Firefox 不支持 EXT_disjoint_timer_query_webgl2 我相信这是因为精确计时可以从其他进程窃取信息。 Chrome 通过站点隔离修复了这个问题，但我猜 Firefox 还没有做到这一点。

注意：WebGL1 具有用于类似功能的EXT_disjoint_timer_query 。

更新：英特尔 GPU 上的问题可能与模糊时间以避免安全问题有关？ Intel GPU 使用统一内存（意味着它们与 CPU 共享内存）。 我不知道。 chrome 安全文章提到降低具有统一内存的设备的精度。

我想即使没有时间扩展，您也可以通过检查 requestAnimationFrame 时间来尝试查看是否可以在 60hz 以下渲染。 不幸的是，我的经验也是它可能是片状的。 任何事情都可能导致 rAF 超过 60fps。 也许用户正在运行其他应用程序。 也许他们在 30hz 的显示器上。 等等...也许在一定数量的帧上平均时间或取多个时间的最低读数。