9 ms·

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?

colejohnson66 6y ago
It’d probably be slower transferring the data to it and back than just using the CPU
- tshaddox 6y ago
  Is that possible? Aren't there hardware video decoders that deliver, well, full video at high frame rates? I'm not sure how those things work. Maybe they have a direct route to the GPU and CPU just decides how things should get composited.
  - DaiPlusPlus 6y ago
    Hardware video decoders were... complicated. 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.
    - tshaddox 6y ago
      Any idea how the Apple Afterburner card works? It's PCI-Express card that can decode a bunch of 8k ProRes streams in realtime.
      - colejohnson66 6y ago
        Simple put: Afterburner is an FPGA you can add to your Mac Pro
        tshaddox 6y ago
        But the question is how does it deliver video to the GPU.
        DaiPlusPlus 6y ago
        PCI-Express bus sharing, and custom Radeon firmware - or it could use DMA to main memory and copy it in the background.
    - riggsdk 6y ago
      I remember a time where Windows Media Player would sometimes do video playback by just drawing a very specific "close-to-black" RGB color in it's window and then let the hardware impose the decoded video on to that part of the screen with that color. I could then open up MS Paint and draw my own custom shaped "window" into my video playback with that color by laying it on top of the WMP window.
      - DaiPlusPlus 6y ago
        Yes, that's Video Overlay: when the video is not rendered to the framebuffer but actually to the output signal directly. It was replaced by VMR (Video Mixing Renderer) which allows video to be rendered to each parent windows' offscreen DWM buffer. 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.
  - wmf 6y ago
    It depends how often you have to round-trip between the CPU and the accelerator. If it's never or once per frame (as in video decoding) it's not bad, but if the JavaScript core ended up blocking on measurements from the layout core multiple times per frame you could end up losing a lot of performance.
  - deleted 6y ago
    [deleted]
viraptor 6y ago
The idea is quite realistic. (Apart from the GCs) But given how html is changing, the behaviour would become obsolete soon. 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.
- ampdepolymerase 6y ago
  You can update FPGAs over-the-air, the are reconfigurable silicon. You already have this for your CPUs whenever you install an "Intel microcode update".
- wmf 6y ago
  Just one example https://people.eecs.berkeley.edu/~krste/papers/maas-isca18-hwgc.pdf https://people.eecs.berkeley.edu/~krste/papers/maas-isca18-h...
wmf 6y ago
There are a lot of differences. AES will never change and will be recommended for decades. AES is very compute-intensive so a hardware implementation is much more efficient than software. HTML/CSS/JS is ever-changing, control-intensive, and memory-intensive so it's probably not a good candidate for hardware acceleration.
- aaomidi 6y ago
  So? We have ever-growing standards that we do hardware acceleration on. Some of the newer standards don't get hardware accel until new hardware comes out. E.g. AV1, HVEC, H264, etc etc. All of these either have or are about to have hardware acceleration. Why not JS?
  - ohazi 6y ago
    > control-intensive, and memory-intensive 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.
  - throwaway2048 6y ago
    All of those video standards are designed from day 1 to be hardware accelerated, they have a completely fixed pipeline with no control branches, with very few data dependencies (stuff like A+B=C C+A=D). 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.
AI_WAIFU 6y ago
Nah, I hate it. If this gets any sort of adoption we'll be stuck with HTML5 forever and changes will become much more difficult.
userbinator 6y ago
...or Java, for that matter: https://en.wikipedia.org/wiki/Jazelle https://en.wikipedia.org/wiki/Jazelle
- Groxx 6y ago
  Or Lisp: https://en.wikipedia.org/wiki/Lisp_machine https://en.wikipedia.org/wiki/Lisp_machine
  - djsumdog 6y ago
    The difference with Lisp machines is that they're the counterpart to Von Numen machines. C is probably the closest abstract representation of a Von Numen architecture.
- deleted 6y ago
  [deleted]
chrisstanchak 6y ago
Same. Want one.
csande17 6y ago
Aside from all the great little jokes--there should definitely be a NIST standard Minion meme collection--the silliest part of this is probably that it's a dedicated PCI-Express card. Well, that and the idea of permanently burning the, uh, unique design choices made by the web platform into hardware is a little horrifying.
- rektide 6y ago
  still, few other hypertext models that are worthy of note
barumi 6y ago
> How is this different (apart from extremity) from adding hardware support for AES? For starters, is any part of javascript CPU-bound?

