Noob question. Isn't some GPU acceleration for 2D used since forever? I keep being perplexed as to why browsers still have problems with it (at least on my older Macbook with a shitty Intel's embedded GPU). I thought some stuff, like scrolling, was offloaded at least in early/mid-2000s, making for a distinctly meh experience when proper drivers weren't installed.
GPUs derive most of their parallelism from emitting rows of related “quads” (the smallest unit of the screen that supports a difference operator). 2D graphics are “chatty” in window sizes that are more like 5–10 units in diameter. It’s hell on HW perf. To make things worse, 2D applications usually want submillisecond latency. A GPU driver/hw stack will struggle to get latency below 1–2ms. When there’s lots of multipass rendering (which is a thing 2D also wants a lot of), latency can to 10+ ms.
Well said, thanks. It's also a goal of this work to do compositing inside the "fine rasterizer" compute kernel, to avoid multipass as much as possible. Of course, in the general case for stuff like blur that's hard, but that's one reason why I've been working on special cases like blurred rounded rectangles, which I can render pretty much at lightspeed. (It's not integrated into the current code but would be quite easy)
What does latency have to do with 2D? Are you suggesting UI toolkits are writing GPU commands synchronously? You should fill display list, fire it and forget about GPU until the next update.
Pen drawing for UIs. The ideal case is to update a small portion of the screen at about 240hz, to provide a good simulation of pen/pencil feedback. Really, your latency envelope should be on the order of the propagation of sound through the barrel of the marking device, but screens don’t update that fast.
Bottleneck is in the input layer. While using a desktop computer look at the mouse cursor, now move the mouse - hardware accelerated 2D graphics, imperceptible latency.
I expect a screen that supports or is designed for pen drawing to be somewhat more likely to be above 60Hz. All of these things are niche things that not many care about, but in any case, it’d be nice to be able to do better. And like with Formula 1 race cars, benefits from high-end techniques tend to trickle down to other more mainstream targets in time.
It's even more offloaded in browsers as I expected.
I recently had to do a proof of concept displaying a huge gantt chart (I really mean huge!).
Normally, 2D drawing has some disadvantages with textures and scaling/rotating.
This proof of concept included testing out various methods on the <canvas>, including both using WebGL and standard 2D calls.
To my surprise, I was able to get the standard 2D calls way faster, even with texturing and rotations (which I did not expect). All browsers (Chrome, Firefox, Edge, IE) do GPU optimizations with standard 2D canvas drawings.
Only when I was putting a shitload of different things on there (gantt chart looked more like a barcode at this point), the WebGL implementation started to outperform the 2D calls.
Remark that I didn't go into programming shaders. In the end, it wasn't necesarry since the normal canvas calls already supported plenty of performance.
Also remark that I'm not just some random dude with no experience. I'm creating a game dev tool https://rpgplayground.com, which runs fully in the browser using Haxe and the Kha graphics library, and made plenty of games during my career.
But that pretty much what we have now even on modern systems.
For desktop UI purposes (but not for games) GPU acceleration started to become critical only relatively recently - on high-DPI screens. Number of pixels jumped 9 times between 96 ppi and 320 ppi (Retina) screens. CPUs haven't changed that much in the time frame so you may experience slow rendering on otherwise perfect screen picture.
At the very beginning x86 PC computers didnt have DMA capable of transferring ram to ram, not to mention DMA was slower than CPU http://www.os2museum.com/wp/the-danger-of-datasheets/ First PC 2D acceleration was very much on graphics chip, in form of either IBM 8514 or TIGA compatibility ($1K cards when introduced). Amiga also doesnt fit the profile, seeing most models shipped with unified shared memory (chip ram).
> Amiga also doesnt fit the profile, seeing most models shipped with unified shared memory (chip ram).
What profile? They did RAM to RAM DMA transfer exactly for video acceleration with the Agnus chip, which would access memory through DMA channels to perform 2D blitting.
c-smile specifically said 'RAM to VRAM'. Agnus/Alice didnt have DMA access to _non video_ ram so Amiga is automatically out.
What I think he was thinking about was Blitter in general, and not particular implementations using DMA controller. First Blitter accelerated 2D graphics I read about were done on Xerox Alto using microcode.
I'm arguing from the point of view that 'VRAM to VRAM' (or maybe "shared I/O RAM" in Amiga's case) is a subset of 'RAM to VRAM'. You seem to be arguing from the point of view that just "RAM" in this context means non-video RAM. That's a fair assumption, and I understood it from your last post, but I don't think the difference is significant to the general point that we've had various forms of DMA-based 2D video acceleration for a long time.
As others have said, the 2D pipeline right now is mostly focused on drawing textures (dumb blocks of pixel data). The work in the OP is about drawing SVG graphics (complex sets of shapes, lines, curves).
Yes, both X Server and Windows have 2D Hardware acceleration for years now. X Server through a multitude of interfaces[1] and Windows through GDI and now Direct2D[2][3]
Yes, it's common to have this kind of acceleration in a video controller. There are VESA extensions for blitting to screen memory for example. Even something as basic as a CGA text screen—where rendering of bitmap fonts is offloaded to the video card and the CPU only needs to operate on indices into a table of predefined characters—could be considered a basic form of 2D acceleration.
The article and most discussion here however concerns rasterization, specifically path rendering, which is useful when rendering things like fonts and image formats like SVG. You use primitives such as lines and curves to form outlines of objects and then fill them. It's a problem that does not very easily translate into rendering textured triangles (which is what the GPU is best at) or copying/moving screen regions, so there's some work in doing it in a performant way still, and a lot of it typically happens on the CPU.
There was some form of 2D GPU acceleration used in Windows XP that is no longer used in modern GPUs. I remember a PCI Trident video card that provided such acceleration for my Windows 98-era computer.
There's also a 3D fixed pipeline that was all that the first 3D GPUs could do and it is also removed from modern GPUs.
A game I still play to this day is called rFactor, and it runs much faster in DX9 mode than in DX8 or DX7 mode in my hardware. At the very least, it behaves that way in this week's test. This means my hardware doesn't have that old fixed pipeline.
Some people with old hardware can only run it with decent frame rate in DX7.
So the answer to your question is: yes, 2D has been accelerated since forever, but now we have general purpose 3D programmable video cards, and they are so good that now we only have general purpose 3D programmable video cards and the other forms of acceleration are obsolete.
I remember playing something that ran with the Win32s extensions and was similar to Wolfenstein 3D, but it was 3D, and I don't think it had anything to do with 2D acceleration.
