Announcement

Collapse
No announcement yet.

Full EXA Composite For R300-500 GPUs

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

  • Full EXA Composite For R300-500 GPUs

    Phoronix: Full EXA Composite For R300-500 GPUs

    Alex Deucher has been working on delivering full EXA Composite support for the Radeon driver and today the first bits of this work are available via his personal git repository. The full EXA Composite not only covers the R300 and R400 generations, but it already supports the Radeon X1000 (R500) graphics cards! In Alex's blog post he mentions that some blend combinations still need to be debugged, but the R300/400 support in general is pretty solid...

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

  • #2
    cool, when will be the next stable release? (especially for ubuntu)

    Comment


    • #3
      This is great. Go devs!

      Comment


      • #4
        This news makes very little sense. I was told in an IRC chat that the Radeon driver was dead, that it was a case of RadeonHD slowly becoming usable and the proprietary driver as the only two options. Also doesn't Alex work for AMD now? Or was that somebody else. If so, why isn't this EXA support going into RadeonHD?

        Comment


        • #5
          Originally posted by an0n1m0us View Post
          This news makes very little sense. I was told in an IRC chat that the Radeon driver was dead, that it was a case of RadeonHD slowly becoming usable and the proprietary driver as the only two options. Also doesn't Alex work for AMD now? Or was that somebody else. If so, why isn't this EXA support going into RadeonHD?

          As I understand it, radeonHD does not have "official" support for anything below R400. Why would they kill it off then?

          Comment


          • #6
            RE: Radeon vs. RadeonHD... There is coincidently an article going up on Phoronix tomorrow morning surrounding the debate.

            The RadeonHD driver right now has basic EXA/XAA R500 support.
            Michael Larabel
            http://www.michaellarabel.com/

            Comment


            • #7
              I was told in an IRC chat that the Radeon driver was dead, that it was a case of RadeonHD slowly becoming usable and the proprietary driver as the only two options.
              who told you that?

              radeonhd is unlikely to extend support for pre-r500 cards, so radeon driver has a good reason to stay.

              Comment


              • #8
                I thought the eventual goal was for radeonhd to merge back into radeon. The whole reason it exists was since drastic changes might be needed to support the newer chips, the developers thought it best to fork the current driver to avoid breaking pre-r500 chips while it evolved.

                Comment


                • #9
                  Originally posted by Tillin9 View Post
                  I thought the eventual goal was for radeonhd to merge back into radeon. The whole reason it exists was since drastic changes might be needed to support the newer chips, the developers thought it best to fork the current driver to avoid breaking pre-r500 chips while it evolved.

                  RadeonHD was written from scratch so there is no "merging back". AMD does want the two drivers to move, but the RadeonHD devs at least feel the drivers are far too different now to possibly merge.
                  Michael Larabel
                  http://www.michaellarabel.com/

                  Comment


                  • #10
                    i would not mind having two separate drivers. r5xx and newer have some substantial changes to 2d acceleration, and it seems pretty reasonable to have a separate driver for these cards.

                    Comment


                    • #11
                      Radeon vs. RadeonHD: http://www.phoronix.com/vr.php?view=12052
                      Michael Larabel
                      http://www.michaellarabel.com/

                      Comment


                      • #12
                        Originally posted by an0n1m0us View Post
                        This news makes very little sense. I was told in an IRC chat that the Radeon driver was dead, that it was a case of RadeonHD slowly becoming usable and the proprietary driver as the only two options. Also doesn't Alex work for AMD now? Or was that somebody else. If so, why isn't this EXA support going into RadeonHD?
                        This may seem confusing, but the key point to remember is that only the display hardware changed significantly between 4xx and 5xx -- for all of the other blocks, including acceleration, the hardware is pretty much unchanged between 4xx and 5xx. In driver terms, this means that only the modesetting part needs to be different and the (larger) acceleration code should be common. Unfortunately the X driver framework is not broken up that way, leaving us two alternatives :

                        - separate driver for newer chips, duplicate the acceleration code across the two drivers (radeonhd)
                        - one driver with separate modesetting code for older & newer chips, one copy of the acceleration code (radeon)

                        All of the acceleration work being performed recently (Textured Video, EXA rotate & blend, 3D) uses the 3D engine, which in turn requires DRI support in the driver. Today the radeon driver has DRI support but radeonhd does not, so in the short term acceleration work is being done using radeon. Adding DRI support and porting across the existing 2D & video acceleration code is top priority for radeonhd, since that will allow acceleration work to be done using radeonhd, not just in radeon.

                        As long as we keep the acceleration code common between the two drivers, work done in one driver will be able to immediately benefit the other anyways.
                        Last edited by bridgman; 03-19-2008, 08:28 AM.

                        Comment


                        • #13
                          Ah, I had remembered a few quotes from the radeonhd developers along the lines of "we're trying to keep things similar to make sharing code easier" from the forum and from FOSDEM talks. I guess the drivers diverged enough for this to be no longer the case.

                          EDIT: Thanks for the clarification of modesetting / acceleration.

                          After reading today's article, my big question is which method leads to kernel-level modesetting, ideally, platform independent (non-x86) kernel-level modesetting?

                          I'm a tad confused as to what AtomBIOS actually is. When I heard it being discussed before, the idea of parsing and scripts, made me think it was a way to keep the interface high-level, by passing tokens to the GPU, it then turned these into all the necessary register changes internally. Thus it not only kept the driver smaller, but let the CPU focus on other things. If that's what it does, I'm okay with using it so long as docs are released. If AtomBIOS is just a way of putting x86 blobs in firmware, i.e. the tokens are turned in x86 assembly for the CPU, I think the Novell developers are right, and it should be avoided.

                          Comment


                          • #14
                            Originally posted by yoshi314 View Post
                            i would not mind having two separate drivers. r5xx and newer have some substantial changes to 2d acceleration, and it seems pretty reasonable to have a separate driver for these cards.
                            Not exactly. R5xx has the same 2D core and a very similar 3D core as R3xx and R4xx chips. When we added atombios support to radeon, 2D worked out of the box on R5xx. Also, I originally added EXA Composite support for R3xx/R4xx. Since the 3D engine is so similar it was trivial to add support for R5xx. The only real difference between R5xx and the older chips is the display engine, which with atombios, was easy to support quickly.
                            Last edited by agd5f; 03-19-2008, 10:51 AM.

                            Comment


                            • #15
                              Originally posted by Tillin9 View Post
                              I'm a tad confused as to what AtomBIOS actually is. When I heard it being discussed before, the idea of parsing and scripts, made me think it was a way to keep the interface high-level, by passing tokens to the GPU, it then turned these into all the necessary register changes internally. Thus it not only kept the driver smaller, but let the CPU focus on other things. If that's what it does, I'm okay with using it so long as docs are released. If AtomBIOS is just a way of putting x86 blobs in firmware, i.e. the tokens are turned in x86 assembly for the CPU, I think the Novell developers are right, and it should be avoided.
                              It is literally a set of scripts and data tables stored in the the rom on the card. The scripts are specific to a certain tasks (turning on/off an output, setting the PLL, setting crtc timing, etc.). The atombios script interpreter in the driver decodes the scripts and programs the registers. The scripts basically break down to a list of registers and what values to program them with based on paramters you pass to the script. This allows us to write modesetting code and sort out any HW specific tweaks once (in atom code stored in the rom), then everything else (drivers, bios, etc.) is able to utilize that. Since they are scripts they can even be run even on non-x86 platforms. This allows you to post atom-based cards on powerpc or arm, etc.

                              Comment

                              Working...
                              X