4 ms·

There is a comment in this thread that explains this very well. 1) So the average CPU can do arroung several GFLOPS, the GPU however, even the integrated, can

There is a comment in this thread that explains this very well. 1) So the average CPU can do arroung several GFLOPS, the GPU however, even the integrated, can do some TFLOPS. S 2) CPUs have syncronization primitives, re-ordering, execution permissions, all sorts of besides the task ops they have to enforce. GPUs for the most part do not care about any of that. From 1 and 2, you could spending 16ms classically rendering a web page, or spend 4ms rendering the page and 12ms on idle. From an energy standpoint, it's the same if not arguably better. (I'm not an expert but I think for simple and over repetitive shaders and the batching implemented, it is actually logical)

amelius 9y ago
To come back to my second point, let's say we make a webpage arbitrarily more complex. Where does the tipping point lie, where compositing would become more favorable (in terms of time and energy) than repainting everything on every frame? Also, what (time and energy) savings could compositing bring if implemented on the GPU? (versus repainting everything on the GPU).
- metajack 9y ago
  I addressed your first paragraph in another comment, but for the second one, compositing is currently on GPUs in most browsers. Layers are painted on the CPU and uploaded as textures to the GPU, which are then composited together. Manipulation of a few properties can be done cheaply in the compositor (modifying the layer transform or opacity for example). And that is assuming that you perfectly layerized, which is a heuristic process. You can find plenty of web dev articles about how to fix your CSS so that it layerizes propertly or how to avoid animations and transitions that can't be accelerated in the compositor. Another savings (memory, time, unsure about energy) comes from not having to upload giant pixel buffers to the GPU.
vardump 9y ago
> 1) So the average CPU can do arroung several GFLOPS Maybe 15 years ago. I think 200 - 1000 GFLOPs is common modern era CPU performance. A single core can do 32 floating point operations per clock cycle. Half that, if you don't count multiply accumulate as two ops. Drop another half if you want 64-bit floats.

amelius 9y ago

To come back to my second point, let's say we make a webpage arbitrarily more complex. Where does the tipping point lie, where compositing would become more favorable (in terms of time and energy) than repainting everything on every frame? Also, what (time and energy) savings could compositing bring if implemented on the GPU? (versus repainting everything on the GPU).

metajack 9y ago
I addressed your first paragraph in another comment, but for the second one, compositing is currently on GPUs in most browsers. Layers are painted on the CPU and uploaded as textures to the GPU, which are then composited together. Manipulation of a few properties can be done cheaply in the compositor (modifying the layer transform or opacity for example). And that is assuming that you perfectly layerized, which is a heuristic process. You can find plenty of web dev articles about how to fix your CSS so that it layerizes propertly or how to avoid animations and transitions that can't be accelerated in the compositor. Another savings (memory, time, unsure about energy) comes from not having to upload giant pixel buffers to the GPU.

vardump 9y ago

> 1) So the average CPU can do arroung several GFLOPS Maybe 15 years ago. I think 200 - 1000 GFLOPs is common modern era CPU performance. A single core can do 32 floating point operations per clock cycle. Half that, if you don't count multiply accumulate as two ops. Drop another half if you want 64-bit floats.