Announcement

Collapse
No announcement yet.

AMD's Position On Gallium3D Support

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

  • AMD's Position On Gallium3D Support

    Phoronix: AMD's Position On Gallium3D Support

    If you're a member of the Phoronix Forums where John Bridgman, the AMD employee in charge of the open-source ATI graphics strategy, is known to frequently post (with over 4,200 comments) along with many other X.Org developers and AMD employees, you pretty much know what there is to know about their position on Gallium3D and other topics. However, if you don't, this post is for you...

    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
    I think one can expect r900's to hit around summer 2011 earliest considering their recent roadmaps 1 1/2+ years per "generation". So Gallium for r900 is a given really... At least I sure hope so.

    Comment


    • #3
      Rumours are (they really do sound true, so you can expect it to happen) that R9xx has been delayed a bit and that the next generation will be a mix betweeen R8xx and R9xx due to TSMC being crap at manufacturing chips even at 40nm (R9xx is 32nm). I can imagine the r600 driver being able to add support for that.

      Comment


      • #4
        Kudos to Corbin. He is surely awesome. I hope he will continue working on radeon drivers!

        Just a question: if google will really open-source the vp8 codec, as was pointed out in another thread [1], where could it be accelerated in hardware? I mean generation/driver, of course. I think it's no problem for r600(g) but what about others?

        [1] http://newteevee.com/2010/04/12/goog...r-html5-video/

        Comment


        • #5
          I just posted a bit of an update. After some discussion internally, we're thinking about starting a new copy of the r600 driver for Evergreen. The programming model is still very similar to earlier chips but the register addresses have moved around a lot. This gives us a good excuse to start a Gallium3D-based driver earlier - not sure if we are going to do it or not but we're going to look at it.

          So... the only "definitive" change in plans is that there is likely to be a separate mesa driver for Evergreen, basically an edited copy of the r600 driver. I guess we might call it r800 to make everyone happy, as long as you all accept that there is no r800 just Evergreen

          Not sure what will happen with ddx and Gallium3D driver yet; we'll revisit that after getting further on the Evergreen Mesa driver and discussing options with Jerome & Corbin.
          Test signature

          Comment


          • #6
            I very much like you guys take on this Features >< implementation >< what users want.

            Personally I'd rather have you went directly with Gallium, even though it might give users a working driver faster with classic mesa, but in the long run it would accelerate the development with a Gallium driver, the way I see it.

            That being said for R500-R700, I think those should be completed before going Gallium

            Comment


            • #7
              Originally posted by bridgman View Post
              I just posted a bit of an update. After some discussion internally, we're thinking about starting a new copy of the r600 driver for Evergreen. The programming model is still very similar to earlier chips but the register addresses have moved around a lot. This gives us a good excuse to start a Gallium3D-based driver earlier - not sure if we are going to do it or not but we're going to look at it.

              So... the only "definitive" change in plans is that there is likely to be a separate mesa driver for Evergreen, basically an edited copy of the r600 driver. I guess we might call it r800 to make everyone happy, as long as you all accept that there is no r800 just Evergreen

              Not sure what will happen with ddx and Gallium3D driver yet; we'll revisit that after getting further on the Evergreen Mesa driver and discussing options with Jerome & Corbin.
              Corbin already mentioned that Jerome will have a presentable r600g driver soon - whatever that means. Can't you just use that as a basis for r800 and go galilum-only? I know it seems and probably is risky but it would speed the transition up on all fronts.

              Comment


              • #8
                If that is the plan, then yes I think we would try to build on top of that 600g. Either way, we need to get Evergreen running 3D to ensure that we know how to program it, and we can do that just as well with classic Mesa and do it right now.

                If all the stars align, the sequence will probably go something like :

                - we get Evergreen 3D running on a modified copy of the classic 600 driver
                - in parallel, Corbin & Jerome get 600g running some real apps
                - we collectively figure out what to do about header files since reg addresses changed
                - if we have a good solution for both address sets to coexist then add Evergreen to 600g
                - if we don't have a good solution for both address sets to coexist then create a separate 800g

                Something like that anyways. Too soon to know for sure.
                Test signature

                Comment


                • #9
                  Originally posted by bridgman View Post
                  I just posted a bit of an update. After some discussion internally, we're thinking about starting a new copy of the r600 driver for Evergreen. The programming model is still very similar to earlier chips but the register addresses have moved around a lot. This gives us a good excuse to start a Gallium3D-based driver earlier - not sure if we are going to do it or not but we're going to look at it.

                  So... the only "definitive" change in plans is that there is likely to be a separate mesa driver for Evergreen, basically an edited copy of the r600 driver. I guess we might call it r800 to make everyone happy, as long as you all accept that there is no r800 just Evergreen

                  Not sure what will happen with ddx and Gallium3D driver yet; we'll revisit that after getting further on the Evergreen Mesa driver and discussing options with Jerome & Corbin.
                  I'm certainly no expert, but if only the register addresses are different, can't they just be #ifdef'd?

                  So you could do something like this:
                  Code:
                  #ifdef _R600
                  #define REGISTER_ADDRESS 0xDEADBEEF
                  #elif _R800
                  #define REGISTER_ADDRESS 0xFEEBDAED
                  #endif

                  Comment


                  • #10
                    Yeah, I think the problem is that nearly every line had to be #ifdef'ed and it started to look like driver code hidden behind a wall of #ifdef statements.

                    I don't think it will be a problem; this just seemed like a good opportunity to kill two birds with one stone -- I didn't want to invest a lot of time designing a solution for the classic mesa driver if jumping across to Gallium3D also made the problem go away. The thought process basically went :

                    - merged 6xx/7xx/Evergreen classic driver
                    - toss the work already done on Evergreen/classic, jump to Gallium3D immediately
                    - copy r600 and hack up an Evergreen-specific copy quickly, in parallel decide whether to jump onto Gallium3D immediately

                    It was one of those unplanned replanning moments
                    Test signature

                    Comment

                    Working...
                    X