Bug 44339 - texImage2D calls should avoid CPU readback of GPU textures if possible
Summary: texImage2D calls should avoid CPU readback of GPU textures if possible
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebGL (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC All
: P2 Normal
Assignee: Nobody
Depends on:
Reported: 2010-08-20 09:42 PDT by Adrienne Walker
Modified: 2013-04-08 11:31 PDT (History)
11 users (show)

See Also:

A small test case for slow perf of texSubImage2D (6.98 KB, application/octet-stream)
2011-06-09 13:53 PDT, Bill Baxter
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
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