Announcement

Collapse
No announcement yet.

GLAMOR Acceleration Continues To Be Cleaned Up

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

  • #11
    Originally posted by slacka View Post
    A few weeks ago I tried out GLAMOR Acceleration on my Intel Sandybridge because it was supposed to be the future of 2D acceleration. I was horrified with the results. Battery usage and CPU usage were all up while 2D performance suffered.

    If your hardware has a dedicated 2D accelerator, you're much better off using that than the inefficient general purpose GPU. As much as I love wayland, its lack of support for 2D acceleration, except through GLAMOR, is a major downside.
    Wayland doesn't support any rendering API by itself, neither 2D nor 3D - it glues applications, which render using whatever method they prefer, and the compositor, which puts what they draw on the screen. That was one of its design goals: to completely move rendering away from the server. X has long provided a 2D rendering API (is it XRender?), which does not suit modern applications, but still has to be supported - even if X is abandoned, some applications will still have to be run through XWayland. Traditional implementations of this API (e.g. EXA, UXA, SNA) work directly over the hardware, which implies duplicating resources, because that is already done in Mesa.

    There are -or there could be- better 2D APIs than XRender, which, moreover, were not tied to a particular display system (for example, OpenVG). They could be implemented as Gallium state trackers, which would mean using 3D resources (but much more efficiently than GLAMOR; it would be comparable to using Wine with the Nine state tracker vs Wine's Direct3D-to-OpenGL translation layer), or directly over the hardware, as those traditional -and difficult to maintain- DDXs. I believe, however, that GPUs haven't included a 2D engine for some time, so most of the optimizations come from knowing whether it would be worth to upload things to the GPU or it would just be better to do them in the CPU.

    GLAMOR, being a generic implementation of XRender, avoids the effort of maintaining two graphic implementations. I don't know if it could ever be as fast as SNA, but I doubt it. However, its main targets are not already-supported GPUs, but those which aren't (AMD's GCN,...) and for which writing dedicated implementations would be time consuming, and XWayland - which, for some reason I don't remember, doesn't support using the hardware directly. So GLAMOR isn't the "future of 2D acceleration", but rather the "last life preserver" for those X-only applications: the less time that's spent with that condemned thing that is X, the better, because it's time spent with a non-monolithic, more future-proof stack. (X will still be used for some years in some places, but in those places there won't be any new GPU, so not implementing XRender over bare-hardware for those chips is not a problem). Under Wayland, I guess Cairo or perhaps OpenVG would be used for 2D -and Cairo leverages OpenGL or OpenVG, see the list of its backends-, so such duplication isn't needed - all graphics implementations would be in Mesa, which is where they belong.

    Performance should be better with Wayland. And, as said, 2D APIs not tied to a particular display system could still be implemented directly over the hardware, which could mean delivering even more performance.

    Comment


    • #12
      Originally posted by nanonyme View Post
      Which distro version and how recent drivers? The Intel Glamor version you were using may just not yet be properly optimized
      I was testing with Arch Linux and Mesa 10.4, so outdated drivers was not the issue.


      kalrish,

      Excellent explanation. Hopefully you're right and better 2D APIs in the future will make GLAMOR's inefficiency a moot topic.

      Comment


      • #13
        Originally posted by slacka View Post
        I was testing with Arch Linux and Mesa 10.4, so outdated drivers was not the issue.
        I don't think the intel driver glamor rewrite has made it into master yet, it's still sitting in a private branch.

        Of course, I have no idea if that will actually speed things up or not.

        Comment


        • #14
          Originally posted by smitty3268 View Post
          I don't think the intel driver glamor rewrite has made it into master yet, it's still sitting in a private branch.

          Of course, I have no idea if that will actually speed things up or not.
          Well, the article did talk about massive removing of software fallbacks and replacing them with proper hardware-accelerated implementations. It will most likely make Glamor be more than a proof of concept and actually fast on Intel like it already has been for radeon and nouveau

          Comment

          Working...
          X