I think I'm supposed to hate this, but I think it's great. How is this different (apart from extremity) from adding hardware support for AES?
HTML/CSS/JS is ever-changing, control-intensive, and memory-intensive so it's probably not a good candidate for hardware acceleration.
E.g. AV1, HVEC, H264, etc etc. All of these either have or are about to have hardware acceleration. Why not JS?
The ideal "accelerator" for these kinds of jobs is a CPU with a big cache.
Video encoding has well defined control loops and data paths that don't arbitrarily interfere with each other, so it's a good candidate for custom hardware.
That is, you have a high bandwidth, highly parallel fast-path between framebuffer memory and functional units that compute FFTs and do motion vector operations, and a control plane that looks at a small handful variables in order to decide which data plane operations to schedule and how to glue together the final result.
To run JS, you need a pile of functional units and lots of memory, and data for every operation needs to be able to come from / go to anywhere in memory. That's... just a general purpose computer.
JS/CSS/HTML5 are not, they essentially have an open ended and infinite amount of branching and data dependency and I'm very skeptical a card could achieve much.
This is before we start talking about stuff like latency to the main CPU, CPUs are EXTREMELY fast in comparison to access to buses like ram, and especially PCI-E, I would not be the least bit surprised that even if some theoretical infinitely fast HTML5 accelerator card existed, it would still not be worth using due to latency of fetches from the card.
It's already not worth offloading things like cryptography to accelerator cards, and every major crypto algorithm was designed to run fast in hardware. And this is before we start talking about stuff like AES-NI.
Just for the sake of argument, I should point out that the bulk of the work done by JS/CSS/HTML involve primitive operations over a tree data structure. Conceptually, this paves the way to opportunities in hardware acceleration, similar to how the extensive use of polynomials in number crunching applications led to the addition of a fused multiply-add instruction set.
DOM level 3 core became a recommendation in April 2004. DOM4 went last call in 2015. The fundamentals- I feel- are quite fixed, although many auxiliary systems do change.
https://www.w3.org/TR/DOM-Level-3-Core/
> control-intensive, and memory-intensive
latency to remote accelerators can be problematic for some control workloads. ideally the control plane can hopefully offload itself onto the accelerator too.
I don't see memory intensive as a barrier. The 8 vdom+ processors probably come with sizable multi-megabyte caches. Perhaps they could be early on-ram processor architectures? after all it seems they have a fixed function diff pipeline. icd also suggest that perhaps the hardware representation might be very effective at using low bit-depth encodings, saving gobs of memory. keep text offboard & encode attribute values via some columnar representation & this could be a high throughput HTMLElement slinger & differ!
Well, that and the idea of permanently burning the, uh, unique design choices made by the web platform into hardware is a little horrifying.
For starters, is any part of javascript CPU-bound?
However most of them worked by using the video-overlay feature on cards where the hardware video decoder injected its output directly to the GPU's output (after the framebuffer) via an internal header - or even injected themselves into the GPU's output VGA signal using a D-Sub-input on the back of the card.
For a very brief time in the late-1990s there were partial MPEG-2 decoder cards that hooked themselves into DirectShow to do the bulk operations needed for DCT and/or Motion Compensation but not rendering the entire MPEG scene - they'd feed their results back to the CPU rather than the GPU... IIRC.
The funny thing is that overlays are coming back (soon, I hope!) - not for performance reasons, but because using a compositing window manager like the DWM introduces an additional frame of latency, but if a foreground window is being displayed 1:1 on the desktop then the GPU can simply overlay it directly to the output signal and thus eliminate that frame of latency. Some Linux WMs support it already, and Microsoft said they're working on it.
It could be great though for smaller parts. If someone can make a super fast font renderer accelerator, it could help in general. Alternatively we could adopt the GPU accelerated one created for servo.