Hacker News Reader

Comment by vanderZwan | Hacker News Reader

If we keep improving the DPI, then just having ever more beefy graphics card isn't going to scale. People tend to forget that graphics cards are really focussed on rendering 3D games, and the vast majority of our daily computer use does not involve that at all. Rendering 2D path graphics is much, much more common.

We need hardware accelerated path rendering we want to render text at those high resolutions fast efficiently. Thankfully, there have been people working on this for a while now, like Mark Kilgard at NVIDIA:

http://www.slideshare.net/Mark_Kilgard/gtc-2014-nvidia-path-...

It's covered by patents though, so I'm not sure how open this particular solution is.

View on HN

Most 2D rendering paths are already accelerated, for example you have DirectWrite in windows (https://msdn.microsoft.com/en-us/library/windows/desktop/dd3...). There is even a linux 2D driver that uses GL to accelerate 2D drawing, and they are/were even experimenting with caching fonts in surfaces.

Since when is desktop 2D graphics rendering a performance an issue ?

I understand the mobile story - they need to conserve energy + work on low end devices - but I doubt you're driving those 4k screens with ARM/Atom CPUs, low end integrated graphics chips and 2GB ram - once you have those giant screens you can fit a desktop machine somewhere as well and those aren't lacking the horsepower to draw 2D graphics.

That 8K near the end of that post is four times as many pixels to render as 4K. It's a surface area, it scales quadratically.

On top of that, the more pixels you have, the more a high frame rate matters to make animations look smooth. Sure, that might mostly just be scrolling on a webpage, but people care about this stuff. It's also physically less tiring for the eyes.

(Don't forget that, mobile includes laptops too - I'd like a high-res screen on my next laptop without the battery draining like crazy)

Yes, doubling the screen on one side raises the pixel count by 4x... but right now 3D graphics cards have at least a couple of orders of magnitude more graphics power than they need to drive a conventional 2D display, and 3 or 4 isn't out of the question, frankly. It really isn't a problem in 2D. Compared to any modern 3D game it's still a walk in the park for them. They've been overprovisioned for 2D work for a long time now. Even non-3D cards were getting pretty powerful before it just wasn't worth shipping 2D-only cards anymore, really, and that was a long time ago, and graphics cards have gotten scarily more powerful since then.

I am not a graphics card hardware expert, but I thought that the current tail end of the pipeline (shaders) basically was a massively parallel pixel handling engine. And that the hardware for that has been getting more and more generalized because of GPU compute.

Is it that inefficient to bend modern graphics card shaders to the task of rendering obscene numbers of pixels without the front end 3d geometry calculations?

No, that's exactly what Kilgard's approach is about, and it's backwards compatible with any NVIDIA card that supports CUDA, I believe.

Problem is GPUs are build for triangle rasterisation and that part is still baked in to hardware for performance. You can use hack stuff on top of the 3D pipeline to render vector graphics but you need to transform geometry and do triangulation which isn't really efficient and can't be done on the GPU efficiently. Coupled with overhead of talking to the GPU trough drivers and you end up being CPU bound and not a lot faster than the CPU rendering.

The equation changes when you increase screen resolution as the cost of setting up GPU to render is determined by geometry not by resolution and GPU rasterization is practically free compared to CPU which gets slower as you increase the resolution - so at the high enough resolution the driver overhead might matter less.

It's made by Nvidia, so there's very little chance of it being open.

Reply on news.ycombinator.com