Announcement

Collapse
No announcement yet.

Christmas Comes In July For An Open ATI

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

  • #31
    @pheldens: This code does kernel modesetting. Meaning you have full modesetting support from kernel init to halt. Also meaning no more suspend/resume issues, because that can be handled cleanly in the kernel. Oh, and you don't have to use X to take adavantage of it.

    Comment


    • #32
      New atombios parser :

      Last year part of the initial documentation drop was the information and interpreter code required to make use of the command tables in AtomBIOS. The interpreter was written in C and allowed the BIOS code to be written in a portable bytecode language so that BIOS calls could be made without trapping back to 16-bit real mode x86 or running an x86 emulator.

      There were some complaints about the code we released initially, mostly (a) compiler warnings because the code was written for our internal development environments not the open source envirotnment, and (b) the way the code was written meant that big changes would be needed to let it be used in the kernel.

      Alex ran across this code when we were working with some of the hardware design groups -- it's basically a rewrite of the AtomBIOS interpreter (aka "parser") designed to go in the kernel. The parser in the current radeon and radeonhd drivers has gone through a lot of production testing while the new parser has only gone through development testing, so it's not ready to just drop into radeon and radeonhd as a replacement, but it is useful to help kernel modesetting move ahead.

      Kernel modesetting :

      Look up Michael's recent article on kernel modesetting (a couple of months ago) for more info, but basically this is the first step to having all graphics control done by a single driver in the kernel, rather than switching back and forth between different drivers when doing vt switching, suspend/resume or even boot up. Incompatibilities between the kernel and X drivers is one of the primary pain points for vt switch and suspend/resume in Linux today; KMS is about having a single driver that everyone uses including X. The other nice thing is that KMS makes it possible for X to run without root privileges, which over time should help to make the whole system more stable. There are conflicting views about KMS, of course -- mostly the usual tradeoff between the problems it solves and the new problems it brings -- but it certainly offers the promise of putting all of the vt switch issues and many of the suspend/resume issues behind us for good.

      Quick & dirty accel branch merge into radeonhd master :

      This merges in a fresh copy of acceleration code from radeon, which brings full EXA render, textured video support, and allowing 2d and 3d to run at the same time. Anyone with a 690 or 5xx should give it a try.

      jlward4th, I think Egbert enabled the scaler in radeonhd a month or two ago, wouldn't hurt to check.
      Last edited by bridgman; 07-27-2008, 12:47 PM.

      Comment


      • #33
        KMS is about having a single driver that everyone uses including X
        i do hope that KMS drivers will provide a replacement for current framebuffer drivers, like (u)vesafb, etc.

        how is that thing going to be worked out?

        Comment


        • #34
          I think it's pretty much guaranteed that there will be console drivers, or else there wouldn't be much point in KMS, would there? Basically, I think the console driver will just be a shim redirecting to the KMS driver.

          Comment


          • #35
            i was rather worried what's going to happen to old fb drivers. are they going to be dropped? what about the generic vesa fb drivers - will there be a generic vesa KMS driver as well?

            Comment


            • #36
              I don't think any drivers will disappear, fb drivers still are useful like in boot time, and VESA has to remain as a fallback driver

              Comment


              • #37
                A generic VESA KMS would make a fair amount of sense, but I haven't heard anyone talk about it yet. I must say, good idea yohsi!

                Comment


                • #38
                  anyone got a basic howto on what to build/where patches are etc? And anyone know how stable it is? Is it usable on a day to day system?

                  Comment


                  • #39
                    Where to get it depends on your distro. On Gentoo you use the x11 overlay.

                    I'm using xf86-video-ati from Git on an X1950XT for over a week now without a single crash. It's very promising.

                    Comment


                    • #40
                      Originally posted by RealNC View Post
                      Where to get it depends on your distro. On Gentoo you use the x11 overlay.

                      I'm using xf86-video-ati from Git on an X1950XT for over a week now without a single crash. It's very promising.
                      Yeah I'm already on git pretty much everything, but I wanted to try the KMS patch

                      Comment


                      • #41
                        So I've just pushed my initial radeon kms code to the "gem-modesetting" branch of the drm git tree.
                        The corresponding DDX code is in the radeon-gem-ms branch of my personal xf86-video-ati repo.
                        http://airlied.livejournal.com/

                        So I think that would be :

                        DRM - mesa/drm, "gem-modesetting" branch
                        X driver - users/airlied/xf86-video-ati, "radeon-gem-ms" branch

                        Dave might pop in and say more but I would consider it highly experimental for now.
                        Last edited by bridgman; 07-30-2008, 11:44 AM.

                        Comment


                        • #42
                          So that means the difference between radeonhd and radeon will be even less now, if I understand correctly, the only *real* differences will be 2D acceleration and video acceleration.

                          It would be awesome if fglrx could be stripped down to a replacement DRI interface, that way ATi's hidden 3D features could be utilized without their buggy DDX

                          Comment


                          • #43
                            Originally posted by TechMage89 View Post
                            A generic VESA KMS would make a fair amount of sense, but I haven't heard anyone talk about it yet. I must say, good idea yohsi!
                            I think you misunderstand what VESA is. It is a common interface for graphics cards.

                            Kernel Modesetting uses the card's proprietary wake up sequence to initialize it into a state where its full capabilities can be used.

                            VESA, being the common denominator for graphics cards, is a generic interface for graphics cards.

                            These two are inherently different, and as I see it, mutually exclusive.

                            Comment


                            • #44
                              No, I don't misunderstand, and no, they are not mutually exclusive.

                              VESA is a common interface for graphics cards for modesetting as a fallback option. However, there still needs to be a driver to communicate with the graphics card using VESA. Right now, there are separate kernel and X drivers to do the task. This involves duplication of code, slow terminal to X switching, and much of the other ugly stuff involved in this. A VESA KMS module would provide modesetting support for both the framebuffer and for X, and give *some* of the benefits of not having a separate X driver (like for example, not having to run X as root.)

                              In short, if we want the KMS way to be universal, we need a fallback interface, so that things don't get fouled up if a card is not supported. Basically, we need to make a VESA KMS.

                              Comment

                              Working...
                              X