Bug 44339

Summary: texImage2D calls should avoid CPU readback of GPU textures if possible
Product: WebKit Reporter: Adrienne Walker <enne>
Component: WebGLAssignee: Nobody <webkit-unassigned>
Status: RESOLVED WONTFIX    
Severity: Normal CC: cmarrin, enne, gman, junov, kbr, twiz, vangelis, wbaxter, wiltzius, zmo, zuh
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: All   
Attachments:
Description Flags
A small test case for slow perf of texSubImage2D none

Description Adrienne Walker 2010-08-20 09:42:28 PDT 
The current implementations of texImage2D that take html elements (image, canvas, video) all read the pixel data back from the GPU to the CPU, convert to the required format on the CPU, and then reupload to the GPU.  This could all be done much more efficiently directly on the GPU itself.

(Brought up from discussion here: https://bugs.webkit.org/show_bug.cgi?id=33852)
Comment 1 Bill Baxter 2011-06-09 13:53:39 PDT 
Created attachment 96636 [details]
A small test case for slow perf of texSubImage2D

I put together a little test case for this.
To see timing of calls to texSubImage2D with canvas as the data source, open up the console.   On newer Chrome with accelerated canvas, times often go up to 2 or 3 or as high as 6.  With previous versions of Chrome that did operations like text rendering in software, the time is consistently 1 ms max.  The disparity gets worse as the GPU pipeline gets more and more full.  In an app that really taxes the GPU, the times can be tens of msec.
Comment 2 Bill Baxter 2012-02-21 16:58:20 PST 
Is this fixed?  I just tried it out on Chromium on Linux with --ignore-gpu-blacklist and I'm seeing a consistent 1ms reported in the console.
(Chromium Version 19.0.1049.0 (122925))
Comment 3 Kenneth Russell 2012-02-22 10:58:14 PST 
No, the GPU->GPU copy path hasn't yet been implemented. Any speedups must be due to other improvements. Gregg has made several in the command buffer's efficiency.
Comment 4 Tom Wiltzius 2012-03-14 16:44:09 PDT 
Is there any work coming down the pipe that'll further improve this in the future beyond the command buffer speedups?
Comment 5 Gregg Tavares 2012-03-14 17:31:37 PDT 
twiz was working on something related
Comment 6 Jeff Timanus 2012-03-15 08:29:30 PDT 
(In reply to comment #5)
> twiz was working on something related

Yes, I was working on a change to implement a gpu-process extension that will allow for BGRA-BGRA texture copies, which are needed to copy the contents out of a hardware accelerated canvas into a webgl texture.

The issue is partially back-burnered, but is next on my stack.

See tracking bug:  crbug.com/101051