[Webkit-unassigned] [Bug 239015] REGRESSION (Safari 15.4) Crash uploading WebGL buffers

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Apr 20 10:56:43 PDT 2022


https://bugs.webkit.org/show_bug.cgi?id=239015

--- Comment #6 from Philip Taylor <philip.taylor at zea.live> ---

Thanks Ken. I'd like to update this issue.

The issues is not specific to iOS. What seems to be happening is a severe performance regression, that looks like a crash in Safari as our renderer gets stuck iterating through a lot of draw calls. 

We store Geometries in one large buffer, and we update this buffer as we stream in geometries. Depending on the order that our workers finish parsing geoms, the _number_ of buffer updates may change.

It seems like if we touch the same geom buffer twice, subsequent calls to drawElements are incredibly slow.

First we allocate our large buffers. (Resizing each time by powers of 2)

Then upload our geometries into these buffers using..

```

gl.bufferSubData(gl.ARRAY_BUFFER, dstByteOffsetInBytes, attrData.values)

```

```

gl.bufferSubData(gl.ELEMENT_ARRAY_BUFFER, dstByteOffsetInBytes, offsettedIndices)

```

Then we draw in large batches.

```
      if (gl.multiDrawElements) {
        gl.multiDrawElements(gl.TRIANGLES, counts, 0, gl.UNSIGNED_INT, offsets, 0, drawCount)
      } else {
        const { geomItemId } = renderstate.unifs
        for (let i = 0; i < drawCount; i++) {
          gl.uniform1i(geomItemId.location, drawIds[i])
          gl.drawElements(gl.TRIANGLES, counts[i], gl.UNSIGNED_INT, offsets[i])
        }
      }
```

Something must change after our calls to bufferSubData that then makes drawElements unusably slow. 

Note: We do have a code path for multi-draw, which is currently disabled on Safari due to another regression. This performance issue may have existed before, but we didn't notice it, because we didn't use this code path, as it was a fallback.


We spent today debugging this issue in Safari on an M1 macbook pro. The issue is not only on iOS.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20220420/349d8b15/attachment.htm>


More information about the webkit-unassigned mailing list