Announcement

Collapse
No announcement yet.

X.Org is the new kernel

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

  • #16
    Sorry to flood the topic, but I just tried xrender on kwin4 and I have to say that's freaking kool! I can get all that effects (exposŤ, show desktop, dim inactive, translucency, and even desktop grid) without a 3d driver at all (tested with nv driver)

    here a shot: http://puelocesar.deviantart.com/art...top-4-88502608

    The only thing I miss is the shadows, but Lubos Lunak commited this month a patch that solves the problem Just need to wait for 4.1 beta2 now

    Well, thanks for the people here who opened my eyes to this solution I'm pretty happy right now with my linux box

    Comment


    • #17
      Originally posted by avilella View Post
      Hi, I think now that we have a kernel that is pretty much the most advanced kernel in the world, what the OSS community needs is to make X.Org the best in the world as well.
      Would you trust the people who will not let Reiser4 into the kernel, not only have control over filesystems, but also have control of graphics drivers.

      The Linux saboteurs (see http://www.phoronix.com/forums/showthread.php?t=9509) have sabotaged Linux's best filesystem. What makes you think they will not sabotage graphics drivers as well.

      But maybe it doesn't matter, as the open source graphics drivers are already completely sabotaged (and have been for many years).

      Comment


      • #18
        What Xorg needs is to be useful enough to graphics driver developers that they don't feel the need to reimplement parts of Xorg inside their drivers.

        What is up with that anyway? I've heard the nVidia driver has its own internal alternatives to all kind of Xorg stuff. And Intel having to write GEM to replace TTM... Was Xorg just not designed for 3D or something?
        Last edited by StringCheesian; 06-13-2008, 09:31 AM.

        Comment


        • #19
          Originally posted by Jade View Post
          Would you trust the people who will not let Reiser4 into the kernel, not only have control over filesystems, but also have control of graphics drivers.

          The Linux saboteurs (see http://www.phoronix.com/forums/showthread.php?t=9509) have sabotaged Linux's best filesystem. What makes you think they will not sabotage graphics drivers as well.

          But maybe it doesn't matter, as the open source graphics drivers are already completely sabotaged (and have been for many years).
          Why must you spam that link whenever something to do with the kernel comes up. It's pointless the few people who actually want to read your "theories" know where to go so you don't need to keep pointing it out.

          Comment


          • #20
            What Xorg needs is to be useful enough to graphics driver developers that they don't feel the need to reimplement parts of Xorg inside their drivers.

            What is up with that anyway? I've heard the nVidia driver has its own internal alternatives to all kind of Xorg stuff. And Intel having to write GEM to replace TTM... Was Xorg just not designed for 3D or something?
            That's pretty much the case -- Xorg was not designed for modern 3d -- but most of the work going on right now is intended to improve the integration between X (which has been primarily 2d) and 3d (which has primarily been used through DRI for the last 10 years). DRI largely operates outside X (for speed) but has just enough hooks (the DRI infrastructure) to keep it in sync with what X is doing.

            AIGLX (and to a lesser extent XGL) were very important steps to start moving the DRI and X worlds closer together. The remaining steps are underway now, but yes there is debate about all of them ;

            - memory management needs to move from X into the kernel driver (drm) and become more versatile so that 3d and 2d can share memory buffers more effectively (TTM, GEM)

            - either applications need to stop using direct rendering and switch to using AIGLX instead (slight performance hit) or DRI needs to be extended to allow the use of DRI to continue but have the application windows all move around together (DRI2, RDR)

            There are other initiatives underway to make other aspects of the user experience better (Gallium gives us a newer, faster, and more versatile 3d driver, kernel modesetting makes seamless graphics and reliable suspend/resume/vt switch much easier) but the two above are the main ones for bringing 3d and X closer together.

            Comment


            • #21
              Originally posted by Aradreth View Post
              Why must you spam that link whenever something to do with the kernel comes up. It's pointless the few people who actually want to read your "theories" know where to go so you don't need to keep pointing it out.
              oh! let him write what ever he wants! we live in democracy (somehow), so everyone can say what he thinks!

              ....and he is so funny!!! :-D

              Comment


              • #22
                Originally posted by Vighy View Post
                oh! let him write what ever he wants! we live in democracy (somehow), so everyone can say what he thinks!

                ....and he is so funny!!! :-D
                So you think it is funny that various parts of Linux have (obviously) been sabotaged?

                Comment


                • #23
                  Originally posted by Jade View Post
                  So you think it is funny that various parts of Linux have (obviously) been sabotaged?
                  No that's horrible (if it's proved), it's funny the strength of your conviction :-)
                  I love to read all your posts... that's why it's funny! :-P

                  ...and, as a ReiserFS estimator I would like to see Reiser4 fixed and in the mainstream, too.

                  Comment


                  • #24
                    Any comparison to Quartz right now would be dated. 10.6 has some pretty radical changes coming under the hood.

                    Comment


                    • #25
                      Originally posted by bridgman View Post
                      - either applications need to stop using direct rendering and switch to using AIGLX instead (slight performance hit) or DRI needs to be extended to allow the use of DRI to continue but have the application windows all move around together (DRI2, RDR)
                      This is a very interesting point that hasn't been covered in much detail in Phoronix. What is the state of AIGLX? I remember Redhat/Fedora went the AIGLX way when it started years ago, and there was a bit of a dichotomy for a while between AIGLX and XGL(?), but I haven't seen any more news in Phoronix recently. What do you mean by "have the application windows all move around together"?

                      Comment


                      • #26
                        Originally posted by avilella View Post
                        This is a very interesting point that hasn't been covered in much detail in Phoronix. What is the state of AIGLX? I remember Redhat/Fedora went the AIGLX way when it started years ago, and there was a bit of a dichotomy for a while between AIGLX and XGL(?), but I haven't seen any more news in Phoronix recently. What do you mean by "have the application windows all move around together"?
                        What I was *trying* to say was that Redirected Direct Rendering (which uses DRI2 and a memory manager) is the next step in letting 2D and 3D windows be composited together.

                        I have no idea what "all move around together" means, other than that I need to stop posting before the coffee kicks in.

                        Comment


                        • #27
                          Originally posted by bridgman View Post
                          What I was *trying* to say was that Redirected Direct Rendering (which uses DRI2 and a memory manager) is the next step in letting 2D and 3D windows be composited together.

                          I have no idea what "all move around together" means, other than that I need to stop posting before the coffee kicks in.
                          Just to clean up a little bit.

                          The first thing to realize is that what is fundamental to a complete compiz (or any other compositing manager) is full COMPOSITE extension support for *all* parts of the driver. That is why the application is called compiz, and they are called compositing managers.

                          When COMPOSITE is enabled, applications are expected to render to an off-screen window surface. The compositing manager can then rendezvous with these offscreen surfaces and combine them in any way that they want.

                          The *all* parts of the driver includes 2D, 3D an video. 2D is easy, for example, XAA falls back to SW. Xv has some information in the callbacks for the buffer to render to, but then comes 3D. 3D currently renders to where it believes the window _should be_. This means it renders to the pixels on the screen, then compiz renders, then the 3D app renders. When you apply the transforms like the cube and wobbly windows, the app doesn't get new window information until after the transform is complete. The transform itself quite happily renders a blank window (assuming that the contents come from the app).

                          AIGLX is technically not required for compiz, but for DRI based drivers, it is the simplest path for getting the window contents into an OpenGL texture.

                          Now with DRI in it's current form, getting this buffer (or redirect buffer as some call it) is very difficult (but not impossible) to achieve.

                          DRI2 includes sufficient infrastructure to make this possible, an advance memory manager (GEM, TTM, etc) is also needed to allow buffer information to be shared throughout the driver.

                          (I believe that "Following the Window around" means that GL application is included in the wobbly windows or cube rotation. This is the user-experience - beyond the pixel fighting that occurs between GL and compiz - sometimes called flashing. The redirected direct rendering does push the rendere content into the window. Due to the confusion brought in by redirected direct rendering vs hw accelerated indirect rendering I tend to use the term OpenGL support for COMPOSITE when talking about this.

                          Regards,

                          Matthew

                          Comment


                          • #28
                            Ahh yes, that's what I meant

                            Comment


                            • #29
                              Originally posted by mtippett View Post
                              Just to clean up a little bit.

                              The first thing to realize is that what is fundamental to a complete compiz (or any other compositing manager) is full COMPOSITE extension support for *all* parts of the driver. That is why the application is called compiz, and they are called compositing managers.

                              When COMPOSITE is enabled, applications are expected to render to an off-screen window surface. The compositing manager can then rendezvous with these offscreen surfaces and combine them in any way that they want.

                              The *all* parts of the driver includes 2D, 3D an video. 2D is easy, for example, XAA falls back to SW. Xv has some information in the callbacks for the buffer to render to, but then comes 3D. 3D currently renders to where it believes the window _should be_. This means it renders to the pixels on the screen, then compiz renders, then the 3D app renders. When you apply the transforms like the cube and wobbly windows, the app doesn't get new window information until after the transform is complete. The transform itself quite happily renders a blank window (assuming that the contents come from the app).

                              AIGLX is technically not required for compiz, but for DRI based drivers, it is the simplest path for getting the window contents into an OpenGL texture.

                              Now with DRI in it's current form, getting this buffer (or redirect buffer as some call it) is very difficult (but not impossible) to achieve.

                              DRI2 includes sufficient infrastructure to make this possible, an advance memory manager (GEM, TTM, etc) is also needed to allow buffer information to be shared throughout the driver.

                              (I believe that "Following the Window around" means that GL application is included in the wobbly windows or cube rotation. This is the user-experience - beyond the pixel fighting that occurs between GL and compiz - sometimes called flashing. The redirected direct rendering does push the rendere content into the window. Due to the confusion brought in by redirected direct rendering vs hw accelerated indirect rendering I tend to use the term OpenGL support for COMPOSITE when talking about this.

                              Regards,

                              Matthew
                              You forgot that the GLX_EXT_texture_from_pixmap extension is also required

                              Comment


                              • #30
                                another feature that Phoronix could delve into is "resolution independence". Both OS X and Windows have been improving this feature in recent releases. What is the current state of resolution independence in X.org applications?

                                Comment

                                Working...
                                X