NEW 257644
GPUP WebGL flush() and finish() are asynchronous
https://bugs.webkit.org/show_bug.cgi?id=257644
Summary GPUP WebGL flush() and finish() are asynchronous
Kimmo Kinnunen
Reported 2023-06-02 04:36:06 PDT
GPUP WebGL flush() and finish() are asynchronous Should be synchronous
Attachments
Radar WebKit Bug Importer
Comment 1 2023-06-02 04:38:12 PDT
Kimmo Kinnunen
Comment 2 2023-06-02 04:39:45 PDT
Kimmo Kinnunen
Comment 3 2023-06-02 04:42:35 PDT
Blocks bug 252876 for benchmarking before/after read pixels perf
Kenneth Russell
Comment 4 2023-06-02 09:48:05 PDT
The side-effects of flush() and finish() can't be observed by application code in the WebGL context. Even with finish(), there's a WebGL spec difference compared to OpenGL ES that the status of objects like queries can't change unless control is returned to the browser. For this reason it should be safe to leave these asynchronous, and I think WebKit might incur a performance penalty compared to other implementations by making them synchronous. If it's necessary to use these for synchronization with other subsystems in WebKit like the media stack, I'd suggest adding another internal primitive that can't be called by the web platform - Chromium does this.
Kimmo Kinnunen
Comment 5 2023-06-02 09:51:06 PDT
Think Chrome's implementation is also synchronous, e.g. the call between renderer and GPU process. I think previously we discussed wrt "real finish vs gl.finish as gl.flush()", which cannot be observed.
Kimmo Kinnunen
Comment 6 2023-06-02 09:52:20 PDT
Or, maybe not maybe it is indeed async?
Kimmo Kinnunen
Comment 8 2023-06-05 04:18:19 PDT
> However, the WebGL implementation never calls the underlying Finish, only Flush: Ah, right! I keep on forgetting.
Note You need to log in before you can comment on or make changes to this bug.