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)
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.
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))
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.
Is there any work coming down the pipe that'll further improve this in the future beyond the command buffer speedups?
twiz was working on something related
(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