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; 27 July 2008, 12:47 PM.
      Test signature

      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

                      Working...
                      X