TTM Huge Page Table Entries Pending For Lowering Graphics Driver CPU Usage

[phoronix]

Phoronix: TTM Huge Page Table Entries Pending For Lowering Graphics Driver CPU Usage

Longtime open-source Linux graphics developer Thomas Hellström of VMware has sent out a patch series aiming for Linux 5.7 or 5.8 to introduce support for huge and giant page-table entries for the TTM memory management code and TTM-enabled graphics drivers...

http://www.phoronix.com/scan.php?page=news_item&px=TTM-Huge-Giant-Page-Tables

[TemplarGR]

This seems nice. But what the memory hit will be? Hope we see it implemented in AMDGPU too.

[Michael]

This seems nice. But what the memory hit will be? Hope we see it implemented in AMDGPU too.

"If a buffer object size is not huge-page or giant-page aligned, its size will NOT be inflated by this patchset."

[polarathene]

Anyone know why WebGL can use so much CPU even when the GPU is clearly active? Not sure if it's an intel graphics bug as I've only tested this with some WebGL projects on a budget i3 laptop with intel graphics, but CPU was going up to 45-70% with 60% load on the iGPU, both in Firefox and Chrome. On Windows I've heard CPU barely takes a hit.

Is it a linux issue with the browsers hardware support, or an issue with Intel's linux drivers? When the next Firefox release is out, I'll give that a try on Wayland(only tried X11 so far), as it's meant to provide zero-copy for WebGL, which I assume might be why the CPU load is spiking, even for simple WebGL scenes. I am able to avoid the CPU activity by not rendering new frames, which works if the content is static, but as soon as I have some sort of animation/effect going on, that's no longer an option and the CPU takes a big hit(understandable that the amount is due to 2/4 cores/threads of the i3 10th gen, but still unexpected..).

glxgears only raises CPU activity up to 10% for 60FPS, so it's definitely something going on with the browsers..

[mos87]

it's definitely something going on with the browsers..

browsers being browsers (or more importantly what they have to browse).

[polarathene]

browsers being browsers (or more importantly what they have to browse).

The CPU only spikes up and stays constant with the WebGL content afaik. For example, the following link showing off some WebGL taxes my i3 at 45% load, but if I change tab CPU drops back down to 0-1% load idling. I can do a much simpler WebGL project, but CPU load still remains about the same as the linked demo. On Windows you don't experience such high activity:

https://codesandbox.io/embed/r3f-instanced-colors-8fo01

[arQon]

1) browsers suck. not the fault of the devs, as the amount of garbage added to the specs over the years makes it impossible to do any of it well, but it doesn't make the browsers suck any less.
2) webgl is only good for things that can be trivially handled IN the gl. the rest of it, on top of all the work that ALREADY still has to be done in the driver, still has to be done on the cpu.

my guess is you're in the "work that ALREADY still has to be done in the driver" part of things. webgl doesn't magically accelerate the whole pipeline: it just moves a small fraction of the functionality onto the gpu. it's just that that tiny fraction happens to represent a lot of performance wins vs a cpu-ONLY implementation, eg filling a lot of pixels.
glxgears does almost no work at all: it's a TINY number of polys and pretty much all just fillrate, so the driver's doing nearly nothing if it doesn't have to handle the rasterisation.

when you change tabs, the browser is simply skipping a ton of work that's pointless - which could be anything from a truckload of "real" work to just sitting in a spinlock burning cycles waiting for vsync.

so, yeah - i can't help you solve your problem these days, but i can say i'm not at all SURPRISED by it, at least.

[polarathene]

2) webgl is only good for things that can be trivially handled IN the gl. the rest of it, on top of all the work that ALREADY still has to be done in the driver, still has to be done on the cpu.

my guess is you're in the "work that ALREADY still has to be done in the driver" part of things.

glxgears does almost no work at all: it's a TINY number of polys and pretty much all just fillrate, so the driver's doing nearly nothing if it doesn't have to handle the rasterisation.

I have had pretty basic WebGL scenes, as simple as glxgears, some without any animation at all, no extra logic changing, just rendering the same static frame with a single object. Even a simple shader that just has the GPU paint a gradient fill. All seems to cause the higher than expected CPU usage.

Windows doesn't have the same performance hit with the WebGL projects, so I'm not sure what CPU work you're referring to here, either the browser is doing something that is tanking performance on Linux vs Windows, or it's my Intel GPU driver code(on linux)? glxgears provides a comparison of the overhead, but that it's not affected by the GPU driver like WebGL/Browser is(but only on Linux). Inspecting the GPU utilization showed similar 60% utilization with a WebGL project or glxgears iirc.

BTW, if you don't quote/tag me, I probably won't see the next reply as I won't be notified.