Announcement

Collapse
No announcement yet.

AMD Documentation Drop Next Week

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

  • AMD Documentation Drop Next Week

    Phoronix: AMD Documentation Drop Next Week

    While we were hopeful that AMD would release the next set of GPU documentation in time for Christmas, we've just been informed that the pending M76 / RS690 specifications will be released by the end of next week. As we mentioned with the RadeonHD 1.1 driver release, this drop will also contain sample code so that DRM work can be underway for the ATI R500 and R600 series.

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

  • #2
    Nifty! I can't wait to see it. Maybe I have a chance of being able to help out now. If I have the time

    Comment


    • #3
      let's hope they did not rush it too much.

      so what exactly is coming this time. 2d only docs?

      Comment


      • #4
        There will be three or four different docs this time, depending on how much we get finished. The two easy ones are register specs for M76 and RS690, similar in content to the M56 and RV630 docs already available on x.org/docs. M76 is our internal name for the mobile version of RV630, ie "Radeon Mobility 2600" - the main difference from the RV630 doc already available is that some important blocks (mostly I2C and LVTMA, the second digital output block) are covered in the mobile docs but not in the desktop docs.

        I discovered that the desktop docs were missing some important info just before the first document release back in September and replaced the 5xx doc with M56 (M56 is mobile 530 IIRC) but couldn't lay hands on M76 documentation in time so went ahead with the 630 doc instead. Clear as mud ? Anyways, first doc just fills in some gaps on the RV630/M76 registers.

        The second doc is for the RS690. This is the integrated chipset whose graphics core often got described as a "Radeon X1200", "X1250" or "X1270". If you look on the amd.com site now we just talk about two chips -- the 690 and 690M (mobile) -- with a couple of variants of each, since they all have the same core albeit at different clock speeds and with some options (HDMI/DVI, sideport memory) not available on the less expensive variants.

        OK ? That's the second doc.

        The third doc is actually a source release with header files and some embedded documentation. It's a simplified version of the "tcore" driver we use for testing new chips before the silicon is available. The main thing that tcore brings is examples on how to set up the command processors, ring buffers for the engines, including IDCT as well as the 3d engine. It doesn't include shader programming info but it does include things like cache setup and flushing. There is also a basic display driver in the sample code but the current radeonhd driver is already quite a bit more advanced.

        The radeonhd devs already have the above info under NDA, btw.

        The fourth piece of documentation (which may not be ready in time) is info about 2d acceleration on 6xx. As I have mentioned earlier, the 6xx doesn't include dedicated 2d acceleration hardware but the command processor (cp) emulates most of the 2d commands using precompiled shaders on the 3d engine. The fourth info package will describe how this works and which commands are emulated, along with sample code for setting up the canned shaders and a precompiled shader blob. I expect that we will replace the shader blob with source code when we start pushing out more 3d info.

        There was a question on IRC about whether "we would wait until 2d docs were out for all chips before releasing 3d info". Quick answer is no -- a better way to describe it would be that our top priority now is enabling 3d development but we are continuing to push 2d docs out while we are working on 3d.

        Comment


        • #5
          Wow thanks for the update Bridgman

          2008 will be a good Year for Amd and linux thats for sure

          Comment


          • #6
            Originally posted by bridgman View Post
            The third doc is actually a source release with header files and some embedded documentation. It's a simplified version of the "tcore" driver we use for testing new chips before the silicon is available.
            Totally OT, but I'm curious as how you test that "driver". I assume you have an array of FPGA's where you load the Verilog model of a particular chip, connected to a windows box, so the driver devs can
            have something to play with, although slow?

            Comment


            • #7
              Thanks bridgman, having an AMD employee here on Phronix besides RadeonHD and the effort AMD puts now into fglrx development turned the scales for me.

              Although I already ordered a HD3870, there is still one open question about Power Play and maybe you can give me a clue. On techPowerUp I read the following about power management of the RV670:
              AMD uses a new form of power management on their RV6xx ASICs called DPM. The GPU independently senses the GPU load and will pick from a set of predefined clocks according to load. Also clock gating is used which turns off unused parts of the silicon and quickly turns them on when they are needed. Unlike the 2D/3D switching on previous ATI cards where the driver manually switched clocks as soon as a 3D fullscreen application is started this process is completely transparent to the software and the driver. This also means that windowed 3D applications will run at the intended performance.
              However other reviews tell things still work driver dependent, so if changing power states is still a driver job, does it work with fglrx and will those specifications also become availiable for the RadeonHD team or are these processes completely transparent to the software now?

              Thanks in advance
              puntarenas

              Comment


              • #8
                Originally posted by bridgman View Post
                The fourth piece of documentation (which may not be ready in time) is info about 2d acceleration on 6xx. As I have mentioned earlier, the 6xx doesn't include dedicated 2d acceleration hardware but the command processor (cp) emulates most of the 2d commands using precompiled shaders on the 3d engine. The fourth info package will describe how this works and which commands are emulated, along with sample code for setting up the canned shaders and a precompiled shader blob. I expect that we will replace the shader blob with source code when we start pushing out more 3d info.
                Does 2d on the R500 fall into this category or does it fall into the R300/400 category? (or into its own category)

                Comment


                • #9
                  Originally posted by koolmanoncampus View Post
                  Does 2d on the R500 fall into this category or does it fall into the R300/400 category? (or into its own category)
                  The 5xx family and the RS600/RS690 have the same 2d engine as the R300/400 family, so the 2d acceleration code in the "radeon" driver should work with only minor changes. I believe that 2d acceleration is already running on 5xx parts in the current "radeon" driver, so porting that over to radeonhd shouldn't be a lot of work.

                  Originally posted by puntarenas View Post
                  However other reviews tell things still work driver dependent, so if changing power states is still a driver job, does it work with fglrx and will those specifications also become availiable for the RadeonHD team or are these processes completely transparent to the software now?
                  My understanding is that there is still some driver involvement, but the new HW capabilities on 6xx parts allow faster and more fine-grained power-down than the driver can do on its own so overall power savings can be improved. We will be making this information available to open source developers. In parallel, support is being added (or has been added) to fglrx although I'm not sure of the exact status.
                  Last edited by bridgman; 12-27-2007, 01:53 PM.

                  Comment


                  • #10
                    Thanks, really good news

                    Comment


                    • #11
                      The news is good, but maybe 1 year too late for buying current cards. Today the only hotfix for ppl with ATI problems is buying another card or lose too many features which would work fine with Win.

                      Comment


                      • #12
                        Gr8

                        Fantastic to get so much details directly from the AMD/ATi team! Thanx!

                        I've been fairly grumpy on this forum myself, but fglrx on the Mobile X1400 has really been problematic too. With AMD developers taking part of the discussions around here, I am sure some of the heated arguments (mostly stemming from disappointment and desperation due to lack of information where things are going) will cool down a bit.

                        Anyways, great news dudes!

                        Comment


                        • #13
                          Originally posted by bridgman View Post
                          There was a question on IRC about whether "we would wait until 2d docs were out for all chips before releasing 3d info". Quick answer is no -- a better way to describe it would be that our top priority now is enabling 3d development but we are continuing to push 2d docs out while we are working on 3d.
                          Out of interest what is involved in pushing out these docs? Are you reworking existing internal docs? or making up new documentation from a wide variety of internal sources?

                          Comment


                          • #14
                            Originally posted by Ze.. View Post
                            Out of interest what is involved in pushing out these docs? Are you reworking existing internal docs? or making up new documentation from a wide variety of internal sources?
                            As I've understood fglrx developers use the same specs, but they need to be sanitized.

                            Comment


                            • #15
                              For the initial doc release (and some of the next round of docs) I was able to find existing docs which were a good starting point. We basically read through them, pulled out any sensitive DRM-related stuff, and replaced all the scary NDA/confidentiality notices with new wording worked out with our legal folks.

                              Going forward, particularly for 3d, "making up new documentation from a wide variety of internal sources" is probably closer to the mark. We can rely on existing docs for filling in knowledge gaps in older chips but we don't have a "Young Person's Guide to Writing Drivers for the Latest Radeon Chips" document lying around.

                              Comment

                              Working...
                              X