Announcement

Collapse
No announcement yet.

GNOME's GTK Vulkan Renderer Faster Than OpenGL, Now Working On Windows

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

  • GNOME's GTK Vulkan Renderer Faster Than OpenGL, Now Working On Windows

    Phoronix: GNOME's GTK Vulkan Renderer Faster Than OpenGL, Now Working On Windows

    GNOME's GTK Vulkan renderer continues advancing in Git for GTK+ 4.0. This Vulkan renderer for the GTK Scene Kit is forming into a nice alternative to its OpenGL renderer...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    So I guess this wont be default for a while due to how much Vulkan support there actually is among the various graphics drivers, but hot damn that is some performance. GTK4 is looking pretty exciting and we're only in the first of it's 4 development cycles

    Comment


    • #3
      Isnt the story that the software renderer (Cairo) is faster than both the hardware renderers?

      Comment


      • #4
        Originally posted by You- View Post
        Isnt the story that the software renderer (Cairo) is faster than both the hardware renderers?
        Yeah, it seems from that comparison that Cairo is all around faster, which I thought was the exact opposite. Otherwise why go through the trouble to redefine renderers if the old one perform so well?

        Comment


        • #5
          Originally posted by ciupenhauer View Post

          Yeah, it seems from that comparison that Cairo is all around faster, which I thought was the exact opposite. Otherwise why go through the trouble to redefine renderers if the old one perform so well?
          Because for many jobs in rendering, the CPU uses more energy to do the same task. Also, you can use the CPU for something else in the meantime, while the GPU is otherwise idle (unless you're also rendering a game in parallel or something).

          Comment


          • #6
            Originally posted by You- View Post
            Isnt the story that the software renderer (Cairo) is faster than both the hardware renderers?
            The story is that GTK, after 10 years of work on doing exactly that, is still very much optimised for Cairo and immediate rendering; disentangling that mess takes time, but apparently less than we originally thought.

            Additionally, the Vulkan renderer is the one that gives us the least in terms of overhead, so we use it as a reference point; the goal is to take the GL renderer at the level of the Vulkan renderer once we moved GTK away from its Cairo roots.

            Comment


            • #7
              ebassi that sounds scarily like making the software performance worse, or completely unsupported.

              Comment


              • #8
                Originally posted by CrystalGamma View Post

                Because for many jobs in rendering, the CPU uses more energy to do the same task. Also, you can use the CPU for something else in the meantime, while the GPU is otherwise idle (unless you're also rendering a game in parallel or something).
                Do you have any data to support this theory, or is all just conjecture?

                Comment


                • #9
                  I have not been able to build GTK 3.89 due to the dependence on Graphene, which does not exist in Debian and which I have yet to sucessfully build. An older 1.4 version exists as precompiled binaries for either Arch or Fedora(forgot which one) but is too old to build GTK 3.89 against. I have been curious to build this, simply so I could test my UbuntuStudio_Legacy theme against it in gtk(whatever)-widget-factory. At some point in the future GNOME apps will be using GTK4 and most distros use or offer some of them (like Brasero) in all DE's except KDE, so themes will have to work with GTK4. There are several GNOME apps I myself use, need to keep, and need to keep my theme working in and I would like to get started on this.

                  Comment


                  • #10
                    Originally posted by curaga View Post
                    ebassi that sounds scarily like making the software performance worse, or completely unsupported.
                    That's a remarkable misunderstanding of what I actually wrote, so: kudos.

                    We need to disentagle GTK+ from Cairo because Cairo on a CPU won't ever get any faster at rendering than a GPU. We've essentially reached peak Cairo performance for what we do with a GUI toolkit, and it's clearly not enough.

                    Right now, with fairly non-invasive changes and unoptimized code, we're already in the same order of magnitude as rendering with Cairo after 10 years of optimizations. Once we get into optimizing the GL and Vulkan renderers, we're going to get much faster than Cairo.

                    Additionally, on crappy CPUs (like, say, the ones in ARM devices on the low price point) Cairo is terribly slow, which is why moving the rendering on the GPU is the only approach that is going to scale.

                    Comment

                    Working...
                    X