Announcement

Collapse
No announcement yet.

There's Evergreen KMS Support & More To Test

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

  • There's Evergreen KMS Support & More To Test

    Phoronix: There's Evergreen KMS Support & More To Test

    David Airlie has re-based his drm-radeon-testing tree and there's now a whole lot of new code and features that users can play with and test. The drm-radeon-testing tree is a branch of the Linux kernel and is code for the Radeon DRM area that will ultimately make it into the mainline tree in the Linux 2.6.34 kernel series and later.To be found in drm-radeon-testing right now is new I2C code that supports the hardware I2C engines found on Radeon graphics cards and exposes it to user-space, a PLL algorithm rework, DRM power management support, basic Evergreen "R800" KMS support, and various other fixes and new additions.Like the recent R800 Evergreen in xf86-video-ati DDX support, the kernel mode-setting support lacks IRQ and any acceleration (2D, 3D, X-Video) support at this time for these Radeon HD 5000 series products...

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

  • #2
    many thanks to you Dave !

    Comment


    • #3
      How much time do you think I have to wait for running open source drivers with my 5850?

      Comment


      • #4
        Originally posted by salva84 View Post
        How much time do you think I have to wait for running open source drivers with my 5850?
        That really depends on what you need. The answer would be sometime between "now" and "more than a year"

        as the news says, modesetting should work now. Modesetting + software rendering is enough for a surprisingly huge amount of tasks. But of course you didn't buy a 5850 for software rendering.

        Feature parity with HD4xxx should be reached in two to three months (source), which would mean sometime during april or early may.

        Longer until G3D takes over and enables opengl 3.x, hardware video decode, openCL etc, but I've yet to see any official estimate on that. G3D for r600+ has barely started, even G3D for r300 isn't "done" yet.

        In any case, add another few months until your favourite distro integrates all the new stuff, unless you're planning to manually install GIT versions.

        Comment


        • #5
          Originally posted by rohcQaH View Post
          That really depends on what you need. The answer would be sometime between "now" and "more than a year"

          as the news says, modesetting should work now. Modesetting + software rendering is enough for a surprisingly huge amount of tasks. But of course you didn't buy a 5850 for software rendering.

          Feature parity with HD4xxx should be reached in two to three months (source), which would mean sometime during April or early may.

          Longer until G3D takes over and enables opengl 3.x, hardware video decode, openCL etc, but I've yet to see any official estimate on that. G3D for r600+ has barely started, even G3D for r300 isn't "done" yet.

          In any case, add another few months until your favorite distro integrates all the new stuff, unless you're planning to manually install GIT versions.
          Thanks for your reply. I bought an ATI 5850 for playing games in my Windows partition, so I don't really care the 3D desktop in Linux. I have two monitors, and I only want to work with both of them (impossible with last open drivers I tried). Is that possible now? How? Thanks you again.

          Comment


          • #6
            Doesn't seem to work here. I get a lot of:

            Code:
            [drm:radeon_i2c_xfer] *ERROR* i2c: unhandled radeon chip
            and one of these:

            Code:
            No connectors reported connected with modes
            in my dmesg.

            And this in the Xorg.0.log:

            Code:
            (EE) RADEON(0): No modes

            Comment


            • #7
              airlied again. Wasn't there a thesis that he never reached deep acpi sleep the last weeks? Nice to see even R800 support going on and to be worked at.
              Today I read a news on AMD's Llano which should be probably the first Fusion chip. I wonder which kind of GPU core they will implement. If it's something new and matching the circumstances of being in the APU or if it will be based on some of the known Rxxx.

              Comment


              • #8
                Originally posted by Adarion View Post
                airlied again. Wasn't there a thesis that he never reached deep acpi sleep the last weeks? Nice to see even R800 support going on and to be worked at.
                Today I read a news on AMD's Llano which should be probably the first Fusion chip. I wonder which kind of GPU core they will implement. If it's something new and matching the circumstances of being in the APU or if it will be based on some of the known Rxxx.
                As I understand, it is supposed to be an evergreen GPU. Also, from what I gather reading between the lines (and some stuff that has been quite directly said by our good friend Bridgman), a good part of the AMD open source initiative is DIRECTLY related to fusion. I.e., it is one thing to sell a video card that requires proprietary drivers, it is quite ANOTHER thing to sell a CPU that requires proprietary drivers -- and this second possibility is an extremely disturbing possibility.

                Now why they went back all the way to R500 with the open source initiative is this: build up the infrastructure that is required for the full support of a device planned for release in a few years, build up support awareness, build up expertise in building the drivers, build the drivers -- it is said that there are some major architectural similarities between all the devices in the range of R600 through R800 such that they will be able to leverage R600 code for R800 hardware in much the same way that the R300 through R500 are related.

                People complain about a delay between introduction of a new product and when it is finally supported by the various drivers.... well looks to me quite the opposite. The R500/R600/R700/R800 are incidental. The objective is out-of-the-box support for fusionR800, since it would be UNFORGIVABLE for it to not work out-of-the-box. Fusion is supposed to arrive about a year from now.... given the current state of the R600/R700 and Gallium3d initiative, figure it being about enough time to build an R800 Gallium3d driver. I don't think that's a coincidence.

                Comment


                • #9
                  As great as the evergreen support is, it's the temp and fan speed monitoring which interests me most here (and is probably more relevant to most linux ati owners atm), so just wondering if anyone knows anymore on this, ie will it support r500 and earlier, and IGPs (if they even have temp sensors...)?

                  Comment


                  • #10
                    Originally posted by Sadako View Post
                    As great as the evergreen support is, it's the temp and fan speed monitoring which interests me most here (and is probably more relevant to most linux ati owners atm), so just wondering if anyone knows anymore on this, ie will it support r500 and earlier, and IGPs (if they even have temp sensors...)?
                    My current Radeon HD 5770 runs quite hot using the vesa driver on Linux. On Windows 7 (with Catalyst) is runs about 100 degrees F, while on Linux my sensor says 120-121 degrees F!

                    Short side-question: How do I install the git patches? I'm on Mandriva Cooker right now.

                    Comment


                    • #11
                      Right now it just does dynamic engine reclocking; all asics are supported. Support for the external thermal and fan chips is not implemented yet, but requires the i2c work in the branch to be possible. The i2c work also allows for the use of external tuners and decoders on AIW cards.

                      Comment


                      • #12
                        Originally posted by agd5f View Post
                        Right now it just does dynamic engine reclocking; all asics are supported.
                        Hmm, doesn't seem to work here with my HD 5750. It lists only one power state:

                        Code:
                        [drm] 1 Power State(s)
                        [drm] State 0 Default (default)
                        [drm]       16 PCIE Lanes
                        [drm]       1 Clock Mode(s)
                        [drm]               0 engine/memory: 700000/1150000
                        [drm] radeon: power management initialized

                        Comment


                        • #13
                          Originally posted by monraaf View Post
                          Hmm, doesn't seem to work here with my HD 5750. It lists only one power state:

                          Code:
                          [drm] 1 Power State(s)
                          [drm] State 0 Default (default)
                          [drm]       16 PCIE Lanes
                          [drm]       1 Clock Mode(s)
                          [drm]               0 engine/memory: 700000/1150000
                          [drm] radeon: power management initialized
                          The logic on r6xx+ chips needs some work. We currently skip power state is they contain an overclock mode, so you just end up with the default mode.

                          Comment


                          • #14
                            Originally posted by agd5f View Post
                            The logic on r6xx+ chips needs some work. We currently skip power state is they contain an overclock mode, so you just end up with the default mode.
                            I see. But if I understand the code correctly that would only apply if mclk > default_mclk or sclk > default_sclk. I don't think this is the case here since the default mode listed is using the maximum values for mclk and sclk.

                            If I understand the code correctly the code only handles PowerPlayInfo tables with a revision <= 4. And according to the atombios disassembler my bios is using revision 5.

                            Anyway, I probably should file a bug report instead of dumping this in a forum . That is if it is not too early to file bug reports regarding Evergreen.

                            Comment


                            • #15
                              KMS works nice here on my new Vapor-X 5770.

                              Only Multi-Head doesn't work so nice. I can't see the Mouse-Pointer on the second Screen. Apart from that I can use both screens in a normal way. Should I create a Bug-Report about this?

                              System is a Gentoo Linux, drm-radeon-testing commit 7cb72ef on KDE 4.3.5

                              Comment

                              Working...
                              X