colejohnson66 6y ago

It’d probably be slower transferring the data to it and back than just using the CPU

tshaddox 6y ago
Is that possible? Aren't there hardware video decoders that deliver, well, full video at high frame rates? I'm not sure how those things work. Maybe they have a direct route to the GPU and CPU just decides how things should get composited.
- DaiPlusPlus 6y ago
  Hardware video decoders were... complicated. 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.
  - tshaddox 6y ago
    Any idea how the Apple Afterburner card works? It's PCI-Express card that can decode a bunch of 8k ProRes streams in realtime.
    - colejohnson66 6y ago
      Simple put: Afterburner is an FPGA you can add to your Mac Pro
      - tshaddox 6y ago
        But the question is how does it deliver video to the GPU.
        DaiPlusPlus 6y ago
        PCI-Express bus sharing, and custom Radeon firmware - or it could use DMA to main memory and copy it in the background.
  - riggsdk 6y ago
    I remember a time where Windows Media Player would sometimes do video playback by just drawing a very specific "close-to-black" RGB color in it's window and then let the hardware impose the decoded video on to that part of the screen with that color. I could then open up MS Paint and draw my own custom shaped "window" into my video playback with that color by laying it on top of the WMP window.
    - DaiPlusPlus 6y ago
      Yes, that's Video Overlay: when the video is not rendered to the framebuffer but actually to the output signal directly. It was replaced by VMR (Video Mixing Renderer) which allows video to be rendered to each parent windows' offscreen DWM buffer. 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.
- wmf 6y ago
  It depends how often you have to round-trip between the CPU and the accelerator. If it's never or once per frame (as in video decoding) it's not bad, but if the JavaScript core ended up blocking on measurements from the layout core multiple times per frame you could end up losing a lot of performance.
- deleted 6y ago
  [deleted]

viraptor 6y ago

The idea is quite realistic. (Apart from the GCs) But given how html is changing, the behaviour would become obsolete soon. 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.

ampdepolymerase 6y ago
You can update FPGAs over-the-air, the are reconfigurable silicon. You already have this for your CPUs whenever you install an "Intel microcode update".
wmf 6y ago
Just one example https://people.eecs.berkeley.edu/~krste/papers/maas-isca18-hwgc.pdf https://people.eecs.berkeley.edu/~krste/papers/maas-isca18-h...

wmf 6y ago

There are a lot of differences. AES will never change and will be recommended for decades. AES is very compute-intensive so a hardware implementation is much more efficient than software. HTML/CSS/JS is ever-changing, control-intensive, and memory-intensive so it's probably not a good candidate for hardware acceleration.

aaomidi 6y ago
So? We have ever-growing standards that we do hardware acceleration on. Some of the newer standards don't get hardware accel until new hardware comes out. E.g. AV1, HVEC, H264, etc etc. All of these either have or are about to have hardware acceleration. Why not JS?
- ohazi 6y ago
  > control-intensive, and memory-intensive 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.
- throwaway2048 6y ago
  All of those video standards are designed from day 1 to be hardware accelerated, they have a completely fixed pipeline with no control branches, with very few data dependencies (stuff like A+B=C C+A=D). 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.

AI_WAIFU 6y ago

Nah, I hate it. If this gets any sort of adoption we'll be stuck with HTML5 forever and changes will become much more difficult.

userbinator 6y ago

...or Java, for that matter: https://en.wikipedia.org/wiki/Jazelle https://en.wikipedia.org/wiki/Jazelle

Groxx 6y ago
Or Lisp: https://en.wikipedia.org/wiki/Lisp_machine https://en.wikipedia.org/wiki/Lisp_machine
- djsumdog 6y ago
  The difference with Lisp machines is that they're the counterpart to Von Numen machines. C is probably the closest abstract representation of a Von Numen architecture.
deleted 6y ago
[deleted]

chrisstanchak 6y ago

Same. Want one.

csande17 6y ago

Aside from all the great little jokes--there should definitely be a NIST standard Minion meme collection--the silliest part of this is probably that it's a dedicated PCI-Express card. Well, that and the idea of permanently burning the, uh, unique design choices made by the web platform into hardware is a little horrifying.

rektide 6y ago
still, few other hypertext models that are worthy of note

barumi 6y ago

> How is this different (apart from extremity) from adding hardware support for AES? For starters, is any part of javascript CPU-bound?