Announcement

Collapse
No announcement yet.

R600/700 EXA X-Video Code Merged To Master

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

  • R600/700 EXA X-Video Code Merged To Master

    Phoronix: R600/700 EXA X-Video Code Merged To Master

    In late December AMD had released R600/700 3D code that allowed open-source triangles to be drawn and a AtomBIOS decompiler also came out of Novell just a few days later. In late January we were then greeted by public R600/700 3D documentation...

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

  • #2
    Well, great job!
    But I want my radeonhd

    Comment


    • #3
      Nice

      Now let's wait for Linux 2.6.30!

      Comment


      • #4
        "Now it's time to have a working, open-source 3D stack for the ATI Radeon HD 2000/3000/4000 hardware."

        I really can't wait for a phoronix article that says: "And here is your free 3d!"

        Comment


        • #5
          gimme gimme!

          Comment


          • #6
            Great steps! But I also wait for radeonhd.
            Hopefully the DRI bug gets fixed soon. Here it crashed sometimes while moving and resizing a movie outside of the screen...If that is fixed, I'll stick to it. Atm I use radeonhd+shadowfb again. AFAIK this is also the last reason why DRI is not enabled by default.
            Apart from that I really really like radeonhd. It runs really awesome.

            Comment


            • #7
              When will xf86-video-ati vs RadeonHD drivers will end? What about a merge for not wasting the already limited resources?

              This is bad to both developers and users...

              Comment


              • #8
                The experience should be roughly the same with both -ati and -radeonhd nowadays (or, I think -radeonhd has the HDMI audio support which -ati lacks? but otherwise). The problem of two drivers is basically already ending, because the ddx drivers are becoming irrelevant with the current r6xx-r7xx work in the drm driver and kernel mode setting. The work is independent from these ddx drivers and have eg. no code from -radeonhd.

                You can see the similarity also in that you may use the same wiki instructions for both drivers, although for xf86-video-ati you naturally do not need the branch anymore since it's in trunk.

                It should not be wasting resources much either, since as you can see in the two (1, 2) git branches, the last 20+ commits are roughly just the same code committed in two places

                Correct me if I'm wrong, but it seems there is not much overlapping work done anymore, in the sense it would slow down something. Radeonhd was planned to become different, not using atombios, but now also radeonhd uses atombios like ati.

                Comment


                • #9
                  It's pretty much the same acceleration code in both drivers (and the same developer ) so there's not really a lot of duplication going on right now. It would still be nice to get to a single code base over time.

                  The drm code and mesa code are *exactly* the same, of course, since there has only ever been one code base.

                  In the meantime, as libv said on IRC today, if you find that one driver has problems but the other one works for you, please report the problem (via bugzilla or mailing list) for the other driver anyways. Sometimes this gives the devs a real useful clue.
                  Last edited by bridgman; 02-26-2009, 03:25 PM.

                  Comment


                  • #10
                    What are the differences between Radeon and RadeonHD anyway? I hear they've got a different modesetting code, but that too is not the case anymore once KMS is supported by the free drivers I guess? Anything else?

                    Comment


                    • #11
                      Originally posted by d2kx View Post
                      What are the differences between Radeon and RadeonHD anyway? I hear they've got a different modesetting code, but that too is not the case anymore once KMS is supported by the free drivers I guess? Anything else?
                      It's mostly the modesetting code that is different (in a number of ways), although there are some changes in other areas as well, eg Luc reworked the bottom end of the acceleration stack in radeonhd.

                      Even though KMS is pretty much here, it will still be a while before the need for user modesetting goes away since most of the enterprise distro users will be running pre-KMS kernels for a couple of years. I don't expect you'll see the first release of a KMS-enabled enterprise distro until some time in 2010, and realistically we need to keep user modesetting supported until a good chunk of the enterprise distro installed base is running with KMS-enabled kernel code.

                      Comment


                      • #12
                        Is the current plan to work on adding R600/R700 support to Mesa, or to jump straight to Gallium?

                        Comment


                        • #13
                          Originally posted by bridgman View Post
                          It's mostly the modesetting code that is different (in a number of ways), although there are some changes in other areas as well, eg Luc reworked the bottom end of the acceleration stack in radeonhd.

                          Even though KMS is pretty much here, it will still be a while before the need for user modesetting goes away since most of the enterprise distro users will be running pre-KMS kernels for a couple of years. I don't expect you'll see the first release of a KMS-enabled enterprise distro until some time in 2010, and realistically we need to keep user modesetting supported until a good chunk of the enterprise distro installed base is running with KMS-enabled kernel code.
                          long live gentoo <3

                          Comment


                          • #14
                            Originally posted by mattst88 View Post
                            Is the current plan to work on adding R600/R700 support to Mesa, or to jump straight to Gallium?
                            We're going to add basic 6xx/7xx support using the "classic" mesa driver model first, in order to provide support for users running systems which don't have KMS/MM and DRI2. By "basic" support I mean roughly the same functionality we have with 5xx today.

                            Once that is running, we'll port the hw-specific code across to Mesa-on-Gallium3D and do most of the ongoing work there.

                            Comment


                            • #15
                              Do you know if there are plans to merge the r6xx/7xx EXA code back into Catalyst? I've here terrible performance with KDE4.2, and my XRender benchmark results go hand in hand with the user experience.

                              Comment

                              Working...
                              X