Bug 80746 - [chromium] threaded animations easily disturbed by texture uploads
Summary: [chromium] threaded animations easily disturbed by texture uploads
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 528+ (Nightly build)
Hardware: Other Android
: P2 Normal
Assignee: Nat Duca
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-09 19:02 PST by Eric Penner
Modified: 2013-04-08 11:23 PDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Penner 2012-03-09 19:02:32 PST
We start threaded animations after we upload all textures on the compositor thread. But the actual upload to GPU takes place later in the GPU process. These uploads can be slow on some platforms, so it would be nice to wait until this is truly done before starting the animation (so animation will be smooth).
Comment 1 Nat Duca 2012-03-13 10:34:22 PDT
Assigning to myself and +reveman while he and I sort out how to make this more-gooder.
Comment 2 Nat Duca 2012-03-29 11:39:37 PDT
I think this will help:
https://bugs.webkit.org/show_bug.cgi?id=81004

Eric, do we have line-of-sight to a technique to getting texture upload cost as part of the tex call rather than the draw call on pvr?
Comment 3 Eric Penner 2012-03-29 13:26:43 PDT
(In reply to comment #2)
> I think this will help:
> https://bugs.webkit.org/show_bug.cgi?id=81004
> 
> Eric, do we have line-of-sight to a technique to getting texture upload cost as part of the tex call rather than the draw call on pvr?

I want to experiment more to totally confirm this, but if we use texSubImage2d rather than texImage2d it causes the cost to paid upfront rather than on the first draw call (it's still very expensive though). Further, if we recycle textures *and* use texSubImage2D then the cost is reduced significantly. I don't want to say this with 100% certainty yet, because the cost could have just moved somewhere else again :) but I'll be able to confirm it soon.

However, this issue with animation is more related to the fact that our command buffer tex*Image calls are always relatively inexpensive, which results in us starting the animations before the heavy GPU cost is paid (the real tex*Image calls, or drawArrays calls depending on how we upload it).