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.

  • #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; 17 April 2009, 04:32 PM.
      Test signature

      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; 17 April 2009, 11:54 PM.
                Test signature

                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

                    Working...
                    X