Announcement

Collapse
No announcement yet.

X.Org 7.5 Released. Wait, Nope!

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

  • #16
    Originally posted by getaceres View Post
    Is it so difficult to have simple alpha blending without hardware acceleration in a 2GH+ machine? Most of the simple effects in Mac OS X like translucency work at full speed without hardware acceleration. Windows had Alpha Blending since Windows 2000 and it was quick even without hardware acceleration. ¿Why then Xorg needs a full 3D graphic card just to let a window know what is behind it? ¿Why does Xorg feel so slow compared to OSX and Windows even with the fastest graphic card?
    I suppose that those problems are due to X being almost completely userland right now. OS X and Windows do a lot of the GUI stack in the kernel. If I understand correctly, this is going to change "soon", with KMS and GEM, which hopefully will up the GUI performance a lot.

    Comment


    • #17
      Originally posted by getaceres View Post
      It must die or it must be rewritten from the ground up .... XRender that actually accelerates (instead of decelerating) the rendering? ¿Have you seen that QT 4.5 using raster rendering (software) is much much faster than using native rendering (XRender)? ¿Is it so difficult to have simple alpha blending without hardware acceleration in a 2GH+ machine? Most of the simple effects in Mac OS X like translucency work at full speed without hardware acceleration. Windows had Alpha Blending since Windows 2000 and it was quick even without hardware acceleration. ¿Why then Xorg needs a full 3D graphic card just to let a window know what is behind it?
      So basically your only problem is performance?! Well, when using XAA you get composition without hw accaleration and it should work as well as it does on OSX.

      After all this is more or less a problem with drivers and the way drivers are written. There are no state-trackers and usually per-primitive overhead is quite high.

      Here Gallium3D could make a real difference.

      ¿Why does Xorg feel so slow compared to OSX and Windows even with the fastest graphic card?
      ¿Can you solve all these problems with Xorg keeping the 20 years old code while solving in a small amount of time the future challenges that may arise in the near future? In the past Xfree didn't keep up with the rest of the graphic systems and, although Xorg implemented some of these features that were missing for long, they are implemented in a slow, semi working fashion.
      You are quite unspecific. Does xorg feel slow, or the applications and toolkits using it?
      Have you thought about toolkits doing stupid things? E.g. I've just reported a problem to trolltech where XRender was used in a very inefficient way for non-aa rendering in QT.
      Which features have been implemented slow and semi working, except XRender (which has been mostly fixed recently)?

      - Clemens
      Last edited by Linuxhippy; 04-01-2009, 10:58 AM.

      Comment


      • #18
        Originally posted by RealNC View Post
        I suppose that those problems are due to X being almost completely userland right now. OS X and Windows do a lot of the GUI stack in the kernel. If I understand correctly, this is going to change "soon", with KMS and GEM, which hopefully will up the GUI performance a lot.
        X still will run in userspace, so KMS and GEM won't make a lot of difference for typical 2D applications.

        - Clemens

        Comment


        • #19
          Originally posted by Linuxhippy View Post
          X still will run in userspace, so KMS and GEM won't make a lot of difference for typical 2D applications.

          - Clemens
          Why not? KMS moves the X driver to the kernel.

          Comment


          • #20
            Originally posted by RealNC View Post
            Why not? KMS moves the X driver to the kernel.
            No, KMS only moves the mode-setting part of the driver into the kernel. Mode setting is usually a very rare event, and has nothing to do with 2D/3D performance.
            GEM moves memory management into kernel, but the whole 2D accaleration code is still running (mostly) in userspace.

            After all, why should it make a difference if the driver is running in userspace or kernel?
            The main problems of bad 2D performance are elsewhere...

            - Clemens

            Comment


            • #21
              Very sad and scary to me the appearance of X.org development lately. I hope things will turn around also. Great article, Michael - I hope it opens some eyes out there.

              Comment


              • #22
                I just want to say how much I appreciate the contributions of those who *are* working on X.org (individuals, Intel, RedHat, etc). Slow development is better than no development at all. Given the difficulty of even casual X hacking, we are lucky to have a team with the knowledge to refactor and improve the core API's.

                Companies looking to contribute could examine what tasks new contributors could take over from the core team, freeing them up to concentrate on major architectural issues.

                Comment


                • #23
                  Originally posted by Linuxhippy View Post
                  1. XOrg is far more than graphics
                  2. Could you explain how Quartz is so much different compared to XRender?

                  I have to agree about the quite ugly code-base, I don't want to predict how a re-write would look like once its has all the features people *depend* on.

                  - Clemens
                  Hi Clemens, I cited Quartz, because when I installed Hackintosh on my machine, it used the Vesa driver, and it was no hw acceleration, but desktop and effects were way faster, smoother and stable then all my linux boxes using official drivers on them (intel and nvidia).

                  About rewrites, I'm a commercial software developer, and every time I have to work on ancient and bugged code, I always notice that it would be much more faster to just throw off the old codebase and write a new one then adapting an archaic, ugly and unmaintainable codebase. But obviously, our projects are *much* smaller then X, so I don't know if that applies..

                  Comment


                  • #24
                    Originally posted by Linuxhippy View Post
                    No, KMS only moves the mode-setting part of the driver into the kernel. Mode setting is usually a very rare event, and has nothing to do with 2D/3D performance.
                    GEM moves memory management into kernel, but the whole 2D accaleration code is still running (mostly) in userspace.

                    After all, why should it make a difference if the driver is running in userspace or kernel?
                    The main problems of bad 2D performance are elsewhere...

                    - Clemens
                    The current acceleration architecture, EXA, is only a stop-gap. See http://en.wikipedia.org/wiki/EXA

                    The long term plan is to move everything to OpenGL. Through Gallium3D, I assume. That is to say, 2D acceleration will be no more; only 3D will exist, with 2D done through 3D rendering.

                    Comment


                    • #25
                      The article was very true, and I like how it was serious at a date like today. I applaud Phoronix

                      Comment


                      • #26
                        Originally posted by 89c51 View Post
                        @Michael

                        What about an interview with Kristian on Wayland and stuff ???

                        That would be great

                        Comment


                        • #27
                          The only current alternative to Xorg is Xfree.. You need to trust me when I state that we're using the better of the two.

                          Xorg needs developers and architects.

                          Comment


                          • #28
                            I suppose the point was to move away from "X" (as in "The X Window System") in general to something else. The core of X is not needed today at all. It's there for the same reasons DOS is still there on Windows :P

                            Comment


                            • #29
                              I heard Linus switched to subversion!

                              Comment


                              • #30
                                Originally posted by RealNC View Post
                                I suppose the point was to move away from "X" (as in "The X Window System") in general to something else. The core of X is not needed today at all. It's there for the same reasons DOS is still there on Windows :P
                                Many have tried to replace X. Until now, all have failed.

                                I dislike X, but mostly for its insane low-level API. Despite its shortcomings, it's versatile, stable and proven (in the API sense).

                                I don't believe a complete rewrite is feasible at this point in time (if it was, someone would have done it). IMHO, they way forward is to strip functionality from X11, bit by bit:

                                KMS is a great first step. I would also like to see input handling moved to the kernel (the kernel APIs are way more sane here!) I don't actually think that will happen (even with XInput2 looking dead in the water), but it would remove a large burden from the Xorg developers. Finally, I would like to see a controlled deprecation and rewrite of the worse and/or duplicated parts of the API.

                                I don't expect that will ever happen, so I've done what every sane person dealing with X11 does: write (or use) an abstraction layer so you don't have to look at its API anymore

                                Edit
                                Question: what is the point of XRender when we have OpenGL? No, really, why not simply design a render and compositing API that uses OpenGL underneath? Is there really something that XRender can do that cannot be done directly or indirectly with OpenGL?
                                Last edited by BlackStar; 04-01-2009, 06:23 PM.

                                Comment

                                Working...
                                X