Stalls in glCopyImageSubData when resizing picture cache texture arrays on Mali-T
Categories
(Core :: Graphics: WebRender, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox83 | --- | fixed |
People
(Reporter: jnicol, Assigned: jnicol)
References
Details
Attachments
(1 file)
The glCopyImageSubData calls when resizing picture cache textures take tens of milliseconds (40-80 typically). Presumably the driver is unable to schedule this asynchronously, and therefore must block until the previous frame's rendering to the picture cache is complete.
I can reproduce this trivially on an initial fling on a page such as mozilla.com, on a Samsung Galaxy A5 (2017) (Mali-T830)
I cannot reproduce on my Galaxy S9 (Mali-G72). However, that may not be a G vs T difference, it may be the more recent driver version, meaning that older Mali-G devices could still be affected. I'm therefore leaning towards making this change for both G and T.
On my Pixel 2 (Adreno 520), the glCopyImageSubData call also takes too long (more like 20-40ms than 40-80). However, the glBlitFramebuffer alternative isn't obviously any better on this device. And because of driver bugs we have to blit each texture layer twice (bug 1505508). Although actually I no longer see bug this on my Pixel 2, so perhaps a recent android update has fixed the driver, but of course we do have to support old android versions. So I think we should leave Adreno as is.
|
Assignee | |
Comment 1•4 years ago
|
||
On Adreno, the cost of glCopyImageSubData (or the glBlitFramebuffer to the first layer) appears to be just because it is the first call which touches the new texture. So it must be lazilly allocating the texture. The preceding glTexStorage3D call is fast. On Mali, the glTexStorage3D call takes more time, meaning the first glBlitFramebuffer is fast.
|
|
Assignee | |
Comment 2•4 years ago
|
||
On a Mali-T830 it has been observed that glCopyImageSubData calls,
while resizing the webrender picture cache, can take many tens of
milliseconds to complete. They are likely stalling until the previous
frame's rendering to the picture cache has completed. This results in
stuttery scrolling. Using the glBlitFramebuffer path does not
encounter this issue, so use that instead.
As a precaution, apply this workaround to all Mali devices, rather
than just Mali-T.
Pushed by jnicol@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/974de9f821d3 Avoid using glCopyImageSubData on Mali GPUs. r=gw
|
||
Comment 4•4 years ago
|
||
| bugherder | ||
Description
•