Slashdot Mirror


Glamor, X11's OpenGL-Based 2D Acceleration Driver, Is Becoming Useful

The Glamor driver for X11 has sought for years to replace all of the GPU-specific 2D rendering acceleration code in X.org with portable, high performance OpenGL. Unfortunately, that goal was hampered by the project starting in the awkward time when folks thought fixed-function hardware was still worth supporting. But, according to Keith Packard, the last few months have seen the code modernized and finally maturing as a credible replacement for many of the hardware-specific 2D acceleration backends. From his weblog: "Fast forward to the last six months. Eric has spent a bunch of time cleaning up Glamor internals, and in fact he’s had it merged into the core X server for version 1.16 which will be coming up this July. Within the Glamor code base, he's been cleaning some internal structures up and making life more tolerable for Glamor developers. ... A big part of the cleanup was a transition all of the extension function calls to use his other new project, libepoxy, which provides a sane, consistent and performant API to OpenGL extensions for Linux, Mac OS and Windows." Keith Packard dove in and replaced the Glamor acceleration for core text and points (points in X11 are particularly difficult to accelerate quickly) in just a few days. Text performance is now significantly faster than the software version (not that anyone is using core text any more, but "they’re often one of the hardest things to do efficiently with a heavy weight GPU interface, and OpenGL can be amazingly heavy weight if you let it."). For points, he moved vertex transformation to the GPU getting it up to the same speed as the software implementation. Looking forward, he wrote "Having managed to accelerate 17 of the 392 operations in x11perf, it’s pretty clear that I could spend a bunch of time just stepping through each of the remaining ones and working on them. Before doing that, we want to try and work out some general principles about how to handle core X fill styles. Moving all of the stipple and tile computation to the GPU will help reduce the amount of code necessary to fill rectangles and spans, along with improving performance, assuming the above exercise generalizes to other primitives." Code is available in anholt's and keithp's xserver branches.

11 of 46 comments (clear)

  1. Reminder by Anonymous Coward · · Score: 2, Funny

    X11 is the Iran-Contra of graphical user interfaces.

    1. Re:Reminder by red_dragon · · Score: 4, Funny

      So do I. Before I start the X server I put my Quaker hat on and then say "HA! HA! I AM USING X11!" and everyone around looks at me saying "WTF is this weirdo talking about?" so I have to put the hat away and shut up. Nobody appreciates good software and hats these days.

      --
      In Soviet Russia, Jesus asks: "What Would You Do?"
    2. Re:Reminder by Ford+Prefect · · Score: 2

      I dunno, I always get a big belly laugh whenever I log into something and see that horrible 1980s B&W X11 desktop, complete with ugly 'X' cursor.

      Try flying on a Virgin America plane with the LCD screen inflight entertainment systems in the seat-backs. They'll often mass-reboot the things before or after a flight, briefly revealing that retro-fantastic, monochrome stippled background with 'X' cursor...

      --
      Tedious Bloggy Stuff - hooray?
  2. Vs compositing? by Anonymous Coward · · Score: 3, Interesting

    I wonder, how does it relate to compositing engine? Ain't surfaces already drawn using GPU accelerated function when using GL-based compositing ?

    1. Re:Vs compositing? by fnj · · Score: 2

      I wonder, how does it relate to compositing engine? Ain't surfaces already drawn using GPU accelerated function when using GL-based compositing ?

      I would like to know this too. And not just with megabuck megawatt GPUs, but with something reasonable like Intel HD2000, 3000, and 4000.

    2. Re:Vs compositing? by Gaygirlie · · Score: 3, Interesting

      I wonder, how does it relate to compositing engine? Ain't surfaces already drawn using GPU accelerated function when using GL-based compositing ?

      The windows themselves should be drawn via the GPU on a modern compositing engine, sure, but the window - contents themselves have nothing to do with compositing managers; an app, depending on what UI-toolkit it uses, may be drawing its buttons and text-entries and scrollbars and whatnot via software, H/W-accelerated and somewhat outdated 2D-acceleration, or via the 3D-engine. Many drivers these days don't bother even trying to support the whole range of 2D-accelerated methods and some drivers don't bother supporting such at all, so the toolkits that still use these methods basically fall back to software-rendering.

  3. Yay! by buchner.johannes · · Score: 3, Insightful

    Cheers to the heros working on improving X. It's probably the most important piece of software on GNU/Linux. Real hackers working there on the most complex issues.

    --
    NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
  4. Eagerly awaiting ickle benchmarks by pavon · · Score: 4, Interesting

    The cairo-ickle blog has maintained very interesting benchmarks of the different cairo rendering backends. The short story is that every hardware accelered backend except for sandybridge SNA has performed worse than the software implementation. And in some cases the hardware acceleration is significantly less stable. I'm curious to see if this finally pushes Glamor over the hump and makes it faster than the software path.

    1. Re:Eagerly awaiting ickle benchmarks by Chemisor · · Score: 4, Interesting

      I wonder if the differences are due to extracting the result from the GPU. There is no doubt whatsoever that doing 2D with OpenGL on the GPU will be faster than a software rasterizer - what kills the performance in these tests is having to copy the result back to the CPU so it can be displayed in an X window. Once X windows are fully composited and output graphics never leave the GPU memory, the hardware acceleration will no doubt prove to be the fastest.

  5. Re:Why? by squiggleslash · · Score: 4, Insightful

    The concept, as I understand it, is that at the moment in order to write a device driver for X11 you have to separately manage code that implements 2D and 3D graphic primitives. Given 2D operations are themselves a subset of 3D operations (even if the API doesn't reflect that), it makes sense to simply have device drivers implement the 3D parts. Then common wrapper code can implement the 2D, alleviating the driver developer of the burden of building and testing an entirely new block of code.

    It should make X.org more reliable, as the same 2D code will be used for all drivers, and should end up being pretty solid. In the mean time, driver developers have more time to polish their 3D driver implementations. Win win. Maybe a slight performance hit, but probably not a significant one.

    --
    You are not alone. This is not normal. None of this is normal.
  6. Even better... by morgauxo · · Score: 2

    I'll use X until it is pried from my cold dead hands. Or until Wayland has network transparency at least on par with X. Whichever happens first.

    Recently I was re-installing my desktop (Gentoo) from scratch and decided to have a go at not installing any big heavy desktop environment. I already used Ratpoison when I am connected over VNC and have memorized most of the key combos so I thought I would try Ratpoison on the local desktop. Completely banishing KDE I switched from KDM to XDM.

    I still have a stock XDM config. I think it's hilarious seing that 80s vintage login on an almost modern machine and having it lead to perfectly up to date applications. Maybe some day I will take the time to pretty it up. I have seen screen shots that show XDM can be made to look nice. But... it's only there until I log in. Why bother?