We currently have GPU compositing and rendering[1]. Other browsers will get this eventually and some have it already.
We plan to explore this space quite a bit.
The other thing we're starting to think about is using SIMD ops for layout, which isn't a GPU but falls into a similar "taking advantage of modern hardware" bucket.
[1] Note that 2D rendering on the GPU is not currently a clear win. In theory you save a texture upload and get massively parallel drawing operations, but in practice there's a lot of overhead to deal with.
We're certainly planning to investigate it, particularly with the advent of vector units that reduce the latency of data transfers, such as AMD's new Opterons and Intel's Knight's Landing. The challenge here is that while several of the stages (e.g. CSS selector matching) can be trivially sped up on a GPU, the CPU/GPU latency cost is going to be close to the original CPU evaluation time.
There are some very sequential and unfortunately common "corner cases" in layout (e.g., uncleared floats) that have lead us to currently prefer the higher clock-speed CPU for parallelizing phases. Even if we find a great way to work around floats, it's likely there will still be a lot of CPU/GPU chatter, which makes it difficult to use today's GPU cards when you're trying to keep total page load well under 200ms and incremental reflows < 15ms.
> it's likely there will still be a lot of CPU/GPU chatter
At least on today's consumer cards (admittedly I haven't tried anything really high-end), one issue I've had with this is that it gets even worse (by far) when more than one program is trying to use the GPU. If you're editing photos in Lightroom while alt-tabbing to a tutorial in the browser, and everything is trying to GPU-accelerate its operations, contention goes way up and things start blocking on GPU contexts and data transfers.
