Announcement

Collapse
No announcement yet.

ATI RV770 Mesa DRI Driver Started

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

  • ATI RV770 Mesa DRI Driver Started

    Phoronix: ATI RV770 Mesa DRI Driver Started

    AMD has yet to go through their final intellectual property review on the R600/700 3D documentation that could yield open ATI R600/700 3D graphics by Christmas (though the chances of this happening are slimming), but Novell's Hatthias Hopf has provided a status update to report that they have internally begun work on an RV770 DRI driver for Mesa. Matthias and Alex Deucher have now been successful in running r600_demo (a very basic 3D test program) on the RV770 GPUs (Radeon HD 4800 series) in the same way as the Radeon HD 2000/3000 series. The Hopf-Deucher duo along with the two other AMD engineers that report to John Bridgman have started work on the Mesa DRI driver that will allow open-source OpenGL acceleration for these new ATI graphics cards. As no documentation or code has yet to be cleared by AMD's legal department, all of this code is being worked on privately...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Each time I seen a headline on Phoronix that is somehow related to ATi and open source, my heart stops for a second

    This is so exciting times.

    Comment


    • #3
      Well I'm getting a little annoyed about these weekly "soon" news. I hate wainting.

      Comment


      • #4
        OK, I'll start a new thread when we're finished
        Test signature

        Comment


        • #5
          Originally posted by bridgman View Post
          OK, I'll start a new thread when we're finished
          2030? Not sure my pension will last that long...

          Comment


          • #6
            Originally posted by izual View Post
            I hate waiting.
            No one likes to wait, but doing it without complaining is a very useful skill
            Personally, I'm grateful that Phoronix keeps people informed as to how far along the driver is.

            Comment


            • #7
              Originally posted by bridgman View Post
              OK, I'll start a new thread when we're finished
              I like getting these updates, so I can see what we are moving forward

              Comment


              • #8
                The exciting times will be when Larabee is out, and you can throw these fixed functions cards away, and actually use your card when you buy it (rather than one year later, and only if the manufacturer feels like it). I ditched NV for AMD, looks like I'll be moving to another manufacturer again

                Comment


                • #9
                  Just to be clear; this is a bog standard Mesa/DRI driver, right? Not one for Gallium? If so, what's the rationale for not skipping straight to Gallium? That would seem like the thing to do to me, though I obviously don't know what I'm talking about.

                  Comment


                  • #10
                    Nope, it's a fair question.

                    First release will be Mesa using the existing driver model, ie making a copy of the existing r300 code (which handles 3xx-5xx) and modifying it to use 6xx/7xx sequences instead of 3xx/5xx. We also plan to use the existing ioctls for communication between mesa and drm, not the new improved ones being worked on by Dave, Jerome and others.

                    The purpose of the first release is to get working code into users and developers hands and to find out any hardware-related issues as quickly as possible. Going with "known good" (and I use the term loosely because all of the developers agree that the current code is old and crufty) simply lets us focus nearly all of our efforts on hardware-specific work without having to also deal with changes and issues in the new code.

                    Once we have working code for the existing driver model it will be easy for the developers to re-use that code with the Gallium driver model and/or the new command submission, fencing and memory management code.

                    Put simply, going this route lets devs come up to speed on Gallium and other new things in parallel with us coming up to speed on how to make the chip work. I think it gets us where we want to go in the fastest and most predictable way.
                    Test signature

                    Comment

                    Working...
                    X