Big buffer modification leads to framedrop.

[Ivan Popelyshev]

I use 256 megabytes webgl buffer for a multidraw optimization.
I take small buffer, upload its data from app to webgl, then use several "copyBufferSubData" operations.
When buffer is small (32, 64) its not a problem. for 128, 256 there's significant frame drop.
I tried different buffer types, currently its STATIC_COPY.

Is it normal behaviour? Do you know whats going on there?

I will separate buffer into multiple parts by 32Mb, Its possible, of course i'll have to adjust my other algorithms to make better batches if I do that.

Ivan.

[Ivan Popelyshev]

tested my app on both Chrome and Firefox, same results. Probably ANGLE-related behaviour.

пятница, 7 апреля 2023 г. в 18:52:00 UTC+3, Ivan Popelyshev:

[Ken Russell]

Does your application draw using the buffer in between the copyBufferSubData operations? If so, then ANGLE's current implementation will make multiple shadow copies of the entire 256 MB buffer. This is likely the reason for the poor performance. Do you have a relatively small test case which can be used to profile?

-Ken

--
You received this message because you are subscribed to the Google Groups "WebGL Dev List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webgl-dev-lis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/webgl-dev-list/de0826ca-7617-494e-8a50-0530810ec9c9n%40googlegroups.com.

[Ivan Popelyshev]

Thank you, Ken!

in one frame, first I do copyBuffer operations, then I use multidraw several times.

OK, I think this means I trigger those shadow copies somehow.

I'll investigate my webgl operations, and if I fail to remove that trigger i'll make small test case :)

Ivan.

пятница, 7 апреля 2023 г. в 21:51:38 UTC+3, Kenneth Russell:

[Ken Russell]

I think in that situation that only one shadow copy at most should be made, but still, copying the entire 256 MB buffer would be expensive. The reason for the shadow copy is that the current version of the buffer's data is likely still in use by the previous frame's rendering on the way to the screen, so when the buffer is mutated via copyBufferSubData, the shadow copy needs to be made. If you can provide a test case, we'd like to run native profiling tools against Chrome's GPU process.

-Ken

To view this discussion on the web visit https://groups.google.com/d/msgid/webgl-dev-list/dc1d0746-8e7f-462c-9444-995aa3639303n%40googlegroups.com.

[Ivan Popelyshev]

... I have to implement double-bufferring with fences, right? OMG, your explanation makes everything clear!

пятница, 7 апреля 2023 г. в 22:06:01 UTC+3, Kenneth Russell:

[Ken Russell]

Fences won't help in WebGL - because there's no inter-context resource sharing, semantically all previous commands have completed by the time the next one is processed. The fact that the buffer might still be in use by the GPU is an implementation detail. In Chromium, WebGL2RenderingContextBase::waitSync is deliberately a no-op, so it won't be possible to tell the implementation to wait until all previous commands are done processing.

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/webgl/webgl2_rendering_context_base.cc;l=4465?q=WebGL2RenderingContextBase::waitSync

However, yes, if you add the option to double-buffer or perhaps even triple-buffer that data in your engine, I think that will improve performance. Please tell us what you find.

To view this discussion on the web visit https://groups.google.com/d/msgid/webgl-dev-list/bbe7e223-fc56-4bb0-82a8-9ede24f15278n%40googlegroups.com.

[Ivan Popelyshev]

Idea: 2 + 1 - buffering based on  https://developer.mozilla.org/en-US/docs/Web/API/WebGL2RenderingContext/getSyncParameter
"static1" buffer is used for drawing
"static2" buffer - we are checking if it stopped drawing, if it did, we upload data from "dynamic"
"dynamic" - holds the data that is being uploaded at the moment, its small and can be copied just fine. 

Also, "dynamic" can be used for rendering to show new versions of objects even if they werent uploaded to static yet

пятница, 7 апреля 2023 г. в 23:14:34 UTC+3, Kenneth Russell:

[Ken Russell]

It looks like Chromium's implementation of glGetQueryObjectuiv in the JavaScript process is non-blocking, so hopefully this should work and the call to WebGL2RenderingContext::getSyncParameter should not stall.

To view this discussion on the web visit https://groups.google.com/d/msgid/webgl-dev-list/fa9ad5e1-afa4-454d-addd-84f421e1cbf0n%40googlegroups.com.

[Ivan Popelyshev]

2+1-buffer implementation doesnt speed up the game, im working on small testcase )

пятница, 7 апреля 2023 г. в 23:35:48 UTC+3, Kenneth Russell:

[Ivan Popelyshev]

I added proper syncs. Now my RAF has fully async lags ) I ask for 1, 2, 3, 4, 5 frames and then they arrive at the same time. Great FPS, totally worthless. Renderdoc really shows 384-megabyte buffer copy from  
regular buffer to something with flags D3D11BIND_VERTEX_BUFFER, D3D11BIND_STREAM_OUTPUT. Gonna make that minimal demo tomorrow.

среда, 12 апреля 2023 г. в 14:45:34 UTC+3, Ivan Popelyshev:

[Ken Russell]

This poor performance is disappointing to hear. Is it possible for you to share a more reduced test case that shows these problems? If so then please file a bug on crbug.com and include about:gpu from your affected system. We have just been working on the shadow copy implementation in ANGLE on macOS, but the Windows implementation is totally different.

To view this discussion on the web visit https://groups.google.com/d/msgid/webgl-dev-list/2edcc3a0-8126-41ed-a2b4-fddd4f801b61n%40googlegroups.com.

[Ivan Popelyshev]

Hello, Ken! Other bugs took my time.

I'm modifying one of C++ ANGLE examples, its time for me to debug this beautiful collection of IF's, I'll share it later this day :)

Excited to join the backend-graphics dev club,
Ivan.

вторник, 18 апреля 2023 г. в 08:02:50 UTC+3, Kenneth Russell:

[Ivan Popelyshev]

Here we go: https://bugs.chromium.org/p/chromium/issues/detail?id=1434273

вторник, 18 апреля 2023 г. в 10:36:59 UTC+3, Ivan Popelyshev:

[Ivan Popelyshev]

@Ken sorry for calling you Geoff in the issue, it was a late night :)

Current status: I found strange workaround, I know whats going wrong in ANGLE, there are ideas how to fix it.

вторник, 18 апреля 2023 г. в 15:38:11 UTC+4, Ivan Popelyshev:

[Ken Russell]

All good Ivan. Glad that we're making progress on this issue.

To view this discussion on the web visit https://groups.google.com/d/msgid/webgl-dev-list/7c5f0c9b-b1b4-4307-b052-86ad093f5c6en%40googlegroups.com.