Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    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?pag...nt-Page-Tables

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

    Comment


    • #3
      Originally posted by TemplarGR View Post
      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."
      Michael Larabel
      http://www.michaellarabel.com/

      Comment


      • #4
        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..

        Comment


        • #5
          Originally posted by polarathene View Post
          it's definitely something going on with the browsers..
          browsers being browsers (or more importantly what they have to browse).

          Comment


          • #6
            Originally posted by mos87 View Post
            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

            Comment


            • #7
              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.

              Comment

              Working...
              X