Announcement

Collapse
No announcement yet.

Initial R6xx/R7xx 3D Driver

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

  • Initial R6xx/R7xx 3D Driver

    Since there's not an article about it yet on Phoronix, decided to link this up.
    http://www.botchco.com/agd5f/?p=43

  • #2
    Oh that is very good news!

    Comment


    • #3
      It'll probably be a few more weeks before it gets cleaned up and merged with radeon-rewrite, but at least all the work can happen in public now.

      A couple of reminders;

      1. This is still in development, don't be trying to run games on it yet.

      2. You'll need drm from a branch in agd5f's mesa repo

      3. There are two 6xx branches in mesa/mesa; r6xx-r7xx-support and r6xx-rewrite. All the new code is currently in r6xx-r7xx-support - the other branch is where we will be merging the new code with radeon-rewrite and fixing things over the next few weeks.

      Our short term priority will be merging with radeon-rewrite; we might fix a few bugs in the r6xx-r7xx-support tree but we mostly wanted to get all the current code out into public so the remaining work could also be done outside of the NDA depot.

      Alex's blog has the current info; note that the copy of his blog post on planet.fdo is out of date.
      Last edited by bridgman; 04-17-2009, 04:32 PM.

      Comment


      • #4
        Serious WIN.

        Comment


        • #5
          Originally posted by bridgman View Post
          It'll probably be a few more weeks before it gets cleaned up and merged with radeon-rewrite, but at least all the work can happen in public now.
          I know, I just noted people had gotten (well, admittedly I had too) a bit anxious so I decided to relay this here as soon as I heard it on IRC. Good work. With power management and initial 3D code, next few months will probably be very interesting for new ATi card owners.
          Originally posted by bridgman View Post
          Our short term priority will be merging with radeon-rewrite; we might fix a few bugs in the r6xx-r7xx-support tree but we mostly wanted to get all the current code out into public so the remaining work could also be done outside of the NDA depot.
          Sure, this is imo the only sensible approach. With the code out in the open everyone willing can participate and we have no one but ourselves to blame if the support takes its time.

          Comment


          • #6
            awesome awesome awesome!
            cant wait to get a new notebook with a new ati graphicscard!

            Comment


            • #7
              Just installed it. glxinfo gives me:

              OpenGL renderer string: R6xx

              I also tried glxgears, but it hung my system. Is there anything else I can use to test it?

              Comment


              • #8
                Are you sure you have the right drm ? Right now you need the one from agd5f's personal repo (a branch in ~agd5f/drm); the one in mesa/drm 6xx-7xx-support branch will initialize OK but won't actually *work* with 3D. I imagine the mesa code will crash if you run it on the drm code in mesa/drm but not 100% sure.

                The drm in agd5f's repo includes new ioctls used by the 3D driver. That was one of the "learning opportunities" for me in this part of the project -- I knew the X server and direct-rendering clients had different entry points into drm, but I didn't realize the two entry points had totally different APIs

                Another thing I learned was that nobody liked the direct-rendering API between mesa and drm for 3xx-5xx, and that a lot of work had gone into defining a new API for use with memory management (GEM/TTM). The existing non-mm API was being kept for pre-6xx GPUs simply because it was already in the kernel, but the consensus recommendation from the devs was that for 6xx and up we should define and use a new non-mm mesa-to-drm API which was as close as possible to the API used *with* memory management on earlier GPUs.

                The result, hopefully, will be (a) a better API, and (b) much less effort to make the new 3D code work over a memory manager (KMS/GEM/TTM) in the future. I'm *pretty* sure that new API is what's implemented in agd5f's drm branch. Note that since the 6xx/7xx direct-rendering-client to drm API has never gone into the Linux kernel it can still be changed, while making changes to the API used for 5xx and earlier would be much more difficult.

                Anyways, bottom line is that there are a bunch of very similar drm trees out there right now but only one of them will work. We debated getting all the merging and cleanup finished before pushing anything to a public repo but figured it would be better to push what we had then clean up in the public repos.

                Finally, the code has only really been run on developer machines, ie we haven't done the "put card A in, test, fix, put card B in, test, fix, put card A back in, test, curse, fix the previous fix, put card B back in, test, put card C in, test, fix, put card D in, test, wow it works, put card E in, test, fix..." dance yet.
                Last edited by bridgman; 04-17-2009, 11:54 PM.

                Comment


                • #9
                  will this driver support radeon xpress 200m chips?

                  Comment


                  • #10
                    Originally posted by homerhomer View Post
                    will this driver support radeon xpress 200m chips?
                    If I read Wikipedia correctly, that card is RS482 and should already have 3D with the open drivers. This is just a piece of news related to the most newest cards.

                    Comment


                    • #11
                      just curious: is someone allowed to tell me if this implementation will work with the RV740 when it's released? It's still 7xx, but you never know..

                      Those RV740 previews just look too good to not buy one soon, but I'd like to have working drivers before buying

                      Comment


                      • #12
                        Originally posted by bridgman View Post
                        Are you sure you have the right drm ?
                        Yes I'm pretty sure. I only have 2 drms, the one shipped with Jaunty and the one I cloned from agd5f's repository.

                        Code:
                        $ git branch
                          r345-cleanup
                        * r6xx-r7xx-3d
                        If I don't install the drm from agd5f's repository and use the one shipped with Jaunty and run glxgears the system doesn't hang and my dmesg gets spammed with:
                        Code:
                        [drm:radeon_cp_cmdbuf] *ERROR* bad cmd_type 0 at f050c000
                        If I do install and use the drm from agd5f's repository and run glxgears the system just hangs.

                        Finally, the code has only really been run on developer machines, ie we haven't done the "put card A in, test, fix, put card B in, test, fix, put card A back in, test, curse, fix the previous fix, put card B back in, test, put card C in, test, fix, put card D in, test, wow it works, put card E in, test, fix..." dance yet.
                        Oke, I'm using radeon HD 3200 (IGP)

                        Comment


                        • #13
                          Originally posted by rohcQaH View Post
                          just curious: is someone allowed to tell me if this implementation will work with the RV740 when it's released? It's still 7xx, but you never know..

                          Those RV740 previews just look too good to not buy one soon, but I'd like to have working drivers before buying
                          It will work with RV740 at least eventually, yes. It's just that no one yet knows exactly when you can expect reasonable functionality from it. Also as bridgman mentioned, developers haven't done extensive card testing with the code yet so it can't be guaranteed to work with all cards in the series. As said, this is only initial code and won't probably be of much use to end users yet except as a reminder (to me and other end users) that the developers are making progress. Most of the significance is that what exists is no longer behind closed doors.
                          In a nutshell this probably shouldn't influence purchase decisions if you expect to get something now. If you are fine with the fact that you have to wait before getting 3D out of the card and even then it will probably not be as powerful as the proprietary ones but mostly compares to the open drivers for the older cards, then it's fine. Those waiting for the performant drivers (read: with modern games) would be waiting for Gallium+LLVM, not this classic Mesa driver. :3

                          Comment


                          • #14
                            Wau this is good news.
                            I wonder if it is the trouble worth trying it yet?
                            Last edited by tball; 04-18-2009, 08:15 AM.

                            Comment


                            • #15
                              nice, but I won't have a look at it, until it enters a branch like mesa/drm r6xx-r7xx-support don't know why, but it feels more "stable", at least the API

                              Comment

                              Working...
                              X