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

Adrienne Walker
Reported 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)
Attachments
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
View All Add attachment proposed patch, testcase, etc.
Bill Baxter
Comment 1 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.
Bill Baxter
Comment 2 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))
Kenneth Russell
Comment 3 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.
Tom Wiltzius
Comment 4 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?
Gregg Tavares
Comment 5 2012-03-14 17:31:37 PDT
twiz was working on something related
Jeff Timanus
Comment 6 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
Note You need to log in before you can comment on or make changes to this bug.