5 ms·

Actually, virtually every device the average grade consumer uses, has a GPU. For instance, even Atom processors have GPUs. Granted, they don't have as much core

Actually, virtually every device the average grade consumer uses, has a GPU. For instance, even Atom processors have GPUs. Granted, they don't have as much cores as a full-fledged nVidia GPU, nor as much dedicated memory, but they are still GPU with several tens of cores and specialized APIs that were designed specifically for the tasks at hand. Plus, they offload (ish) the CPU.

amelius 9y ago
How about energy use? PS: And my second point?
- aneutron 9y ago
  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.
- zenojevski 9y ago
  Energy use _should_ go down overall, as the CPU takes more time to perform this type of task, compared to a GPU.
btrask 9y ago
Something without a GPU: VirtualBox. Last time I tried a Servo nightly in VirtualBox (to be fair, a few months ago), it immediately crashed/aborted with a GPU-related error. I think there's a good argument for preventing security-critical apps from raw GPU access, because graphics cards and drivers are a huge amount of attack surface. I still think WebRender is the way forward, but I hope they get it working with something like llvmpipe.
- Manishearth 9y ago
  It certainly used to work fine with llvmpipe; I tested it when it first came out and it worked with no problems. Was pretty fast, too; it wasn't crippled by it though the stress tests (that do horribly in Firefox and Chrome) didn't do that well in it either (of course). This may have changed and broken it on llvmpipe. In general we've not smoothed out this stuff so that you can fall back cleanly when a GPU doesn't exist.
- aneutron 9y ago
  While I understand the concern about security, I think it is beside the point. The surface attack is effectively the GPU and its driver, not the web renderer. The technique that are put in place by the web renderer are and were used by game engines. If anything it'll push the GPU makers to have better drivers support. EDIT: As for the no-GPU case, it is an edge-case, in which we could for example switch to the classical renderer. If you're running FF from a VM as your daily driver, there's something not right somewhere I think. (I'm thinking of C&C servers for satellites still running on WinXP and stuff)
  - btrask 9y ago
    > If you're running FF from a VM as your daily driver, there's something not right somewhere I think. I am. QubesOS is a similar setup that runs applications in Xen VMs for security. I think you can do GPU passthrough but it's not recommended. At this point I don't think I would ever go back to running a browser "bare", even if there were no bugs, being able to have complete control over it (e.g. pausing, blocking network access, etc.) is a godsend. I think the idea that "it'll push GPU makers to be secure" is weak. We're so far from that point it's not even on the horizon.

amelius 9y ago

How about energy use? PS: And my second point?

aneutron 9y ago
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.
zenojevski 9y ago
Energy use _should_ go down overall, as the CPU takes more time to perform this type of task, compared to a GPU.

btrask 9y ago

Something without a GPU: VirtualBox. Last time I tried a Servo nightly in VirtualBox (to be fair, a few months ago), it immediately crashed/aborted with a GPU-related error. I think there's a good argument for preventing security-critical apps from raw GPU access, because graphics cards and drivers are a huge amount of attack surface. I still think WebRender is the way forward, but I hope they get it working with something like llvmpipe.

Manishearth 9y ago
It certainly used to work fine with llvmpipe; I tested it when it first came out and it worked with no problems. Was pretty fast, too; it wasn't crippled by it though the stress tests (that do horribly in Firefox and Chrome) didn't do that well in it either (of course). This may have changed and broken it on llvmpipe. In general we've not smoothed out this stuff so that you can fall back cleanly when a GPU doesn't exist.
aneutron 9y ago
While I understand the concern about security, I think it is beside the point. The surface attack is effectively the GPU and its driver, not the web renderer. The technique that are put in place by the web renderer are and were used by game engines. If anything it'll push the GPU makers to have better drivers support. EDIT: As for the no-GPU case, it is an edge-case, in which we could for example switch to the classical renderer. If you're running FF from a VM as your daily driver, there's something not right somewhere I think. (I'm thinking of C&C servers for satellites still running on WinXP and stuff)
- btrask 9y ago
  > If you're running FF from a VM as your daily driver, there's something not right somewhere I think. I am. QubesOS is a similar setup that runs applications in Xen VMs for security. I think you can do GPU passthrough but it's not recommended. At this point I don't think I would ever go back to running a browser "bare", even if there were no bugs, being able to have complete control over it (e.g. pausing, blocking network access, etc.) is a godsend. I think the idea that "it'll push GPU makers to be secure" is weak. We're so far from that point it's not even on the horizon.