Live data from Hacker News

The web at maximum FPS: How WebRender gets rid of jank

hacks.mozilla.org

171–180 of 212 posts

Re: The web at maximum FPS: How WebRender gets rid of jank

#171

I tried testing it out on a ThinkPad T61 to see how well it works with an older embedded GPU (Intel 965 Express), but I can't enable it (on Windows 10) because D3D11 compositing is disabled, it says D3D11_COMPOSITING: Blocklisted; failure code BLOCKLIST_ So does that mean that it is known not to work with that GPU? Can you override the blocklist to see what happens? Edit: It also says: > Direct2D: Blocked for your gr…

Take it from a Thinkpad X60 owner, the Intel GPUs from that era are absolute trash. They don't support OpenGL 3.0 on any platform (in fact, they didn't gain 3.0+ support until Sandy Bridge in 2011(!)) so don't expect any of this recent GPU-centric work (which seems to be targeting OpenGL 3.0+) to work on these GPUs. It would probably work just fine on the contemporary Radeon and GeForce cards since they support OpenGL 3.3.

Re: The web at maximum FPS: How WebRender gets rid of jank

#173

Won’t this cause a lot of work to be done for a blinking cursor? Curious about battery drain, I/O overhead, General CPU usage, etc.

With a compositor you're already drawing every pixel every frame on the GPU, whether it's just a cursor blinking or not. The WR approach basically only adds a negligible amount of vertex shading time.

It seems like even in the compositor approach, you could optimize that. copy the last last drawn frame buffer directly and then modify it.

I think the best approach would be some hybrid between invalidation and redrawing everything.

Re: The web at maximum FPS: How WebRender gets rid of jank

#174
post #146

Earlier quoted context omitted.

Actually, virtually every device the average grade consumer uses, has a GPU. For instance, even Atom processors have GPUs. Granted, they don't have as much cores as a full-fledged nVidia GPU, nor as much dedicated memory, but they are still GPU with several tens of cores and specialized APIs that were designed specifically for the tasks at hand. Plus, they offload (ish) the CPU.

Something without a GPU: VirtualBox. Last time I tried a Servo nightly in VirtualBox (to be fair, a few months ago), it immediately crashed/aborted with a GPU-related error. I think there's a good argument for preventing security-critical apps from raw GPU access, because graphics cards and drivers are a huge amount of attack surface. I still think WebRender is the way forward, but I hope they get it working with som…

It certainly used to work fine with llvmpipe; I tested it when it first came out and it worked with no problems. Was pretty fast, too; it wasn't crippled by it though the stress tests (that do horribly in Firefox and Chrome) didn't do that well in it either (of course). This may have changed and broken it on llvmpipe.

In general we've not smoothed out this stuff so that you can fall back cleanly when a GPU doesn't exist.

Re: The web at maximum FPS: How WebRender gets rid of jank

#175

Earlier quoted context omitted.

I remember reading at some point that WebRender could actually be isolated relatively easily and then applied to basically any browser. That sort of already took place, going from Servo over into Gecko. So, it might actually turn into somewhat of a pseudo-standard.

You send display lists to it over IPC, and it's easy enough to generate those from C++. It has a well defined API boundary, which makes it easy to use. This is in stark contrast to the style engine in Servo which relies on memory representation to be fast. So integrating it requires very tight coupling of data structures.

Is it in its own process for improved security? Specifically, are buggy graphics drivers the concern?

Re: The web at maximum FPS: How WebRender gets rid of jank

#176
post #64

Is it going to use Vulkan? Sounds like a good fit for proper parallelized rendering. UPDATE: Ah, I see it's mentioned in the future work: https://github.com/servo/webrender/wiki#future-work Vulkan? This could possibly make some of the serial steps above able to be parallelized further. So it will be using OpenGL then?

Vulkan has been a consideration from the earliest architecturing steps done in WebRender. So, the internal pipelines are all set up to be mapped to Vulkan's pipelines. It's actually OpenGL which fits less into the architecture, but it's still easier to just bundle WebRender's pipelines all together and then throw that into OpenGL.

Interesting. Will it eventually use vulkano library, or its own Vulkan bindings?

Re: The web at maximum FPS: How WebRender gets rid of jank

#177
post #151

Will there finally be a unified use of the GPU on all platforms (win, mac, linux, etc) or will WebRender just be a Windows only feature for quite some time?

I have WebRender working on Linux with Intel 5500 integrated graphics. Hardware acceleration is still a bit glitchy though I'm afraid (with or without WebRender). To enable, toggle 'layers.acceleration.force-enabled' as well as 'gfx.webrender.enabled' edit: It's also working through my Nvidia 950m (through bumblebee), although subjectively it seems to have a little more lag this way.

Well that stinks, I'm on Intel HD 3000

Re: The web at maximum FPS: How WebRender gets rid of jank

#178
post #177

Earlier quoted context omitted.

I have WebRender working on Linux with Intel 5500 integrated graphics. Hardware acceleration is still a bit glitchy though I'm afraid (with or without WebRender). To enable, toggle 'layers.acceleration.force-enabled' as well as 'gfx.webrender.enabled' edit: It's also working through my Nvidia 950m (through bumblebee), although subjectively it seems to have a little more lag this way.

Well that stinks, I'm on Intel HD 3000

I'm not saying you need at least a 5500, I'm just saying it works for me and that's what I have.

Re: The web at maximum FPS: How WebRender gets rid of jank

#179
post #175

Earlier quoted context omitted.

You send display lists to it over IPC, and it's easy enough to generate those from C++. It has a well defined API boundary, which makes it easy to use. This is in stark contrast to the style engine in Servo which relies on memory representation to be fast. So integrating it requires very tight coupling of data structures.

Is it in its own process for improved security? Specifically, are buggy graphics drivers the concern?

Buggy graphics drivers are definitely a concern, not just for security but for stability. Specifically, graphics drivers crash. A lot. Simply moving GPU access to a separate process (which is common in modern browsers) means that a driver crash doesn't bring down any webpages, much less the whole browser; if done right you just get a flicker as the GPU process is restarted.

Re: The web at maximum FPS: How WebRender gets rid of jank

#180
post #168

Earlier quoted context omitted.

For WebRender, we targeted the integrated GPUs. You still need some logic to ensure you don't accidentally kick the discrete one into gear, but the integrated ones definitely have enough performance for almost anything WR will throw at it.

Could you elaborate the edge cases which fall beyond "almost anything WR will throw at it" ie what are the use cases where you would end up waking the discrete GPU?

I would personally imagine anything more complex than Quake Live would probably trigger the discrete GPU.
Post reply on HN