Announcement

Collapse
No announcement yet.

ATI's X.Org DDX Driver Gets KMS Ready

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

  • ATI's X.Org DDX Driver Gets KMS Ready

    Phoronix: ATI's X.Org DDX Driver Gets KMS Ready

    With the forthcoming Linux 2.6.31 kernel there is finally Radeon kernel mode-setting support so that those running ATI graphics cards on Linux will be able to experience a cleaner boot process, faster VT switching, improved security, and other overdue features for Linux. Using kernel mode-setting with ATI Radeon hardware will require a supported kernel that is built with the appropriate kernel configuration options. In addition, an updated DDX driver is also necessary so it realizes the kernel is handling the mode-setting process...

    http://www.phoronix.com/vr.php?view=NzM1Ng

  • #2
    So this is a vital patch before KMS for R600 and R700 can be implemented?

    Comment


    • #3
      Originally posted by Louise View Post
      So this is a vital patch before KMS for R600 and R700 can be implemented?
      This was required before ANY radeon card could use KMS, both R600+ and the older generations. I believe the stuff that isn't working just for the newer cards is in the kernel and Mesa codebases. Not sure about DRM.

      Comment


      • #4
        The transition to KMS should be quite straight-forward, as it has been enabled in Fedora for a year now, providing a pretty long testing time frame.

        Comment


        • #5
          Originally posted by smitty3268 View Post
          This was required before ANY radeon card could use KMS, both R600+ and the older generations. I believe the stuff that isn't working just for the newer cards is in the kernel and Mesa codebases. Not sure about DRM.
          I see

          It would be nice with a dependency tree. E.g.

          Code:
          KMS -> 3D -> Power Management
          ... and all the other stuff at
          http://www.x.org/wiki/RadeonFeature

          Comment


          • #6
            I've just tried this out and it didn't work well !
            I didn't take the time to figure out why, just wanted to say recompiling was not sufficient for me.

            I've fall back on the kms branch that kind of "works".

            Comment


            • #7
              Originally posted by Louise View Post
              It would be nice with a dependency tree.
              As I understand it:

              possible to work on now:
              r600+ 3D (OpenGL1.4)
              video acceleration (shader, not UVD2)
              power management (already in master branch)

              memory manager -> KMS
              memory manager -> DRI2
              memory manager -> Gallium

              Gallium -> more advanced 3D (OpenGL2.0+)
              Gallium -> generic video acceleration framework

              KMS -> more advanced power management

              Comment


              • #8
                AFAICS this patch merges some of the existing KMS support into master. Kernel and mesa support have already been merged (2.6.31 for the kernel, radeon-rewrite merge for mesa), so once this merge is done all the big pieces for KMS support will be in their respective master trees.

                I don't think this does anything specific for 6xx/7xx but it does mean that work can now be based on master rather than on another branch, which is really nice.

                Smitty3268, I made a few minor changes, see below. Otherwise your list looks good.

                memory manager -> KMS
                memory manager -> DRI2 / RDR (RDR is what everyone really wants)
                memory manager -> Gallium3D
                memory manager -> more advanced 3D (OpenGL 1.5+) via chip-specific code

                Gallium3D -> more advanced 3D (OpenGL 1.5+) via generic code
                Gallium3D -> generic video acceleration framework

                KMS -> more advanced power management (dynamic control of clocks etc..)
                Last edited by bridgman; 06-30-2009, 11:38 PM.

                Comment


                • #9
                  Originally posted by MPF View Post
                  I've just tried this out and it didn't work well !
                  I didn't take the time to figure out why, just wanted to say recompiling was not sufficient for me.

                  I've fall back on the kms branch that kind of "works".
                  The commit in question, which was applied to master, does not provide KMS support. It is just some preparations for the final KMS patch to land later. So you will still have to use the kms-support branch for a while.

                  Comment


                  • #10
                    If I combine the brances on the dependency tree, it becomes
                    Code:
                    memory manager -+-> KMS -> more advanced power management (dynamic control of clocks etc..)
                                    |
                                    +-> DRI2 / RDR (RDR is what everyone really wants)
                                    |
                                    +-> more advanced 3D (OpenGL 1.5+) via chip-specific code
                                    |
                                    +-> Gallium3D -+-> more advanced 3D (OpenGL 1.5+) via generic code
                                                   |
                                                   +-> generic video acceleration framework
                    Edit: branch 1 and 3 are not the same My bad

                    But can I ask where these go on the tree?:

                    * OpenCL
                    * TV-out
                    * GLSL
                    * Display Port
                    Last edited by Louise; 07-01-2009, 09:29 AM.

                    Comment


                    • #11
                      Looking good.

                      - OpenCL depends on Gallium3D

                      - TV-out is just a big pain in the butt and doesn't depend on anything other than a big heap of free time

                      - I would treat GLSL as part of "more advanced 3D", ie it could happen in classic mesa but will probably only happen on Gallium3D

                      - display port doesn't depend on anything

                      Comment


                      • #12
                        Originally posted by bridgman View Post
                        Looking good.
                        So when people ask "when will we get OpenCL" this can be pasted in as reply
                        Code:
                        memory manager -+-> KMS -> advanced power management (dynamic control of clocks etc..)
                                        |
                                        +-> DRI2 / RDR (RDR is what everyone really wants)
                                        |
                                        +-> advanced MESA 3D (OpenGL 1.5+) via chip-specific code
                                        |
                                        +-> Gallium3D -+-> advanced 3D (OpenGL 1.5+, GLSL) via generic code
                                                       |
                                                       +-> generic video acceleration framework
                                                       |
                                                       +-> OpenCL
                        No dependencies:
                        * TV-out
                        * Display Port

                        Originally posted by bridgman View Post
                        - TV-out is just a big pain in the butt and doesn't depend on anything other than a big heap of free time
                        When AMD started to make their own north- and south-bridges, I read an interview where someone from AMD was asked, why their south bridges didn't have an AMD developed sound codec.

                        The answer was something like: "The devil is on the analogue side, and we have no plans on waking him".

                        Is that also the problem with TV-out?


                        Originally posted by bridgman View Post
                        - I would treat GLSL as part of "more advanced 3D", ie it could happen in classic mesa but will probably only happen on Gallium3D
                        Because the API's are cleaner on Gallium3D?

                        Comment


                        • #13
                          Originally posted by Louise View Post
                          When AMD started to make their own north- and south-bridges, I read an interview where someone from AMD was asked, why their south bridges didn't have an AMD developed sound codec.

                          The answer was something like: "The devil is on the analogue side, and we have no plans on waking him".

                          Is that also the problem with TV-out?
                          I don't think so -- in theory we know how to program it, but it's not working and debugging takes a long time. We'll probably have to dig through the fglrx source code to see what is done there, but that is a non-trivial task as well.

                          Originally posted by Louise View Post
                          (regarding GLSL) Because the API's are cleaner on Gallium3D?
                          Mostly because the GLSL compiler work can (in theory) be "done once" and used across multiple GPU families, where GLSL gets compiled to TGSI by common code then each driver only needs to convert TGSI into GPU-specific instructions.

                          Yes there's a lot of "in theory" here
                          Last edited by bridgman; 07-01-2009, 11:51 AM.

                          Comment


                          • #14
                            Originally posted by bridgman View Post
                            I don't think so -- in theory we know how to program it, but it's not working and debugging takes a long time. We'll probably have to dig through the fglrx source code to see what is done there, but that is a non-trivial task as well.
                            Sounds a lot like the "GURU Meditation" from the Amiga

                            From http://en.wikipedia.org/wiki/Guru_Meditation
                            Early in the development of the Amiga computer operating system, the company's developers became so frustrated with the system's frequent crashes that, as a relaxation technique, a game was developed where a person would sit cross-legged on the joyboard, resembling an Indian guru. The player was supposed to remain perfectly still with the goal of the game being to stay still the longest. If the player moved, a "guru meditation error" resulted.
                            Originally posted by bridgman View Post
                            Mostly because the GLSL compiler work can (in theory) be "done once" and used across multiple GPU families, where GLSL gets compiled to TGSI by common code then each driver only needs to convert TGSI into GPU-specific instructions.

                            Yes there's a lot of "in theory" here
                            Impressive.

                            Sounds like someone could pitch a job in the industry, if they made this their thesis

                            Comment


                            • #15
                              Originally posted by Louise View Post
                              Sounds a lot like the "GURU Meditation" from the Amiga
                              Interesting; I didn't know about Guru Meditation Errors.

                              Finding something in a large piece of software like the proprietary driver reminds me of a short story I read a long time ago. If I remember correctly, it involved an infinite number of monkeys with typewriters, an angel cast out from Paradise and tasked with supervising said monkeys, and a block of granite a parsec or so on each side. Every 1000 years a small bird would stop by and sharpen its beak on the block, gradually wearing down the block and providing a way to measure the passage of time.

                              EDIT - found it - "Been a long, long time" by R. A. Lafferty. There is an xkcd comic in a similar vein, but it's not as good : http://xkcd.com/505/

                              Originally posted by Louise View Post
                              Impressive. Sounds like someone could pitch a job in the industry, if they made this their thesis
                              True. The best news, though, is that the work has (in theory) already been done and is (in theory) working on Intel 915 parts. I imagine it still needs some work though, or I would have expected the Intel devs to jump across to Gallium3D immediately (since GEM and DRI2 are already available).
                              Last edited by bridgman; 07-01-2009, 02:46 PM.

                              Comment

                              Working...
                              X